idnits 2.17.1 draft-ietf-sidrops-rpki-rsc-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 (March 18, 2021) is 1128 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 155, but not defined == Missing Reference: 'RFC3779' is mentioned on line 160, but not defined -- Looks like a reference, but probably isn't: '0' on line 184 -- Looks like a reference, but probably isn't: '1' on line 185 == Missing Reference: 'RFC-TBD' is mentioned on line 327, but not defined ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 1 error (**), 0 flaws (~~), 4 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 March 18, 2021 5 Expires: September 19, 2021 7 Resource Public Key Infrastructure (RPKI) object profile for Signed 8 Checklist (RSC) 9 draft-ietf-sidrops-rpki-rsc-02 11 Abstract 13 This document defines a Cryptographic Message Syntax (CMS) profile 14 for a general purpose listing of checksums (a 'checklist'), for use 15 with the Resource Public Key Infrastructure (RPKI). The objective is 16 to allow an attestation, in the form of a listing of one or more 17 checksums of arbitrary digital objects (files), to be signed "with 18 resources", and for validation to provide a means to confirm a 19 specific Internet Resource Holder produced the Signed Checklist. The 20 profile is intended to provide for the signing of an arbitrary 21 checksum listing with a specific set of Internet Number Resources. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14 [RFC2119] [RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 19, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. RSC Profile and Distribution . . . . . . . . . . . . . . . . 3 67 3. The RSC ContentType . . . . . . . . . . . . . . . . . . . . . 3 68 4. The RSC eContent . . . . . . . . . . . . . . . . . . . . . . 4 69 4.1. version . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.2. resources . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.3. digestAlgorithm . . . . . . . . . . . . . . . . . . . . . 5 72 4.4. checkList . . . . . . . . . . . . . . . . . . . . . . . . 5 73 5. Operational Considerations . . . . . . . . . . . . . . . . . 5 74 6. RSC Validation . . . . . . . . . . . . . . . . . . . . . . . 6 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 6 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 9.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 9.2. File Extension . . . . . . . . . . . . . . . . . . . . . 7 80 9.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 7 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 83 10.2. Informative References . . . . . . . . . . . . . . . . . 9 84 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 85 Appendix B. Document changelog - RFC EDITOR: REMOVE BEFORE 86 PUBLICATION . . . . . . . . . . . . . . . . . . . . 10 87 B.1. changes from -01 -> -02 . . . . . . . . . . . . . . . . . 10 88 B.2. changes from -00 -> -01 . . . . . . . . . . . . . . . . . 10 89 B.3. individual submission phase . . . . . . . . . . . . . . . 10 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 92 1. Introduction 94 This document defines a Cryptographic Message Syntax (CMS) [RFC5652] 95 profile for a general purpose listing of checksums (a 'checklist'), 96 for use with the Resource Public Key Infrastructure (RPKI) [RFC6480]. 97 The objective is to allow an attestation, in the form of a listing of 98 one or more checksums of arbitrary files, to be signed "with 99 resources", and for validation to provide a means to confirm a given 100 Internet Resource Holder produced the RPKI Signed Checklist (RSC). 101 The profile is intended to provide for the signing of a checksum 102 listing with a specific set of Internet Number Resources. 104 Signed Checklists are expected to facilitate inter-domain business 105 use-cases which depend on an ability to verify resource holdership. 106 RPKI-based validation processes are expected to become the industry 107 norm for automated Bring Your Own IP (BYOIP) on-boarding or 108 establishment of physical interconnection between Autonomous Systems. 110 The RSC concept borrows heavily from RTA [I-D.ietf-sidrops-rpki-rta], 111 Manifests [RFC6486], and OpenBSD's [signify] utility. The main 112 difference between RSC and RTA is that the RTA profile allows 113 multiple signers to attest a single digital object through a checksum 114 of its content, while the RSC profile allows a single signer to 115 attest the existence of multiple digital objects. A single signer 116 profile is considered a simplification for both implementers and 117 operators. 119 2. RSC Profile and Distribution 121 RSC follows the Signed Object Template for the RPKI [RFC6488] with 122 one exception. Because RSCs MUST NOT be distributed through the 123 global RPKI repository system, the Subject Information Access (SIA) 124 extension is omitted from the RSC's X.509 EE certificate. 126 What constitutes suitable transport for RSC files is deliberately 127 unspecified. It might be a USB stick, a web interface secured with 128 conventional HTTPS, PGP-signed email, a T-shirt printed with a QR 129 code, or a carrier pigeon. 131 3. The RSC ContentType 133 The ContentType for an RSC is defined as rpkiSignedChecklist, and has 134 the numerical value of 1.2.840.113549.1.9.16.1.TBD. 136 This OID MUST appear both within the eContentType in the 137 encapContentInfo object as well as the ContentType signed attribute 138 in the signerInfo object (see [RFC6488]). 140 4. The RSC eContent 142 The content of an RSC indicates that a checklist for arbitrary 143 digital objects has been signed "with resources". An RSC is formally 144 defined as: 146 RpkiSignedChecklist-2021 147 { iso(1) member-body(2) us(840) rsadsi(113549) 148 pkcs(1) pkcs9(9) smime(16) mod(0) TBD } 150 DEFINITIONS EXPLICIT TAGS ::= 151 BEGIN 153 IMPORTS 154 CONTENT-TYPE, Digest, DigestAlgorithmIdentifier 155 FROM CryptographicMessageSyntax-2009 -- in [RFC5911] 156 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 157 pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } 159 ASIdOrRange, IPAddressFamily 160 FROM IPAddrAndASCertExtn -- in [RFC3779] 161 { iso(1) identified-organization(3) dod(6) internet(1) 162 security(5) mechanisms(5) pkix(7) mod(0) 163 id-mod-ip-addr-and-as-ident(30) } ; 165 ct-rpkiSignedChecklist CONTENT-TYPE ::= 166 { TYPE RpkiSignedChecklist IDENTIFIED BY 167 id-ct-signedChecklist } 169 id-ct-signedChecklist OBJECT IDENTIFIER ::= 170 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 171 pkcs-9(9) id-smime(16) id-ct(1) TBD } 173 RpkiSignedChecklist ::= SEQUENCE { 174 version [0] INTEGER DEFAULT 0, 175 resources ResourceBlock, 176 digestAlgorithm DigestAlgorithmIdentifier, 177 checkList SEQUENCE SIZE (1..MAX) OF FilenameAndHash } 179 FilenameAndHash ::= SEQUENCE { 180 filename IA5String OPTIONAL, 181 hash Digest } 183 ResourceBlock ::= SEQUENCE { 184 asID [0] AsList OPTIONAL, 185 ipAddrBlocks [1] IPList OPTIONAL } 186 -- at least one of asID or ipAddrBlocks MUST be present 187 ( WITH COMPONENTS { ..., asID PRESENT} | 188 WITH COMPONENTS { ..., ipAddrBlocks PRESENT } ) 190 AsList ::= SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange 192 IPList ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamily 194 END 196 4.1. version 198 The version number of the RpkiSignedChecklist MUST be 0. 200 4.2. resources 202 The resources contained here are the resources used to mark the 203 attestation, and MUST match the set of resources listed by the EE 204 certificate carried in the CMS certificates field. 206 4.3. digestAlgorithm 208 The digest algorithm used to create the message digest of the 209 attested digital object. This algorithm MUST be a hashing algorithm 210 defined in [RFC7935]. 212 4.4. checkList 214 This field is a sequence of FilenameAndHash objects. There is one 215 FilenameAndHash entry for each arbitrary object referenced on the 216 Signed Checklist. Each FilenameAndHash is an ordered pair of the 217 name of the directory entry containing the digital object and the 218 message digest of the digital object. The filename field is 219 OPTIONAL. 221 5. Operational Considerations 223 When creating digital objects of a plain-text nature (such as ASCII, 224 UTF-8, HTML, Javascript, XML, etc) it is RECOMMENDED to convert such 225 objects into a lossless compressed form. Distributing plain-text 226 objects within a compression envelope (such as GZIP [RFC1952]) might 227 help avoid unexpected canonicalization at intermediate systems (which 228 in turn would lead to checksum verification errors). Validator 229 implementations are expected to treat a checksummed digital object as 230 string of arbitrary single octets. 232 6. RSC Validation 234 To validate an RSC the relying party MUST perform all the validation 235 checks specified in [RFC6488] as well as the following additional 236 RSC-specific validation steps. 238 o The message digest of each referenced digital object, using the 239 digest algorithm specified in the the digestAlgorithm field, MUST 240 be calculated and MUST match the value given in the messageDigest 241 field of the associated FileAndHash, for the RSC entry to be 242 considered valid. 244 o If a filename field is present, the field's content MUST contain 245 only characters specified in the Portable Filename Character Set 246 as defined in [POSIX]. 248 7. Security Considerations 250 Relying parties are hereby warned that the data in a RPKI Signed 251 Checklist is self-asserted. When determining the meaning of any data 252 contained in an RPKI Signed Checklist, Relying Parties MUST NOT make 253 any assuptions about the signer beyond the fact that it had 254 sufficient control of the issuing CA to create the object. These 255 data have not been verified by the Certificate Authority (CA) that 256 issued the CA certificate to the entity that issued the EE 257 certificate used to validate the Signed Checklist. 259 RPKI Certificates are not bound to real world identities, see 260 [I-D.ymbk-sidrops-rpki-has-no-identity] for an elaboration. Relying 261 Parties can only associate real world entities to Internet Number 262 Resources by additionally consulting an exogenous authority. Signed 263 Checklists are a tool to communicate assertions 'signed with Internet 264 Number Resources', not about any other aspect of the resource 265 holder's business operations such as the identity of the resource 266 holder itself. 268 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 270 This section records the status of known implementations of the 271 protocol defined by this specification at the time of posting of this 272 Internet-Draft, and is based on a proposal described in RFC 7942. 273 The description of implementations in this section is intended to 274 assist the IETF in its decision processes in progressing drafts to 275 RFCs. Please note that the listing of any individual implementation 276 here does not imply endorsement by the IETF. Furthermore, no effort 277 has been spent to verify the information presented here that was 278 supplied by IETF contributors. This is not intended as, and must not 279 be construed to be, a catalog of available implementations or their 280 features. Readers are advised to note that other implementations may 281 exist. 283 According to RFC 7942, "this will allow reviewers and working groups 284 to assign due consideration to documents that have the benefit of 285 running code, which may serve as evidence of valuable experimentation 286 and feedback that have made the implemented protocols more mature. 287 It is up to the individual working groups to use this information as 288 they see fit". 290 o A signer and validator implementation [rpki-rsc-demo] based on 291 perl and OpenSSL was provided by Tom Harrison from APNIC. 293 o A validator implementation based on OpenBSD's rpki-client is 294 expected to be published after IANA Early Allocation of the OIDs. 296 9. IANA Considerations 298 9.1. OID 300 The IANA has registered the OID for the RPKI Signed Checklist in the 301 registry created by [RFC6488] as follows: 303 Name OID Specification 304 --------------------------------------------------------- 305 Checklists 1.2.840.113549.1.9.16.1.TBD [RFC-TBD] 307 9.2. File Extension 309 The IANA has added an item for the Signed Checklist file extension to 310 the "RPKI Repository Name Scheme" created by [RFC6481] as follows: 312 Filename Extension RPKI Object Reference 313 ----------------------------------------------------------- 314 .sig Signed Checklist [RFC-TBD] 316 9.3. Media Type 318 The IANA has registered the media type application/rpki-checklist as 319 follows: 321 Type name: application 322 Subtype name: rpki-checklist 323 Required parameters: None 324 Optional parameters: None 325 Encoding considerations: binary 326 Security considerations: Carries an RPKI Signed Checklist 327 [RFC-TBD]. 328 Interoperability considerations: None 329 Published specification: This document. 330 Applications that use this media type: RPKI operators. 331 Additional information: 332 Content: This media type is a signed object, as defined 333 in [RFC6488], which contains a payload of a list of 334 checksums as defined above in this document. 335 Magic number(s): None 336 File extension(s): .sig 337 Macintosh file type code(s): 338 Person & email address to contact for further information: 339 Job Snijders 340 Intended usage: COMMON 341 Restrictions on usage: None 342 Author: Job Snijders 343 Change controller: Job Snijders 345 10. References 347 10.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, 351 DOI 10.17487/RFC2119, March 1997, 352 . 354 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 355 RFC 5652, DOI 10.17487/RFC5652, September 2009, 356 . 358 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 359 Resource Certificate Repository Structure", RFC 6481, 360 DOI 10.17487/RFC6481, February 2012, 361 . 363 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 364 "Manifests for the Resource Public Key Infrastructure 365 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 366 . 368 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 369 Template for the Resource Public Key Infrastructure 370 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 371 . 373 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 374 Algorithms and Key Sizes for Use in the Resource Public 375 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 376 August 2016, . 378 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 379 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 380 May 2017, . 382 10.2. Informative References 384 [I-D.ietf-sidrops-rpki-rta] 385 Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T., 386 and M. Hoffmann, "A profile for Resource Tagged 387 Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work 388 in progress), January 2021. 390 [I-D.ymbk-sidrops-rpki-has-no-identity] 391 Bush, R. and R. Housley, "The I in RPKI does not stand for 392 Identity", draft-ymbk-sidrops-rpki-has-no-identity-00 393 (work in progress), March 2021. 395 [POSIX] IEEE and The Open Group, "The Open Group's Base 396 Specifications, Issue 7", 2016, 397 . 399 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", 400 RFC 1952, DOI 10.17487/RFC1952, May 1996, 401 . 403 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 404 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 405 February 2012, . 407 [rpki-rsc-demo] 408 Harrison, T., "A proof-of-concept for constructing and 409 validating RPKI Signed Checklists (RSCs).", February 2021, 410 . 412 [signify] Unangst, T. and M. Espie, "signify - cryptographically 413 sign and verify files", May 2014, 414 . 416 Appendix A. Acknowledgements 418 The author wishes to thank George Michaelson, Tom Harrison, Geoff 419 Huston, Randy Bush, Stephen Kent, Matt Lepinski, Rob Austein, Ted 420 Unangst, and Marc Espie for prior art. The author thanks Russ 421 Housley for reviewing the ASN.1 notation and providing suggestions. 422 The author would like to thank Nimrod Levy, Tom Harrison, Ben 423 Maddison, and Tim Bruijnzeels for document review and suggestions. 425 Appendix B. Document changelog - RFC EDITOR: REMOVE BEFORE PUBLICATION 427 B.1. changes from -01 -> -02 429 o Clarify RSC is part of a puzzle, not panacea. Thanks Randy & Russ 431 B.2. changes from -00 -> -01 433 o Readability improvements 435 o Update document category to match the registry allocation policy 436 requirement. 438 B.3. individual submission phase 440 o On-the-wire change: the 'Filename' switched from 'required' to 441 'optional'. Some SIDROPS Working Group participants proposed a 442 checksum itself is the most minimal information required to 443 address digital objects. 445 Author's Address 447 Job Snijders 448 Fastly 449 Amsterdam 450 Netherlands 452 Email: job@fastly.com