idnits 2.17.1 draft-michaelson-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 (October 19, 2018) is 1988 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC6480' is mentioned on line 84, but not defined -- Looks like a reference, but probably isn't: '0' on line 180 -- Looks like a reference, but probably isn't: '1' on line 181 == Missing Reference: 'FTP' is mentioned on line 316, but not defined == Missing Reference: 'TELNET' is mentioned on line 321, but not defined == Missing Reference: 'UFNI' is mentioned on line 353, but not defined == Missing Reference: 'R20081126' is mentioned on line 359, but not defined == Missing Reference: 'PDF' is mentioned on line 373, but not defined == Missing Reference: 'PS' is mentioned on line 373, but not defined == Missing Reference: 'EPUB' is mentioned on line 373, 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 APNIC 5 Expires: April 22, 2019 T. Bruijnzeels 6 M. Hoffmann 7 opennetlabs 8 October 19, 2018 10 A profile for Resource Tagged Attestations (RTAs) 11 draft-michaelson-rpki-rta-00 13 Abstract 15 This document defines a Cryptographic Message Syntax (CMS) profile 16 for a general purpose Resource Tagged Attestation (RTA), for use with 17 the Resource Public Key Infrastructure (RPKI). The objective is to 18 allow an attestation, in the form of an arbitrary digital object, to 19 be signed "with resources", and for validation to provide an outcome 20 of "valid with resources". The profile is intended to provide for 21 the signing of an attestion with an arbitrary set of resources. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 22, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 59 3. RTA Profile . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. The RTA ContentType . . . . . . . . . . . . . . . . . . . . . 4 61 5. The RTA eContent . . . . . . . . . . . . . . . . . . . . . . 4 62 5.1. version . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5.2. subjectKeyIdentifiers . . . . . . . . . . . . . . . . . . 5 64 5.3. resources . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5.4. digestAlgorithm . . . . . . . . . . . . . . . . . . . . . 6 66 5.5. messageDigest . . . . . . . . . . . . . . . . . . . . . . 6 67 5.6. attestations . . . . . . . . . . . . . . . . . . . . . . 6 68 6. RTA Validation . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. Need for Canonicalization . . . . . . . . . . . . . . . . . . 7 70 7.1. ASCII, UTF-8, and HTML File Canonicalization . . . . . . 7 71 7.2. XML File Canonicalization . . . . . . . . . . . . . . . . 8 72 7.3. No Canonicalization of Other File Formats . . . . . . . . 8 73 8. Standalone Use . . . . . . . . . . . . . . . . . . . . . . . 8 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 77 12. Normative References . . . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 This document defines a Cryptographic Mesage Syntax (CMS) [RFC5652] 83 profile for a general purpose Resource Tagged Attestation (RTA), for 84 use with the Resource Public Key Infrastructure (RPKI) [RFC6480]. An 85 RTA allows an arbitrary digital object to be signed "with resources," 86 and for validation of the digital signature to provide an outcome of 87 "valid with resources." The profile is intended to provide for the 88 signing of a arbitrary attestion with a set of resources by the duly 89 delegated resource holder(s). 91 The RTA makes use of the template for RPKI Digitally Signed Objects 92 [RFC6488], which defines a CMS wrapper for the RTA content, as well 93 as a generic validation procedure for RPKI signed objects. However, 94 this specification does not comply to the profile in [RFC6488] in all 95 respects. This document describes the areas of difference to the 96 template profile, the ASN.1 syntax for the RTA eContent, and the 97 additional steps required to validate RTAs (in addition to the 98 validation steps specified in [RFC6488]. 100 An RTA is a detached signature CMS model, It leverages concepts 101 documented in [RFC8358] and [RFC5485]. Text from these RFCs has been 102 repurposed removing references to internet-drafts and RFCs since this 103 is a general detached signature signing model. 105 2. Conventions Used In This Document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119] when they 110 appear in ALL CAPS. These words may also appear in this document in 111 lower case as plain English words, absent their normative meanings. 113 3. RTA Profile 115 An RTA conforms to the template for RPKI Digitally Signed Objects 116 [RFC6488], with the exception that in order to allow for arbitrary 117 resource sets to be used to sign an RTA, it may be necessary to use 118 multiple signatures to sign an RTA. 120 The differences between this RTA profile and the profile specified by 121 the RPKI Digitally Signed Object template are as follows: 123 o Section 2.1 of [RFC6488] specifies a single SignerInfo object. An 124 RTA MAY contain more than one SignerInfo object. 126 o Section 2.1.4, and Section 3 of [RFC6488] specify that the 127 certificates field contains a single EE certificate. The 128 certificates field of an RTA contains precisely the same number of 129 EE certificates as there are SignerInfo objects in the RTA, where 130 each EE certificate is needed to validate the signature in each 131 SignerInfo. In addition, the certificates field MAY contain a 132 collection of CA certificates that would allow a RP to validate 133 the EE certificates. 135 o Section 2.1.5 of [RFC6488] specifies that the crls field be 136 omitted. For RTAs the crls field MUST contain the current CRL for 137 each CA certificate that has been included in the certificates 138 field of the RTA. 140 o Section 3 of [RFC6488] describes the signed object validation 141 checks that are to be performed by a Relying Party. Additional 142 validation checks for an RTA are required, as described in section 143 5 of this profile. 145 4. The RTA ContentType 147 The ContentType for a RTA is defined as resourceTaggedAttestation, 148 and has the numerical value of 1.2.840.113549.1.9.16.1.36 150 This OID MUST appear both within the eContentType in the 151 encapContentInfo object as well as the ContentType signed attribute 152 in the signerInfo object (see [RFC6488]). 154 5. The RTA eContent 156 The content of a RTA indicates that an arbitrary digital object has 157 been signed "with resources". A RTA is formally defined as: 159 ResourceTaggedAttestationDefinitions DEFINITIONS ::= 160 BEGIN 162 -- definition from rfc3029 163 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 164 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) 1 } 166 id-ct-resourceTaggedAttestation OBJECT IDENTIFIER ::= 167 { id-ct(1) 36 } 169 ResourceTaggedAttestation ::= SEQUENCE { 170 version [0] INTEGER DEFAULT 0, 171 subjectKeyIdentifers SubjectKeys, 172 resources ResourceBlock, 173 digestAlgorithm AlgorithmIdentifer, 174 messageDigest OCTET STRING } 176 SubjectKeys ::= SET SIZE (1..MAX) OF SubjectKeyIdentifier 177 -- defined in RFC5280 179 ResourceBlock ::= SEQUENCE { 180 asID [0] AsList OPTIONAL, 181 ipAddrBlocks [1] IPList OPTIONAL } 182 -- at least one of asID or ipAddrBlocks must be present 184 AsList ::= SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange 185 ASIdOrRange ::= CHOICE { 186 id ASId, 187 range ASRange } 189 ASRange ::= SEQUENCE { 190 min ASId, 191 max ASId } 193 ASId ::= INTEGER 195 IPList ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamily 197 IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI -- 198 addressFamily OCTET STRING (SIZE (2..3)), 199 addressesOrRanges SEQUENCE OF IPAddressOrRange } 201 IPAddressOrRange ::= CHOICE { 202 addressPrefix IPAddress, 203 addressRange IPAddressRange } 205 IPAddressRange ::= SEQUENCE { 206 min IPAddress, 207 max IPAddress } 209 IPAddress ::= BIT STRING 211 -- imported from [@!RFC5280] 212 AlgorithmIdentifer ::= SEQUENCE { 213 algorithm OBJECT IDENTIFIER, 214 parameters ANY DEFINED BY algorithm OPTIONAL } 215 END 217 Note that this content appears as the eContent within the 218 encapContentInfo (see [RFC6488]). 220 Note that AttestationSet is a SET OF EncapsulatedContentInfo from 221 [RFC5485] 223 5.1. version 225 The version number of the ResourceTaggedAttestation MUST be 0. 227 5.2. subjectKeyIdentifiers 229 The subjectKeyIdentifiers MUST be the set of SubjectKeyIdentifier 230 values contained in each of the EE certificates carried in the CMS 231 certificates field. 233 5.3. resources 235 The resources are contained here are the resources used to tag the 236 attestation, and MUST match the set of resources listed by the set of 237 EE certificates carried in the CMS certificates field. 239 The ordering of resources is defined in [RFC3779]. 241 5.4. digestAlgorithm 243 The digest algorithm used to create the message digest of the 244 attested digital object. This algorithm MUST be a hashing algorithm 245 defined in [RFC7935]. 247 5.5. messageDigest 249 The message digest of the attested digital object using the algorithm 250 specificed in the digestAlgorithm field. 252 5.6. attestations 254 The SET OF EncapsulatedContentInfo [RFC5485] which form the 255 individual digital signatures, made by each signing party. For each 256 instance in the set, one of the subjectKeyIdentifiers MUST identify a 257 certificate which can validate the signature. This means that there 258 will be an instance of a SignedData and SignerInfo for that 259 subjectKeyIdentifier (SignerInfo.sid) 261 the eContentType is id-ct-anyContentType, which refers to ANY octet 262 sequence. 264 6. RTA Validation 266 To validate a RTA the relying party MUST perform all the validation 267 checks specified in [RFC6488] as well as the following additional 268 RTA-specific validation steps. 270 o Canonicalization of the attested object MUST be performed. 272 o The message digest of the attested object using the digest 273 algorithm specified in the the digestAlgorithm field MUST be 274 calculated and MUST match the value given in the messageDigest 275 field of the RTA content. 277 o The signature verification process defined section 5.6 of 278 [RFC5652] MUST be performed for all public keys referenced in each 279 SignerInfo of the CMS. If any signature cannot be verified then 280 the RTA cannot be validated. 282 o The set of public keys contained in the subjectKeyIdentifers of 283 the RTA MUST exactly match the set of subjectKeyIdentifiers 284 contained in the set of SignerInfo objects of the CMS object. 286 o The set of resources contained in resources of the RTA MUST 287 exactly match the set of resources contained in the set of EE 288 certificates of the CMS object. 290 o The number of certificates in the CMS object MUST equal the number 291 of signerInfo objects in the CMS, and the subjectKeyidentifiers in 292 these certificates MUST match one and only one 293 subjectkeyidentifier of a signerinfo object. 295 7. Need for Canonicalization 297 As in [RFC5485] and [RFC8358] there is a need for canonicalization. 299 The following text is based on section 4 of [RFC8358] with changes to 300 remove references to internet-drafts and RFCs. 302 In general, the content is treated like a single octet string for the 303 generation of the digital signature. Unfortunately, text and HTML 304 files require canonicalization to avoid signature validation 305 problems. The primary concern is the manner in which different 306 operating systems indicate the end of a line of text. Some systems 307 use a single new-line character, other systems use the combination of 308 the carriage-return character followed by a line-feed character, and 309 other systems use fixed-length records padded with space characters. 310 For the digital signature to validate properly, a single convention 311 must be employed. 313 7.1. ASCII, UTF-8, and HTML File Canonicalization 315 The canonicalization procedure follows the conventions used for text 316 files in the File Transfer Protocol (FTP) [FTP]. Such files must be 317 supported by FTP implementations, so code reuse seems likely. 319 The canonicalization procedure converts the data from its internal 320 character representation to the standard 8-bit NVT-ASCII 321 representation (see TELNET [TELNET]). In accordance with the NVT 322 standard, the sequence MUST be used to denote the end of a 323 line of text. Using the standard NVT-ASCII representation means that 324 data MUST be interpreted as 8-bit bytes. 326 Trailing space characters MUST NOT appear on a line of text. That 327 is, the space character must not be followed by the sequence. 329 Thus, a blank line is represented solely by the sequence. 331 The form-feed nonprintable character (0x0C) is expected Other non- 332 printable characters, such as tab and backspace, are not expected, 333 but they do occur. Non-printable or non-ASCII characters (ones 334 outside the range 0x20 to 0x7E) MUST NOT be changed in any way not 335 covered by the rules for end-of-line handling in the previous 336 paragraph. 338 Trailing blank lines MUST NOT appear at the end of the file. That 339 is, the file must not end with multiple consecutive sequences. 341 In some environments, a Byte Order Mark (BOM) (U+FEFF) is used at the 342 beginning of a file to indicate that it contains non-ASCII 343 characters. In UTF-8 or HTML files, a BOM at the beginning of the 344 file is not considered to be part of the file content. One or more 345 consecutive leading BOMs, if present, MUST NOT be processed by the 346 digital signature algorithm. 348 Any end-of-file marker used by an operating system is not considered 349 to be part of the file content. When present, such end-of-file 350 markers MUST NOT be processed by the digital signature algorithm. 352 Note: This text file canonicalization procedure is consistent with 353 the NVT-ASCII definition offered in Appendix B of RFC 5198 [UFNI]. 355 7.2. XML File Canonicalization 357 Utilities that produce XML files are expected to follow the guidance 358 provided by the World Wide Web Consortium (W3C) in Section 2.11 of 359 [R20081126]. If this guidance is followed, no canonicalization is 360 needed. 362 A robust signature generation process MAY perform canonicalization to 363 ensure that the W3C guidance has been followed. This guidance says 364 that a character MUST be used to denote the end of a line of 365 text within an XML file. Therefore, any two-character 366 sequence and any that is not followed by are to be 367 translated to a single character. 369 7.3. No Canonicalization of Other File Formats 371 No canonicalization is needed for file formats currently used or 372 planned other than ASCII, UTF-8, HTML, and XML files. Other file 373 formats, including PDF [PDF], PostScript [PS], and EPUB [EPUB] are 374 treated as a simple sequence of octets by the digital signature 375 algorithm. 377 8. Standalone Use 379 The RTA MAY include the set of certificates which permit the RTA, and 380 the object which has been signed to be validated cryptographically 381 given a set of applicable trust anchors. 383 No publication protocol is specified, or expected. RTA objects are 384 standalone, and intended to be exchanged freely as attachments to 385 email or lodged in the web, or other mechanisms. 387 An RTA MAY appear on an RPKI Manifest and MAY be published in a 388 repository. 390 9. IANA Considerations 392 IANA is entirely off the hook on this one. 394 10. Security Considerations 396 Security is explicitly a consideration in the whole of this draft. 398 The intent is to make testable digital signatures over data to 399 associate the data with specific INR. 401 o If the private key of any RPKI certificate leaks, anyone could in 402 theory make signatures. 404 o The applicability of the INR to the INR in the data is not 405 specified. Validity is taken to mean the cryptographic validity 406 of the certification chains, and associated signatures. The 407 applicability of the specific RFC3779 resources to the signed data 408 is out of scope. 410 o Given the lack of constraint on signed objects, there is no 411 intention to have the signed object placed in a repository or 412 appear on a manifest, or in any other way interfere with the 413 operations of the distributed RPKI system. RTA objects themselves 414 may appear in repositories, and are constrained in size to the 415 ASN.1 encoded burden of the set of certificates which are 416 sufficient to describe the RFC3779 resources associated with the 417 signatures. 419 o By design, each signing party signs the RTA object discretely. 420 Since the RTA object includes the set of subjectKeyIdentifiers 421 there is partial closure over the question "who agrees to sign" 422 since the object is only valid if the set of signing parties 423 matches the list of expected signing keys. However, in principle 424 a sub-set (down to one) of these signing parties can assert an RTA 425 which specifies only that subset, or itself solely to sign, and 426 make a valid RTA which cannot be disproved. Since the RTA can 427 only refer to RFC3779 data which is within scope of the set of 428 signers, the impact of this is to refine (narrow down) the 429 relevant set of internet resources which can relate to the 430 (detached) signed object. However, this places the burden of 431 semantic validation of the meaning of those resources, 432 contextually, on the consumer. Caveat Emptor. 434 11. Acknowledgments 436 Russ Housely advised informally on the use of CMS signed objects 437 around 2012. 439 Russ's work on CMS signed internet drafts in [RFC8358] and [RFC5485] 440 has been re-purposed here to apply to arbitrary signed objects, not 441 just internet-drafts and text documents. 443 An early implementation of RTA was coded by Robert Loomans and Gary 444 Kennedy at APNIC before 2011 which used simpler ASN.1 semantics to 445 specify the signed object. 447 12. Normative References 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, 451 DOI 10.17487/RFC2119, March 1997, 452 . 454 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 455 Addresses and AS Identifiers", RFC 3779, 456 DOI 10.17487/RFC3779, June 2004, 457 . 459 [RFC5485] Housley, R., "Digital Signatures on Internet-Draft 460 Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009, 461 . 463 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 464 RFC 5652, DOI 10.17487/RFC5652, September 2009, 465 . 467 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 468 Template for the Resource Public Key Infrastructure 469 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 470 . 472 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 473 Algorithms and Key Sizes for Use in the Resource Public 474 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 475 August 2016, . 477 [RFC8358] Housley, R., "Update to Digital Signatures on Internet- 478 Draft Documents", RFC 8358, DOI 10.17487/RFC8358, March 479 2018, . 481 Authors' Addresses 483 George G. Michaelson 484 Asia Pacific Network Information Centre 485 6 Cordelia St 486 South Brisbane, QLD 4101 487 Australia 489 Email: ggm@apnic.net 491 Geoff Huston 492 Asia Pacific Network Information Centre 493 6 Cordelia St 494 South Brisbane, QLD 4101 495 Australia 497 Email: gih@apnic.net 499 Tim Bruijnzeels 500 Open Netlabs B.V. 501 Science Park 400 502 Amsterdam 1098 XH 503 The Netherlands 505 Email: timb@opennetlabs.nl 507 Martin Hoffmann 508 Open Netlabs B.V. 509 Science Park 400 510 Amsterdam 1098 XH 511 The Netherlands 513 Email: martin@nlnetlabs.nl