idnits 2.17.1 draft-ietf-sidrops-rpki-rta-00.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 (January 17, 2021) is 1188 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 206 -- Looks like a reference, but probably isn't: '1' on line 207 == Missing Reference: 'FTP' is mentioned on line 324, but not defined == Missing Reference: 'TELNET' is mentioned on line 329, but not defined == Missing Reference: 'UFNI' is mentioned on line 362, but not defined == Missing Reference: 'R20081126' is mentioned on line 368, but not defined == Missing Reference: 'PDF' is mentioned on line 382, but not defined == Missing Reference: 'PS' is mentioned on line 382, but not defined == Missing Reference: 'EPUB' is mentioned on line 382, 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: July 21, 2021 APNIC 6 T. Bruijnzeels 7 M. Hoffmann 8 nlnetlabs 9 January 17, 2021 11 A profile for Resource Tagged Attestations (RTAs) 12 draft-ietf-sidrops-rpki-rta-00 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 July 21, 2021. 41 Copyright Notice 43 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . 11 79 13. Normative References . . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 In the light of revisions to CMS and S/MIME, This ASN.1 is based on 159 principles from [RFC5911] ASN.1 itself is defined in [X.680] and 160 [X.690] 162 (in the below, TBD needs to be replaced with the properly assigned 163 OID reference) 165 The content of an RTA indicates that an arbitrary digital object has 166 been signed "with resources". An RTA is formally defined as: 168 ResourceTaggedAttestation-2021 169 { iso(1) member-body(2) us(840) rsadsi(113549) 170 pkcs(1) pkcs9(9) smime(16) mod(0) TBD } 172 DEFINITIONS EXPLICIT TAGS ::= 173 BEGIN 175 IMPORTS 176 CONTENT-TYPE, SubjectKeyIdentifier, 177 DigestAlgorithmIdentifier, Digest 178 FROM CryptographicMessageSyntax-2009 -- in [RFC5911] 179 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 180 pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } 182 ASIdOrRange, IPAddressFamily 183 FROM IPAddrAndASCertExtn -- in [RFC3779] 184 { iso(1) identified-organization(3) dod(6) internet(1) 185 security(5) mechanisms(5) pkix(7) mod(0) 186 id-mod-ip-addr-and-as-ident(30) } ; 188 ct-resourceTaggedAttestation CONTENT-TYPE ::= 189 { TYPE ResourceTaggedAttestation IDENTIFIED BY 190 id-ct-resourceTaggedAttestation } 192 id-ct-resourceTaggedAttestation OBJECT IDENTIFIER ::= 193 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 194 pkcs-9(9) id-smime(16) id-ct 36 } 196 ResourceTaggedAttestation ::= SEQUENCE { 197 version [0] INTEGER DEFAULT 0, 198 subjectKeyIdentifers SubjectKeys, 199 resources ResourceBlock, 200 digestAlgorithm DigestAlgorithmIdentifier, 201 messageDigest Digest } 203 SubjectKeys ::= SET SIZE (1..MAX) OF SubjectKeyIdentifier 205 ResourceBlock ::= SEQUENCE { 206 asID [0] AsList OPTIONAL, 207 ipAddrBlocks [1] IPList OPTIONAL } 208 -- at least one of asID or ipAddrBlocks MUST be present 209 ( WITH COMPONENTS { ..., asID PRESENT} | 210 WITH COMPONENTS { ..., ipAddrBlocks PRESENT } ) 212 AsList ::= SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange 214 IPList ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamily 216 END 218 Note that this content appears as the eContent within the 219 encapContentInfo (see [RFC6488]). 221 [TODO: this needs some work. The AttestationSet is from prior pre-00 222 state. What is this referring to?] 224 Note that AttestationSet is a SET OF EncapsulatedContentInfo from 225 [RFC5485] 227 5.1. version 229 The version number of the ResourceTaggedAttestation MUST be 0. 231 5.2. subjectKeyIdentifiers 233 The subjectKeyIdentifiers MUST be the set of SubjectKeyIdentifier 234 values contained in each of the EE certificates carried in the CMS 235 certificates field. 237 5.3. resources 239 The resources contained here are the resources used to tag the 240 attestation, and MUST match the set of resources listed by the set of 241 EE certificates carried in the CMS certificates field. 243 The ordering of resources is defined in [RFC3779]. 245 5.4. digestAlgorithm 247 The digest algorithm used to create the message digest of the 248 attested digital object. This algorithm MUST be a hashing algorithm 249 defined in [RFC7935]. 251 5.5. messageDigest 253 The message digest of the attested digital object using the algorithm 254 specified in the digestAlgorithm field. 256 5.6. attestations 258 The SET OF EncapsulatedContentInfo [RFC5485] which form the 259 individual digital signatures, made by each signing party. For each 260 instance in the set, one of the subjectKeyIdentifiers MUST identify a 261 certificate which can validate the signature. This means that there 262 will be an instance of a SignedData and SignerInfo for that 263 subjectKeyIdentifier (SignerInfo.sid) 265 The eContentType is id-ct-anyContentType, which refers to the ASN.1 266 ANY octet sequence. 268 6. RTA Validation 270 To validate an RTA the relying party MUST perform all the validation 271 checks specified in [RFC6488] as well as the following additional 272 RTA-specific validation steps. 274 o Canonicalization of the attested object MUST be performed. 276 o The message digest of the attested object using the digest 277 algorithm specified in the the digestAlgorithm field MUST be 278 calculated and MUST match the value given in the messageDigest 279 field of the RTA content. 281 o The signature verification process defined section 5.6 of 282 [RFC5652] MUST be performed for all public keys referenced in each 283 SignerInfo of the CMS. If any signature cannot be verified, then 284 the RTA MUST NOT be validated. This process includes CRL checks 285 which may require fetching from the CRLDP of any certificate 286 without an embedded CRL in the CMS which is current. 288 [TODO more text needed about CRL/CRLDP and handling expired CRLS] 290 o The set of public keys contained in the subjectKeyIdentifers of 291 the RTA MUST exactly match the set of subjectKeyIdentifiers 292 contained in the set of SignerInfo objects of the CMS object. 294 o The set of resources contained in resources of the RTA MUST 295 exactly match the set of resources contained in the set of EE 296 certificates of the CMS object. 298 o The number of certificates in the CMS object MUST equal the number 299 of signerInfo objects in the CMS, and the subjectKeyidentifiers in 300 these certificates MUST match one and only one 301 subjectkeyidentifier of a signerinfo object. 303 7. Need for Canonicalization 305 As in [RFC5485] and [RFC8358] there is a need for canonicalization. 307 The following text is based on section 4 of [RFC8358] with changes to 308 remove references to internet-drafts and RFCs. 310 In general, the content is treated like a single octet string for the 311 generation of the digital signature. Unfortunately, text and HTML 312 files require canonicalization to avoid signature validation 313 problems. The primary concern is the manner in which different 314 operating systems indicate the end of a line of text. Some systems 315 use a single new-line character, other systems use the combination of 316 the carriage-return character followed by a line-feed character, and 317 other systems use fixed-length records padded with space characters. 318 For the digital signature to validate properly, a single convention 319 must be employed. 321 7.1. ASCII, UTF-8, and HTML File Canonicalization 323 The canonicalization procedure follows the conventions used for text 324 files in the File Transfer Protocol (FTP) [FTP]. Such files must be 325 supported by FTP implementations, so code reuse seems likely. 327 The canonicalization procedure converts the data from its internal 328 character representation to the standard 8-bit NVT-ASCII 329 representation (see TELNET [TELNET]). In accordance with the NVT 330 standard, the sequence MUST be used to denote the end of a 331 line of text. Using the standard NVT-ASCII representation means that 332 data MUST be interpreted as 8-bit bytes. 334 Trailing space characters MUST NOT appear on a line of text. That 335 is, the space character must not be followed by the sequence. 337 Thus, a blank line is represented solely by the sequence. 339 The form-feed nonprintable character (0x0C) is expected. 341 Other non-printable characters, such as tab and backspace, are not 342 expected, but they do occur. Non-printable or non-ASCII characters 343 (ones outside the range 0x20 to 0x7E) MUST NOT be changed in any way 344 not covered by the rules for end-of-line handling in the previous 345 paragraph. 347 Trailing blank lines MUST NOT appear at the end of the file. That 348 is, the file must not end with multiple consecutive sequences. 350 In some environments, a Byte Order Mark (BOM) (U+FEFF) is used at the 351 beginning of a file to indicate that it contains non-ASCII 352 characters. In UTF-8 or HTML files, a BOM at the beginning of the 353 file is not considered to be part of the file content. One or more 354 consecutive leading BOMs, if present, MUST NOT be processed by the 355 digital signature algorithm. 357 Any end-of-file marker used by an operating system is not considered 358 to be part of the file content. When present, such end-of-file 359 markers MUST NOT be processed by the digital signature algorithm. 361 Note: This text file canonicalization procedure is consistent with 362 the NVT-ASCII definition offered in Appendix B of RFC 5198 [UFNI]. 364 7.2. XML File Canonicalization 366 Utilities that produce XML files are expected to follow the guidance 367 provided by the World Wide Web Consortium (W3C) in Section 2.11 of 368 [R20081126]. If this guidance is followed, no canonicalization is 369 needed. 371 A robust signature generation process MAY perform canonicalization to 372 ensure that the W3C guidance has been followed. This guidance says 373 that a character MUST be used to denote the end of a line of 374 text within an XML file. Therefore, any two-character 375 sequence and any that is not followed by are to be 376 translated to a single character. 378 7.3. No Canonicalization of Other File Formats 380 No canonicalization is needed for file formats currently used or 381 planned other than ASCII, UTF-8, HTML, and XML files. Other file 382 formats, including PDF [PDF], PostScript [PS], and EPUB [EPUB] are 383 treated as a simple sequence of octets by the digital signature 384 algorithm. 386 8. Standalone Use 388 An RTA MAY include the set of certificates and CRL which permit the 389 RTA and the object which has been signed to be validated 390 cryptographically given a set of applicable trust anchors. The set 391 of certificates and CRLs must form a complete path from a trust 392 anchor to each end-entity certificate used to sign. 394 No publication protocol is specified, or expected. RTA objects are 395 standalone, and intended to be exchanged freely as attachments to 396 email or lodged in the web, or other mechanisms. 398 The EE certificates generated and used to sign MAY omit the Subject 399 Information Access (SIA) extension mandated by RFC 6487 as that 400 extension requires an rsync URI for the accessLocation form and the 401 RTA method does not require repository access via rsync. 403 An RTA and its associated EE certificates MAY appear on an RPKI 404 Manifest and MAY be published in a repository. 406 9. IANA Considerations 408 IANA is entirely off the hook on this one. 410 10. Security Considerations 412 Security is explicitly a consideration in the whole of this draft. 414 The intent is to make testable digital signatures over data to 415 associate the data with specific INR. 417 o If the private key of any RPKI certificate leaks, anyone could in 418 theory make signatures. 420 o The applicability of the INR to the INR in the data is not 421 specified. Validity is taken to mean the cryptographic validity 422 of the certification chains, and associated signatures. The 423 applicability of the specific RFC3779 resources to the signed data 424 is out of scope. 426 o Given the lack of constraint on signed objects, there is no 427 intention to have the signed object placed in a repository or 428 appear on a manifest, or in any other way interfere with the 429 operations of the distributed RPKI system. RTA objects themselves 430 may appear in repositories, and are constrained in size to the 431 ASN.1 encoded burden of the set of certificates which are 432 sufficient to describe the RFC3779 resources associated with the 433 signatures. 435 o By design, each signing party signs the RTA object discretely. 436 Since the RTA object includes the set of subjectKeyIdentifiers 437 there is partial closure over the question "who agrees to sign" 438 since the object is only valid if the set of signing parties 439 matches the list of expected signing keys. However, in principle 440 a sub-set (down to one) of these signing parties can assert an RTA 441 which specifies only that subset, or itself solely to sign, and 442 make a valid RTA which cannot be disproved. Since the RTA can 443 only refer to RFC3779 data which is within scope of the set of 444 signers, the impact of this is to refine (narrow down) the 445 relevant set of internet resources which can relate to the 446 (detached) signed object. However, this places the burden of 447 semantic validation of the meaning of those resources, 448 contextually, on the consumer. Caveat Emptor. 450 11. Acknowledgments 452 Russ Housely advised informally on the use of CMS signed objects 453 around 2012. 455 Russ's work on CMS signed internet drafts in [RFC8358] and [RFC5485] 456 has been re-purposed here to apply to arbitrary signed objects, not 457 just internet-drafts and text documents. 459 An early implementation of RTA was coded by Robert Loomans and Gary 460 Kennedy at APNIC before 2011 which used simpler ASN.1 semantics to 461 specify the signed object. 463 Jamie Gillespie (APNIC) provided valuable feedback and critique of 464 the 00 draft. 466 NLNet Labs implemented RTA in Krill and Routinator in 2021. 468 In early 2021 Russ provided newer ASN.1 aligned with the revised CMS 469 and S/MIME, maintaining backwards (on-the-wire) compatibility with 470 existing implementations. 472 12. Revision history 474 o 00 draft initial upload from older text, inclusion of CMS 475 references. 477 o 01 draft explicit language for the lack of repository references, 478 use of CRL, spellcheck nits. 480 o 02 draft released with new code from NLNet, waking up the work. 482 o 00 modifications to ASN.1 from Russ Housely, WG adoption. 484 13. Normative References 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, 488 DOI 10.17487/RFC2119, March 1997, 489 . 491 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 492 Addresses and AS Identifiers", RFC 3779, 493 DOI 10.17487/RFC3779, June 2004, 494 . 496 [RFC5485] Housley, R., "Digital Signatures on Internet-Draft 497 Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009, 498 . 500 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 501 RFC 5652, DOI 10.17487/RFC5652, September 2009, 502 . 504 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 505 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 506 DOI 10.17487/RFC5911, June 2010, 507 . 509 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 510 Template for the Resource Public Key Infrastructure 511 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 512 . 514 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 515 Algorithms and Key Sizes for Use in the Resource Public 516 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 517 August 2016, . 519 [RFC8358] Housley, R., "Update to Digital Signatures on Internet- 520 Draft Documents", RFC 8358, DOI 10.17487/RFC8358, March 521 2018, . 523 [X.680] International Telecommunications Union, "Information 524 technology -- Abstract Syntax Notation One (ASN.1): 525 Specification of basic notation", ITU-T Recommendation 526 X.680, August 2015. 528 [X.690] International Telecommunications Union, "Information 529 technology -- ASN.1 encoding rules: Specification of Basic 530 Encoding Rules (BER), Canonical Encoding Rules (CER) and 531 Distinguished Encoding Rules (DER)", ITU-T Recommendation 532 X.690, August 2015. 534 Authors' Addresses 536 George G. Michaelson 537 Asia Pacific Network Information Centre 538 6 Cordelia St 539 South Brisbane, QLD 4101 540 Australia 542 Email: ggm@apnic.net 544 Geoff Huston 545 Asia Pacific Network Information Centre 546 6 Cordelia St 547 South Brisbane, QLD 4101 548 Australia 550 Email: gih@apnic.net 552 Tom Harrison 553 Asia Pacific Network Information Centre 554 6 Cordelia St 555 South Brisbane, QLD 4101 556 Australia 558 Email: tomh@apnic.net 559 Tim Bruijnzeels 560 NLNet Labs B.V. 561 Science Park 400 562 Amsterdam 1098 XH 563 The Netherlands 565 Email: timb@nlnetlabs.nl 567 Martin Hoffmann 568 NLNet Labs B.V. 569 Science Park 400 570 Amsterdam 1098 XH 571 The Netherlands 573 Email: martin@nlnetlabs.nl