idnits 2.17.1 draft-ietf-sidrops-rpki-rsc-01.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 8, 2021) is 1144 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 313, 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 8, 2021 5 Expires: September 9, 2021 7 Resource Public Key Infrastructure (RPKI) object profile for Signed 8 Checklist (RSC) 9 draft-ietf-sidrops-rpki-rsc-01 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 9, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. RSC Profile and Distribution . . . . . . . . . . . . . . . . 3 67 3. The RSC ContentType . . . . . . . . . . . . . . . . . . . . . 3 68 4. The RSC eContent . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . 5 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 6 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 8 84 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 85 Appendix B. Document changelog - RFC EDITOR: REMOVE BEFORE 86 PUBLICATION . . . . . . . . . . . . . . . . . . . . 9 87 B.1. changes from -00 -> -01 . . . . . . . . . . . . . . . . . 9 88 B.2. individual submission phase . . . . . . . . . . . . . . . 9 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 This document defines a Cryptographic Message Syntax (CMS) [RFC5652] 94 profile for a general purpose listing of checksums (a 'checklist'), 95 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 193 END 195 4.1. version 197 The version number of the RpkiSignedChecklist MUST be 0. 199 4.2. resources 201 The resources contained here are the resources used to mark the 202 attestation, and MUST match the set of resources listed by the EE 203 certificate carried in the CMS certificates field. 205 4.3. digestAlgorithm 207 The digest algorithm used to create the message digest of the 208 attested digital object. This algorithm MUST be a hashing algorithm 209 defined in [RFC7935]. 211 4.4. checkList 213 This field is a sequence of FilenameAndHash objects. There is one 214 FilenameAndHash entry for each arbitrary object referenced on the 215 Signed Checklist. Each FilenameAndHash is an ordered pair of the 216 name of the directory entry containing the digital object and the 217 message digest of the digital object. The filename field is 218 OPTIONAL. 220 5. Operational Considerations 222 When creating digital objects of a plain-text nature (such as ASCII, 223 UTF-8, HTML, Javascript, XML, etc) it is RECOMMENDED to convert such 224 objects into a lossless compressed form. Distributing plain-text 225 objects within a compression envelope (such as GZIP [RFC1952]) might 226 help avoid unexpected canonicalization at intermediate systems (which 227 in turn would lead to checksum verification errors). Validator 228 implementations are expected to treat a checksummed digital object as 229 string of arbitrary single octets. 231 6. RSC Validation 233 To validate an RSC the relying party MUST perform all the validation 234 checks specified in [RFC6488] as well as the following additional 235 RSC-specific validation steps. 237 o The message digest of each referenced digital object, using the 238 digest algorithm specified in the the digestAlgorithm field, MUST 239 be calculated and MUST match the value given in the messageDigest 240 field of the associated FileAndHash, for the RSC entry to be 241 considered valid. 243 o If a filename field is present, the field's content MUST contain 244 only characters specified in the Portable Filename Character Set 245 as defined in [POSIX]. 247 7. Security Considerations 249 Relying parties are hereby warned that the data in a RPKI Signed 250 Checklist is self-asserted. These data have not been verified by the 251 Certificate Authority (CA) that issued the CA certificate to the 252 entity that issued the EE certificate used to validate the Signed 253 Checklist. 255 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 257 This section records the status of known implementations of the 258 protocol defined by this specification at the time of posting of this 259 Internet-Draft, and is based on a proposal described in RFC 7942. 260 The description of implementations in this section is intended to 261 assist the IETF in its decision processes in progressing drafts to 262 RFCs. Please note that the listing of any individual implementation 263 here does not imply endorsement by the IETF. Furthermore, no effort 264 has been spent to verify the information presented here that was 265 supplied by IETF contributors. This is not intended as, and must not 266 be construed to be, a catalog of available implementations or their 267 features. Readers are advised to note that other implementations may 268 exist. 270 According to RFC 7942, "this will allow reviewers and working groups 271 to assign due consideration to documents that have the benefit of 272 running code, which may serve as evidence of valuable experimentation 273 and feedback that have made the implemented protocols more mature. 274 It is up to the individual working groups to use this information as 275 they see fit". 277 o A signer and validator implementation [rpki-rsc-demo] based on 278 perl and OpenSSL was provided by Tom Harrison from APNIC. 280 o A validator implementation based on OpenBSD's rpki-client is 281 expected to be published after IANA Early Allocation of the OIDs. 283 9. IANA Considerations 284 9.1. OID 286 The IANA has registered the OID for the RPKI Signed Checklist in the 287 registry created by [RFC6488] as follows: 289 Name OID Specification 290 --------------------------------------------------------- 291 Checklists 1.2.840.113549.1.9.16.1.TBD [RFC-TBD] 293 9.2. File Extension 295 The IANA has added an item for the Signed Checklist file extension to 296 the "RPKI Repository Name Scheme" created by [RFC6481] as follows: 298 Filename Extension RPKI Object Reference 299 ----------------------------------------------------------- 300 .sig Signed Checklist [RFC-TBD] 302 9.3. Media Type 304 The IANA has registered the media type application/rpki-checklist as 305 follows: 307 Type name: application 308 Subtype name: rpki-checklist 309 Required parameters: None 310 Optional parameters: None 311 Encoding considerations: binary 312 Security considerations: Carries an RPKI Signed Checklist 313 [RFC-TBD]. 314 Interoperability considerations: None 315 Published specification: This document. 316 Applications that use this media type: RPKI operators. 317 Additional information: 318 Content: This media type is a signed object, as defined 319 in [RFC6488], which contains a payload of a list of 320 checksums as defined above in this document. 321 Magic number(s): None 322 File extension(s): .sig 323 Macintosh file type code(s): 324 Person & email address to contact for further information: 325 Job Snijders 326 Intended usage: COMMON 327 Restrictions on usage: None 328 Author: Job Snijders 329 Change controller: Job Snijders 331 10. References 333 10.1. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 341 RFC 5652, DOI 10.17487/RFC5652, September 2009, 342 . 344 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 345 Resource Certificate Repository Structure", RFC 6481, 346 DOI 10.17487/RFC6481, February 2012, 347 . 349 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 350 "Manifests for the Resource Public Key Infrastructure 351 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 352 . 354 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 355 Template for the Resource Public Key Infrastructure 356 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 357 . 359 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 360 Algorithms and Key Sizes for Use in the Resource Public 361 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 362 August 2016, . 364 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 365 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 366 May 2017, . 368 10.2. Informative References 370 [I-D.ietf-sidrops-rpki-rta] 371 Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T., 372 and M. Hoffmann, "A profile for Resource Tagged 373 Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work 374 in progress), January 2021. 376 [POSIX] IEEE and The Open Group, "The Open Group's Base 377 Specifications, Issue 7", 2016, 378 . 380 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", 381 RFC 1952, DOI 10.17487/RFC1952, May 1996, 382 . 384 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 385 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 386 February 2012, . 388 [rpki-rsc-demo] 389 Harrison, T., "A proof-of-concept for constructing and 390 validating RPKI Signed Checklists (RSCs).", February 2021, 391 . 393 [signify] Unangst, T. and M. Espie, "signify - cryptographically 394 sign and verify files", May 2014, 395 . 397 Appendix A. Acknowledgements 399 The author wishes to thank George Michaelson, Tom Harrison, Geoff 400 Huston, Randy Bush, Stephen Kent, Matt Lepinski, Rob Austein, Ted 401 Unangst, and Marc Espie for prior art. The author thanks Russ 402 Housley for reviewing the ASN.1 notation and providing suggestions. 403 The author would like to thank Nimrod Levy, Tom Harrison, Ben 404 Maddison, and Tim Bruijnzeels for document review and suggestions. 406 Appendix B. Document changelog - RFC EDITOR: REMOVE BEFORE PUBLICATION 408 B.1. changes from -00 -> -01 410 o Readability improvements 412 o Update document category to match the registry allocation policy 413 requirement. 415 B.2. individual submission phase 417 o On-the-wire change: the 'Filename' switched from 'required' to 418 'optional'. Some SIDROPS Working Group participants proposed a 419 checksum itself is the most minimal information required to 420 address digital objects. 422 Author's Address 423 Job Snijders 424 Fastly 425 Amsterdam 426 Netherlands 428 Email: job@fastly.com