idnits 2.17.1 draft-michaelson-rpki-rta-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 1, 2020) is 1271 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC6480' is mentioned on line 86, but not defined -- Looks like a reference, but probably isn't: '0' on line 182 -- Looks like a reference, but probably isn't: '1' on line 183 == Missing Reference: 'FTP' is mentioned on line 325, but not defined == Missing Reference: 'TELNET' is mentioned on line 330, but not defined == Missing Reference: 'UFNI' is mentioned on line 363, but not defined == Missing Reference: 'R20081126' is mentioned on line 369, but not defined == Missing Reference: 'PDF' is mentioned on line 383, but not defined == Missing Reference: 'PS' is mentioned on line 383, but not defined == Missing Reference: 'EPUB' is mentioned on line 383, but not defined Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Michaelson 3 Internet-Draft G. Huston 4 Intended status: Experimental T. Harrison 5 Expires: May 5, 2021 APNIC 6 T. Bruijnzeels 7 M. Hoffmann 8 opennetlabs 9 November 1, 2020 11 A profile for Resource Tagged Attestations (RTAs) 12 draft-michaelson-rpki-rta-02 14 Abstract 16 This document defines a Cryptographic Message Syntax (CMS) profile 17 for a general purpose Resource Tagged Attestation (RTA), for use with 18 the Resource Public Key Infrastructure (RPKI). The objective is to 19 allow an attestation, in the form of an arbitrary digital object, to 20 be signed "with resources", and for validation to provide an outcome 21 of "valid with resources". The profile is intended to provide for 22 the signing of an attestation with an arbitrary set of resources. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 5, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 60 3. RTA Profile . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. The RTA ContentType . . . . . . . . . . . . . . . . . . . . . 4 62 5. The RTA eContent . . . . . . . . . . . . . . . . . . . . . . 4 63 5.1. version . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.2. subjectKeyIdentifiers . . . . . . . . . . . . . . . . . . 5 65 5.3. resources . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.4. digestAlgorithm . . . . . . . . . . . . . . . . . . . . . 6 67 5.5. messageDigest . . . . . . . . . . . . . . . . . . . . . . 6 68 5.6. attestations . . . . . . . . . . . . . . . . . . . . . . 6 69 6. RTA Validation . . . . . . . . . . . . . . . . . . . . . . . 6 70 7. Need for Canonicalization . . . . . . . . . . . . . . . . . . 7 71 7.1. ASCII, UTF-8, and HTML File Canonicalization . . . . . . 7 72 7.2. XML File Canonicalization . . . . . . . . . . . . . . . . 8 73 7.3. No Canonicalization of Other File Formats . . . . . . . . 9 74 8. Standalone Use . . . . . . . . . . . . . . . . . . . . . . . 9 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 78 12. Revision history . . . . . . . . . . . . . . . . . . . . . . 10 79 13. Normative References . . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 This document defines a Cryptographic Message Syntax (CMS) [RFC5652] 85 profile for a general purpose Resource Tagged Attestation (RTA), for 86 use with the Resource Public Key Infrastructure (RPKI) [RFC6480]. An 87 RTA allows an arbitrary digital object to be signed "with resources," 88 and for validation of the digital signature to provide an outcome of 89 "valid with resources." The profile is intended to provide for the 90 signing of a arbitrary attestation with a set of resources by the 91 duly delegated resource holder(s). 93 The RTA makes use of the template for RPKI Digitally Signed Objects 94 [RFC6488], which defines a CMS wrapper for the RTA content, as well 95 as a generic validation procedure for RPKI signed objects. However, 96 this specification does not comply to the profile in [RFC6488] in all 97 respects. This document describes the areas of difference to the 98 template profile, the ASN.1 syntax for the RTA eContent, and the 99 additional steps required to validate RTAs (in addition to the 100 validation steps specified in [RFC6488]. 102 An RTA is a detached signature CMS model, it leverages concepts 103 documented in [RFC8358] and [RFC5485]. Text from these RFCs has been 104 repurposed removing references to internet-drafts and RFCs since this 105 is a general detached signature signing model. 107 2. Conventions Used In This Document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119] when they 112 appear in ALL CAPS. These words may also appear in this document in 113 lower case as plain English words, absent their normative meanings. 115 3. RTA Profile 117 An RTA conforms to the template for RPKI Digitally Signed Objects 118 [RFC6488], with the exception that in order to allow for arbitrary 119 resource sets to be used to sign an RTA, it may be necessary to use 120 multiple signatures to sign an RTA. 122 The differences between this RTA profile and the profile specified by 123 the RPKI Digitally Signed Object template are as follows: 125 o Section 2.1 of [RFC6488] specifies a single SignerInfo object. An 126 RTA MAY contain more than one SignerInfo object. 128 o Section 2.1.4, and Section 3 of [RFC6488] specify that the 129 certificates field contains a single EE certificate. The 130 certificates field of an RTA contains precisely the same number of 131 EE certificates as there are SignerInfo objects in the RTA, where 132 each EE certificate is needed to validate the signature in each 133 SignerInfo. In addition, the certificates field MAY contain a 134 collection of CA certificates that would allow a RP to validate 135 the EE certificates. 137 o Section 2.1.5 of [RFC6488] specifies that the crls field be 138 omitted. For RTAs the crls field MUST contain the current CRL for 139 each CA certificate that has been included in the certificates 140 field of the RTA. 142 o Section 3 of [RFC6488] describes the signed object validation 143 checks that are to be performed by a Relying Party. Additional 144 validation checks for an RTA are required, as described in section 145 5 of this profile. 147 4. The RTA ContentType 149 The ContentType for an RTA is defined as resourceTaggedAttestation, 150 and has the numerical value of 1.2.840.113549.1.9.16.1.36 152 This OID MUST appear both within the eContentType in the 153 encapContentInfo object as well as the ContentType signed attribute 154 in the signerInfo object (see [RFC6488]). 156 5. The RTA eContent 158 The content of an RTA indicates that an arbitrary digital object has 159 been signed "with resources". An RTA is formally defined as: 161 ResourceTaggedAttestationDefinitions DEFINITIONS ::= 162 BEGIN 164 -- definition from rfc3029 165 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 166 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) 1 } 168 id-ct-resourceTaggedAttestation OBJECT IDENTIFIER ::= 169 { id-ct(1) 36 } 171 ResourceTaggedAttestation ::= SEQUENCE { 172 version [0] INTEGER DEFAULT 0, 173 subjectKeyIdentifers SubjectKeys, 174 resources ResourceBlock, 175 digestAlgorithm AlgorithmIdentifer, 176 messageDigest OCTET STRING } 178 SubjectKeys ::= SET SIZE (1..MAX) OF SubjectKeyIdentifier 179 -- defined in RFC5280 181 ResourceBlock ::= SEQUENCE { 182 asID [0] AsList OPTIONAL, 183 ipAddrBlocks [1] IPList OPTIONAL } 184 -- at least one of asID or ipAddrBlocks must be present 186 AsList ::= SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange 187 ASIdOrRange ::= CHOICE { 188 id ASId, 189 range ASRange } 191 ASRange ::= SEQUENCE { 192 min ASId, 193 max ASId } 195 ASId ::= INTEGER 197 IPList ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamily 199 IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI -- 200 addressFamily OCTET STRING (SIZE (2..3)), 201 addressesOrRanges SEQUENCE OF IPAddressOrRange } 203 IPAddressOrRange ::= CHOICE { 204 addressPrefix IPAddress, 205 addressRange IPAddressRange } 207 IPAddressRange ::= SEQUENCE { 208 min IPAddress, 209 max IPAddress } 211 IPAddress ::= BIT STRING 213 -- imported from [@!RFC5280] 214 AlgorithmIdentifer ::= SEQUENCE { 215 algorithm OBJECT IDENTIFIER, 216 parameters ANY DEFINED BY algorithm OPTIONAL } 217 END 219 Note that this content appears as the eContent within the 220 encapContentInfo (see [RFC6488]). 222 [TODO: this needs some work. The AttestationSet is from prior pre-00 223 state. What is this referring to?] 225 Note that AttestationSet is a SET OF EncapsulatedContentInfo from 226 [RFC5485] 228 5.1. version 230 The version number of the ResourceTaggedAttestation MUST be 0. 232 5.2. subjectKeyIdentifiers 234 The subjectKeyIdentifiers MUST be the set of SubjectKeyIdentifier 235 values contained in each of the EE certificates carried in the CMS 236 certificates field. 238 5.3. resources 240 The resources contained here are the resources used to tag the 241 attestation, and MUST match the set of resources listed by the set of 242 EE certificates carried in the CMS certificates field. 244 The ordering of resources is defined in [RFC3779]. 246 5.4. digestAlgorithm 248 The digest algorithm used to create the message digest of the 249 attested digital object. This algorithm MUST be a hashing algorithm 250 defined in [RFC7935]. 252 5.5. messageDigest 254 The message digest of the attested digital object using the algorithm 255 specified in the digestAlgorithm field. 257 5.6. attestations 259 The SET OF EncapsulatedContentInfo [RFC5485] which form the 260 individual digital signatures, made by each signing party. For each 261 instance in the set, one of the subjectKeyIdentifiers MUST identify a 262 certificate which can validate the signature. This means that there 263 will be an instance of a SignedData and SignerInfo for that 264 subjectKeyIdentifier (SignerInfo.sid) 266 The eContentType is id-ct-anyContentType, which refers to the ASN.1 267 ANY octet sequence. 269 6. RTA Validation 271 To validate an RTA the relying party MUST perform all the validation 272 checks specified in [RFC6488] as well as the following additional 273 RTA-specific validation steps. 275 o Canonicalization of the attested object MUST be performed. 277 o The message digest of the attested object using the digest 278 algorithm specified in the the digestAlgorithm field MUST be 279 calculated and MUST match the value given in the messageDigest 280 field of the RTA content. 282 o The signature verification process defined section 5.6 of 283 [RFC5652] MUST be performed for all public keys referenced in each 284 SignerInfo of the CMS. If any signature cannot be verified, then 285 the RTA MUST NOT be validated. This process includes CRL checks 286 which may require fetching from the CRLDP of any certificate 287 without an embedded CRL in the CMS which is current. 289 [TODO more text needed about CRL/CRLDP and handling expired CRLS] 291 o The set of public keys contained in the subjectKeyIdentifers of 292 the RTA MUST exactly match the set of subjectKeyIdentifiers 293 contained in the set of SignerInfo objects of the CMS object. 295 o The set of resources contained in resources of the RTA MUST 296 exactly match the set of resources contained in the set of EE 297 certificates of the CMS object. 299 o The number of certificates in the CMS object MUST equal the number 300 of signerInfo objects in the CMS, and the subjectKeyidentifiers in 301 these certificates MUST match one and only one 302 subjectkeyidentifier of a signerinfo object. 304 7. Need for Canonicalization 306 As in [RFC5485] and [RFC8358] there is a need for canonicalization. 308 The following text is based on section 4 of [RFC8358] with changes to 309 remove references to internet-drafts and RFCs. 311 In general, the content is treated like a single octet string for the 312 generation of the digital signature. Unfortunately, text and HTML 313 files require canonicalization to avoid signature validation 314 problems. The primary concern is the manner in which different 315 operating systems indicate the end of a line of text. Some systems 316 use a single new-line character, other systems use the combination of 317 the carriage-return character followed by a line-feed character, and 318 other systems use fixed-length records padded with space characters. 319 For the digital signature to validate properly, a single convention 320 must be employed. 322 7.1. ASCII, UTF-8, and HTML File Canonicalization 324 The canonicalization procedure follows the conventions used for text 325 files in the File Transfer Protocol (FTP) [FTP]. Such files must be 326 supported by FTP implementations, so code reuse seems likely. 328 The canonicalization procedure converts the data from its internal 329 character representation to the standard 8-bit NVT-ASCII 330 representation (see TELNET [TELNET]). In accordance with the NVT 331 standard, the sequence MUST be used to denote the end of a 332 line of text. Using the standard NVT-ASCII representation means that 333 data MUST be interpreted as 8-bit bytes. 335 Trailing space characters MUST NOT appear on a line of text. That 336 is, the space character must not be followed by the sequence. 338 Thus, a blank line is represented solely by the sequence. 340 The form-feed nonprintable character (0x0C) is expected. 342 Other non-printable characters, such as tab and backspace, are not 343 expected, but they do occur. Non-printable or non-ASCII characters 344 (ones outside the range 0x20 to 0x7E) MUST NOT be changed in any way 345 not covered by the rules for end-of-line handling in the previous 346 paragraph. 348 Trailing blank lines MUST NOT appear at the end of the file. That 349 is, the file must not end with multiple consecutive sequences. 351 In some environments, a Byte Order Mark (BOM) (U+FEFF) is used at the 352 beginning of a file to indicate that it contains non-ASCII 353 characters. In UTF-8 or HTML files, a BOM at the beginning of the 354 file is not considered to be part of the file content. One or more 355 consecutive leading BOMs, if present, MUST NOT be processed by the 356 digital signature algorithm. 358 Any end-of-file marker used by an operating system is not considered 359 to be part of the file content. When present, such end-of-file 360 markers MUST NOT be processed by the digital signature algorithm. 362 Note: This text file canonicalization procedure is consistent with 363 the NVT-ASCII definition offered in Appendix B of RFC 5198 [UFNI]. 365 7.2. XML File Canonicalization 367 Utilities that produce XML files are expected to follow the guidance 368 provided by the World Wide Web Consortium (W3C) in Section 2.11 of 369 [R20081126]. If this guidance is followed, no canonicalization is 370 needed. 372 A robust signature generation process MAY perform canonicalization to 373 ensure that the W3C guidance has been followed. This guidance says 374 that a character MUST be used to denote the end of a line of 375 text within an XML file. Therefore, any two-character 376 sequence and any that is not followed by are to be 377 translated to a single character. 379 7.3. No Canonicalization of Other File Formats 381 No canonicalization is needed for file formats currently used or 382 planned other than ASCII, UTF-8, HTML, and XML files. Other file 383 formats, including PDF [PDF], PostScript [PS], and EPUB [EPUB] are 384 treated as a simple sequence of octets by the digital signature 385 algorithm. 387 8. Standalone Use 389 An RTA MAY include the set of certificates and CRL which permit the 390 RTA and the object which has been signed to be validated 391 cryptographically given a set of applicable trust anchors. The set 392 of certificates and CRLs must form a complete path from a trust 393 anchor to each end-entity certificate used to sign. 395 No publication protocol is specified, or expected. RTA objects are 396 standalone, and intended to be exchanged freely as attachments to 397 email or lodged in the web, or other mechanisms. 399 The EE certificates generated and used to sign MAY omit the Subject 400 Information Access (SIA) extension mandated by RFC 6487 as that 401 extension requires an rsync URI for the accessLocation form and the 402 RTA method does not require repository access via rsync. 404 An RTA and its associated EE certificates MAY appear on an RPKI 405 Manifest and MAY be published in a repository. 407 9. IANA Considerations 409 IANA is entirely off the hook on this one. 411 10. Security Considerations 413 Security is explicitly a consideration in the whole of this draft. 415 The intent is to make testable digital signatures over data to 416 associate the data with specific INR. 418 o If the private key of any RPKI certificate leaks, anyone could in 419 theory make signatures. 421 o The applicability of the INR to the INR in the data is not 422 specified. Validity is taken to mean the cryptographic validity 423 of the certification chains, and associated signatures. The 424 applicability of the specific RFC3779 resources to the signed data 425 is out of scope. 427 o Given the lack of constraint on signed objects, there is no 428 intention to have the signed object placed in a repository or 429 appear on a manifest, or in any other way interfere with the 430 operations of the distributed RPKI system. RTA objects themselves 431 may appear in repositories, and are constrained in size to the 432 ASN.1 encoded burden of the set of certificates which are 433 sufficient to describe the RFC3779 resources associated with the 434 signatures. 436 o By design, each signing party signs the RTA object discretely. 437 Since the RTA object includes the set of subjectKeyIdentifiers 438 there is partial closure over the question "who agrees to sign" 439 since the object is only valid if the set of signing parties 440 matches the list of expected signing keys. However, in principle 441 a sub-set (down to one) of these signing parties can assert an RTA 442 which specifies only that subset, or itself solely to sign, and 443 make a valid RTA which cannot be disproved. Since the RTA can 444 only refer to RFC3779 data which is within scope of the set of 445 signers, the impact of this is to refine (narrow down) the 446 relevant set of internet resources which can relate to the 447 (detached) signed object. However, this places the burden of 448 semantic validation of the meaning of those resources, 449 contextually, on the consumer. Caveat Emptor. 451 11. Acknowledgments 453 Russ Housely advised informally on the use of CMS signed objects 454 around 2012. 456 Russ's work on CMS signed internet drafts in [RFC8358] and [RFC5485] 457 has been re-purposed here to apply to arbitrary signed objects, not 458 just internet-drafts and text documents. 460 An early implementation of RTA was coded by Robert Loomans and Gary 461 Kennedy at APNIC before 2011 which used simpler ASN.1 semantics to 462 specify the signed object. 464 Jamie Gillespie (APNIC) provided valuable feedback and critique of 465 the 00 draft. 467 NLNet Labs implemented RTA in Krill and Routinator in 2021. 469 12. Revision history 471 o 00 draft initial upload from older text, inclusion of CMS 472 references. 474 o 01 draft explicit language for the lack of repository references, 475 use of CRL, spellcheck nits. 477 o 02 draft released with new code from NLNet, waking up the work 479 13. Normative References 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, 483 DOI 10.17487/RFC2119, March 1997, 484 . 486 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 487 Addresses and AS Identifiers", RFC 3779, 488 DOI 10.17487/RFC3779, June 2004, 489 . 491 [RFC5485] Housley, R., "Digital Signatures on Internet-Draft 492 Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009, 493 . 495 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 496 RFC 5652, DOI 10.17487/RFC5652, September 2009, 497 . 499 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 500 Template for the Resource Public Key Infrastructure 501 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 502 . 504 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 505 Algorithms and Key Sizes for Use in the Resource Public 506 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 507 August 2016, . 509 [RFC8358] Housley, R., "Update to Digital Signatures on Internet- 510 Draft Documents", RFC 8358, DOI 10.17487/RFC8358, March 511 2018, . 513 Authors' Addresses 515 George G. Michaelson 516 Asia Pacific Network Information Centre 517 6 Cordelia St 518 South Brisbane, QLD 4101 519 Australia 521 Email: ggm@apnic.net 522 Geoff Huston 523 Asia Pacific Network Information Centre 524 6 Cordelia St 525 South Brisbane, QLD 4101 526 Australia 528 Email: gih@apnic.net 530 Tom Harrison 531 Asia Pacific Network Information Centre 532 6 Cordelia St 533 South Brisbane, QLD 4101 534 Australia 536 Email: tomh@apnic.net 538 Tim Bruijnzeels 539 Open Netlabs B.V. 540 Science Park 400 541 Amsterdam 1098 XH 542 The Netherlands 544 Email: timb@opennetlabs.nl 546 Martin Hoffmann 547 Open Netlabs B.V. 548 Science Park 400 549 Amsterdam 1098 XH 550 The Netherlands 552 Email: martin@nlnetlabs.nl