idnits 2.17.1 draft-ietf-sidrops-rpki-rsc-03.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 27, 2021) is 1063 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5911' is mentioned on line 162, but not defined -- Looks like a reference, but probably isn't: '0' on line 191 -- Looks like a reference, but probably isn't: '1' on line 192 == Missing Reference: 'RFC-TBD' is mentioned on line 401, but not defined ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snijders 3 Internet-Draft Fastly 4 Intended status: Standards Track T. Harrison 5 Expires: November 28, 2021 APNIC 6 B. Maddison 7 Workonline 8 May 27, 2021 10 Resource Public Key Infrastructure (RPKI) object profile for Signed 11 Checklist (RSC) 12 draft-ietf-sidrops-rpki-rsc-03 14 Abstract 16 This document defines a Cryptographic Message Syntax (CMS) profile 17 for a general purpose listing of checksums (a 'checklist'), for use 18 with the Resource Public Key Infrastructure (RPKI). The objective is 19 to allow an attestation, in the form of a listing of one or more 20 checksums of arbitrary digital objects (files), to be signed "with 21 resources", and for validation to provide a means to confirm a 22 specific Internet Resource Holder produced the Signed Checklist. The 23 profile is intended to provide for the signing of an arbitrary 24 checksum listing with a specific set of Internet Number Resources. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 30 "OPTIONAL" in this document are to be interpreted as described in BCP 31 14 [RFC2119] [RFC8174] when, and only when, they appear in all 32 capitals, as shown here. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 28, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. RSC Profile and Distribution . . . . . . . . . . . . . . . . 3 69 3. The RSC ContentType . . . . . . . . . . . . . . . . . . . . . 3 70 4. The RSC eContent . . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. version . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.2. resources . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.3. digestAlgorithm . . . . . . . . . . . . . . . . . . . . . 5 74 4.4. checkList . . . . . . . . . . . . . . . . . . . . . . . . 5 75 5. RSC Validation . . . . . . . . . . . . . . . . . . . . . . . 5 76 6. Operational Considerations . . . . . . . . . . . . . . . . . 6 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 78 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 7 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 9.1. SMI Security for S/MIME CMS Content Type 81 (1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . . 8 82 9.2. RPKI Signed Objects sub-registry . . . . . . . . . . . . 8 83 9.3. File Extension . . . . . . . . . . . . . . . . . . . . . 8 84 9.4. SMI Security for S/MIME Module Identifier 85 (1.2.840.113549.1.9.16.0) . . . . . . . . . . . . . . . . 9 86 9.5. Media Type . . . . . . . . . . . . . . . . . . . . . . . 9 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 89 10.2. Informative References . . . . . . . . . . . . . . . . . 10 90 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 91 Appendix B. Document changelog - RFC EDITOR: REMOVE BEFORE 92 PUBLICATION . . . . . . . . . . . . . . . . . . . . 11 93 B.1. changes from -02 -> -03 . . . . . . . . . . . . . . . . . 11 94 B.2. changes from -01 -> -02 . . . . . . . . . . . . . . . . . 11 95 B.3. changes from -00 -> -01 . . . . . . . . . . . . . . . . . 12 96 B.4. individual submission phase . . . . . . . . . . . . . . . 12 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 99 1. Introduction 101 This document defines a Cryptographic Message Syntax (CMS) [RFC5652] 102 profile for a general purpose listing of checksums (a 'checklist'), 103 for use with the Resource Public Key Infrastructure (RPKI) [RFC6480]. 104 The objective is to allow an attestation, in the form of a listing of 105 one or more checksums of arbitrary files, to be signed "with 106 resources", and for validation to provide a means to confirm a given 107 Internet Resource Holder produced the RPKI Signed Checklist (RSC). 108 The profile is intended to provide for the signing of a checksum 109 listing with a specific set of Internet Number Resources. 111 Signed Checklists are expected to facilitate inter-domain business 112 use-cases which depend on an ability to verify resource holdership. 113 RPKI-based validation processes are expected to become the industry 114 norm for automated Bring Your Own IP (BYOIP) on-boarding or 115 establishment of physical interconnection between Autonomous Systems. 117 The RSC concept borrows heavily from RTA [I-D.ietf-sidrops-rpki-rta], 118 Manifests [RFC6486], and OpenBSD's [signify] utility. The main 119 difference between RSC and RTA is that the RTA profile allows 120 multiple signers to attest a single digital object through a checksum 121 of its content, while the RSC profile allows a single signer to 122 attest the existence of multiple digital objects. A single signer 123 profile is considered a simplification for both implementers and 124 operators. 126 2. RSC Profile and Distribution 128 RSC follows the Signed Object Template for the RPKI [RFC6488] with 129 one exception. Because RSCs MUST NOT be distributed through the 130 global RPKI repository system, the Subject Information Access (SIA) 131 extension MUST be omitted from the RSC's X.509 EE certificate. 133 What constitutes suitable transport for RSC files is deliberately 134 unspecified. It might be a USB stick, a web interface secured with 135 conventional HTTPS, PGP-signed email, a T-shirt printed with a QR 136 code, or a carrier pigeon. 138 3. The RSC ContentType 140 The ContentType for an RSC is defined as rpkiSignedChecklist, and has 141 the numerical value of 1.2.840.113549.1.9.16.1.48. 143 This OID MUST appear both within the eContentType in the 144 encapContentInfo object as well as the ContentType signed attribute 145 in the signerInfo object (see [RFC6488]). 147 4. The RSC eContent 149 The content of an RSC indicates that a checklist for arbitrary 150 digital objects has been signed "with resources". An RSC is formally 151 defined as: 153 RpkiSignedChecklist-2021 154 { iso(1) member-body(2) us(840) rsadsi(113549) 155 pkcs(1) pkcs9(9) smime(16) mod(0) TBD } 157 DEFINITIONS EXPLICIT TAGS ::= 158 BEGIN 160 IMPORTS 161 CONTENT-TYPE, Digest, DigestAlgorithmIdentifier 162 FROM CryptographicMessageSyntax-2009 -- in [RFC5911] 163 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 164 pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } 166 ASIdOrRange, IPAddressOrRange 167 FROM IPAddrAndASCertExtn -- in [RFC3779] 168 { iso(1) identified-organization(3) dod(6) internet(1) 169 security(5) mechanisms(5) pkix(7) mod(0) 170 id-mod-ip-addr-and-as-ident(30) } ; 172 ct-rpkiSignedChecklist CONTENT-TYPE ::= 173 { TYPE RpkiSignedChecklist IDENTIFIED BY 174 id-ct-signedChecklist } 176 id-ct-signedChecklist OBJECT IDENTIFIER ::= 177 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 178 pkcs-9(9) id-smime(16) id-ct(1) 48 } 180 RpkiSignedChecklist ::= SEQUENCE { 181 version [0] INTEGER DEFAULT 0, 182 resources ResourceBlock, 183 digestAlgorithm DigestAlgorithmIdentifier, 184 checkList SEQUENCE SIZE (1..MAX) OF FileNameAndHash } 186 FileNameAndHash ::= SEQUENCE { 187 fileName IA5String OPTIONAL, 188 hash Digest } 190 ResourceBlock ::= SEQUENCE { 191 asID [0] AsList OPTIONAL, 192 ipAddrBlocks [1] IPList OPTIONAL } 193 -- at least one of asID or ipAddrBlocks MUST be present 194 ( WITH COMPONENTS { ..., asID PRESENT} | 195 WITH COMPONENTS { ..., ipAddrBlocks PRESENT } ) 197 AsList ::= SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange 199 IPList ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamilyItem 201 IPAddressFamilyItem ::= SEQUENCE { -- AFI & optional SAFI -- 202 addressFamily OCTET STRING (SIZE (2..3)), 203 iPAddressOrRange IPAddressOrRange } 205 END 207 4.1. version 209 The version number of the RpkiSignedChecklist MUST be 0. 211 4.2. resources 213 The resources contained here are the resources used to mark the 214 attestation, and MUST match the set of resources listed by the EE 215 certificate carried in the CMS certificates field. 217 4.3. digestAlgorithm 219 The digest algorithm used to create the message digest of the 220 attested digital object. This algorithm MUST be a hashing algorithm 221 defined in [RFC7935]. 223 4.4. checkList 225 This field is a sequence of FilenameAndHash objects. There is one 226 FilenameAndHash entry for each arbitrary object referenced on the 227 Signed Checklist. Each FilenameAndHash is an ordered pair of the 228 name of the directory entry containing the digital object and the 229 message digest of the digital object. The filename field is 230 OPTIONAL. 232 5. RSC Validation 234 Before a relying party can use an RSC to validate a set of digital 235 objects, the relying party MUST first validate the RSC. To validate 236 an RSC, the relying party MUST perform all the validation checks 237 specified in [RFC6488] as well as the following additional RSC- 238 specific validation steps. 240 o The IP address delegation extension [RFC3779] is present in the 241 end-entity (EE) certificate (contained within the RSC), and each 242 IP address prefix(es) in the RSC is contained within the set of IP 243 addresses specified by the EE certificate's IP address delegation 244 extension. 246 o For each FilenameAndHash entry in the RSC, if a filename field is 247 present, the field's content MUST contain only characters 248 specified in the Portable Filename Character Set as defined in 249 [POSIX]. 251 To validate a set of digital objects against an RSC: 253 o The message digest of each referenced digital object, using the 254 digest algorithm specified in the the digestAlgorithm field, MUST 255 be calculated and MUST match the value given in the messageDigest 256 field of the associated FilenameAndHash, for the digital object to 257 be considered valid as against the RSC. 259 6. Operational Considerations 261 When creating digital objects of a plain-text nature (such as ASCII, 262 UTF-8, HTML, Javascript, XML, etc) it is RECOMMENDED to convert such 263 objects into a lossless compressed form. Distributing plain-text 264 objects within a compression envelope (such as GZIP [RFC1952]) might 265 help avoid unexpected canonicalization at intermediate systems (which 266 in turn would lead to checksum verification errors). Validator 267 implementations are expected to treat a checksummed digital object as 268 string of arbitrary single octets. 270 If a filename field is present, but no referenced digital object has 271 a filename that matches the content of that field, a validator 272 implementation SHOULD compare the message digest of each digital 273 object to the value from the messageDigest field of the associated 274 FilenameAndHash, and report matches to the client for further 275 consideration. 277 7. Security Considerations 279 Relying parties are hereby warned that the data in a RPKI Signed 280 Checklist is self-asserted. When determining the meaning of any data 281 contained in an RPKI Signed Checklist, Relying Parties MUST NOT make 282 any assuptions about the signer beyond the fact that it had 283 sufficient control of the issuing CA to create the object. These 284 data have not been verified by the Certificate Authority (CA) that 285 issued the CA certificate to the entity that issued the EE 286 certificate used to validate the Signed Checklist. 288 RPKI Certificates are not bound to real world identities, see 289 [I-D.ymbk-sidrops-rpki-has-no-identity] for an elaboration. Relying 290 Parties can only associate real world entities to Internet Number 291 Resources by additionally consulting an exogenous authority. Signed 292 Checklists are a tool to communicate assertions 'signed with Internet 293 Number Resources', not about any other aspect of the resource 294 holder's business operations such as the identity of the resource 295 holder itself. 297 RSC objects are not distributed through the global RPKI repository 298 system, so whether a given CA is making use of them is not 299 immediately apparent from the state of the repository. However, 300 because RSC objects depend on EE certificates, and because all 301 existing applications for EE certificates involve their publication 302 in the repository, an observer may be able to infer indirectly from 303 the state of the repository that RSC objects are in use. For 304 example, if the CA sets the serial number on a new EE certificate to 305 be one greater than the serial number used for the previous EE 306 certificate, then an observer could infer that RSCs are in use if 307 there is a gap between serial numbers used in published EE 308 certificates. Similarly, if the CA includes an unpublished serial 309 number in a CRL, an observer could infer that an RSC object has been 310 revoked. 312 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 314 This section records the status of known implementations of the 315 protocol defined by this specification at the time of posting of this 316 Internet-Draft, and is based on a proposal described in RFC 7942. 317 The description of implementations in this section is intended to 318 assist the IETF in its decision processes in progressing drafts to 319 RFCs. Please note that the listing of any individual implementation 320 here does not imply endorsement by the IETF. Furthermore, no effort 321 has been spent to verify the information presented here that was 322 supplied by IETF contributors. This is not intended as, and must not 323 be construed to be, a catalog of available implementations or their 324 features. Readers are advised to note that other implementations may 325 exist. 327 According to RFC 7942, "this will allow reviewers and working groups 328 to assign due consideration to documents that have the benefit of 329 running code, which may serve as evidence of valuable experimentation 330 and feedback that have made the implemented protocols more mature. 331 It is up to the individual working groups to use this information as 332 they see fit". 334 o A signer and validator implementation [rpki-rsc-demo] written in 335 Perl based on OpenSSL was provided by Tom Harrison from APNIC. 337 o A signer implementation [rpkimancer] written in Python was 338 developed by Ben Maddison. 340 o Example .sig files were created by Job Snijders with the use of 341 OpenSSL. 343 o A validator implementation based on OpenBSD rpki-client and 344 LibreSSL was developed by Job Snijders. 346 9. IANA Considerations 348 9.1. SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) 350 The IANA has permanently allocated for this document in the SMI 351 Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) 352 registry: 354 Decimal Description References 355 --------------------------------------------------------------- 356 48 id-ct-signedChecklist [draft-ietf-sidrops-rpki-rsc] 358 Upon publication of this document, IANA is requested to reference the 359 RFC publication instead of this draft. 361 9.2. RPKI Signed Objects sub-registry 363 The IANA is requested to register the OID for the RPKI Signed 364 Checklist in the registry created by [RFC6488] as following: 366 Name OID Specification 367 ------------------------------------------------------------- 368 Signed Checklist 1.2.840.113549.1.9.16.1.48 [draft-ietf-sidrops-rpki-rsc] 370 9.3. File Extension 372 The IANA is requested to add an item for the Signed Checklist file 373 extension to the "RPKI Repository Name Scheme" registry created by 374 [RFC6481] as follows: 376 Filename Extension RPKI Object Reference 377 ----------------------------------------------------------------------- 378 .sig Signed Checklist [draft-ietf-sidrops-rpki-rsc] 380 9.4. SMI Security for S/MIME Module Identifier 381 (1.2.840.113549.1.9.16.0) 383 The IANA is requested to add an item to the "SMI Security for S/MIME 384 Module Identifier" registry as follows: 386 Decimal Description References 387 ------------------------------------------------------------------------- 388 TBD id-mod-rpkiSignedChecklist-2021 [draft-ietf-sidrops-rpki-rsc] 390 9.5. Media Type 392 The IANA is requested to register the media type application/rpki- 393 checklist in the Provisional Standard Media Type registry as follows: 395 Type name: application 396 Subtype name: rpki-checklist 397 Required parameters: None 398 Optional parameters: None 399 Encoding considerations: binary 400 Security considerations: Carries an RPKI Signed Checklist 401 [RFC-TBD]. 402 Interoperability considerations: None 403 Published specification: This document. 404 Applications that use this media type: RPKI operators. 405 Additional information: 406 Content: This media type is a signed object, as defined 407 in [RFC6488], which contains a payload of a list of 408 checksums as defined above in this document. 409 Magic number(s): None 410 File extension(s): .sig 411 Macintosh file type code(s): 412 Person & email address to contact for further information: 413 Job Snijders 414 Intended usage: COMMON 415 Restrictions on usage: None 416 Author: Job Snijders 417 Change controller: Job Snijders 419 10. References 421 10.1. Normative References 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 429 Addresses and AS Identifiers", RFC 3779, 430 DOI 10.17487/RFC3779, June 2004, 431 . 433 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 434 RFC 5652, DOI 10.17487/RFC5652, September 2009, 435 . 437 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 438 Resource Certificate Repository Structure", RFC 6481, 439 DOI 10.17487/RFC6481, February 2012, 440 . 442 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 443 "Manifests for the Resource Public Key Infrastructure 444 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 445 . 447 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 448 Template for the Resource Public Key Infrastructure 449 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 450 . 452 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 453 Algorithms and Key Sizes for Use in the Resource Public 454 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 455 August 2016, . 457 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 458 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 459 May 2017, . 461 10.2. Informative References 463 [I-D.ietf-sidrops-rpki-rta] 464 Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T., 465 and M. Hoffmann, "A profile for Resource Tagged 466 Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work 467 in progress), January 2021. 469 [I-D.ymbk-sidrops-rpki-has-no-identity] 470 Bush, R. and R. Housley, "The I in RPKI does not stand for 471 Identity", draft-ymbk-sidrops-rpki-has-no-identity-00 472 (work in progress), March 2021. 474 [POSIX] IEEE and The Open Group, "The Open Group's Base 475 Specifications, Issue 7", 2016, 476 . 478 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", 479 RFC 1952, DOI 10.17487/RFC1952, May 1996, 480 . 482 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 483 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 484 February 2012, . 486 [rpki-rsc-demo] 487 Harrison, T., "A proof-of-concept for constructing and 488 validating RPKI Signed Checklists (RSCs).", February 2021, 489 . 491 [rpkimancer] 492 Maddison, B., "rpkimancer", May 2021, 493 . 495 [signify] Unangst, T. and M. Espie, "signify - cryptographically 496 sign and verify files", May 2014, 497 . 499 Appendix A. Acknowledgements 501 The authors wish to thank George Michaelson, Tom Harrison, Geoff 502 Huston, Randy Bush, Stephen Kent, Matt Lepinski, Rob Austein, Ted 503 Unangst, and Marc Espie for prior art. The authors thank Russ 504 Housley for reviewing the ASN.1 notation and providing suggestions. 505 The authors would like to thank Nimrod Levy, and Tim Bruijnzeels for 506 document review and suggestions. 508 Appendix B. Document changelog - RFC EDITOR: REMOVE BEFORE PUBLICATION 510 B.1. changes from -02 -> -03 512 o Reference the IANA assigned OID 514 o Clarify validation rules 516 B.2. changes from -01 -> -02 518 o Clarify RSC is part of a puzzle, not panacea. Thanks Randy & Russ 520 B.3. changes from -00 -> -01 522 o Readability improvements 524 o Update document category to match the registry allocation policy 525 requirement. 527 B.4. individual submission phase 529 o On-the-wire change: the 'Filename' switched from 'required' to 530 'optional'. Some SIDROPS Working Group participants proposed a 531 checksum itself is the most minimal information required to 532 address digital objects. 534 Authors' Addresses 536 Job Snijders 537 Fastly 538 Amsterdam 539 Netherlands 541 Email: job@fastly.com 543 Tom Harrison 544 Asia Pacific Network Information Centre 545 6 Cordelia St 546 South Brisbane, QLD 4101 547 Australia 549 Email: tomh@apnic.net 551 Ben Maddison 552 Workonline Communications 553 Cape Town 554 South Africa 556 Email: benm@workonline.africa