idnits 2.17.1 draft-ietf-sidrops-rpki-rsc-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 (March 8, 2021) is 1116 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5911' is mentioned on line 148, but not defined == Missing Reference: 'RFC3779' is mentioned on line 153, but not defined -- Looks like a reference, but probably isn't: '0' on line 177 -- Looks like a reference, but probably isn't: '1' on line 178 == Missing Reference: 'RFC-TBD' is mentioned on line 304, 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: Informational March 8, 2021 5 Expires: September 9, 2021 7 RPKI Signed Checklists 8 draft-ietf-sidrops-rpki-rsc-00 10 Abstract 12 This document defines a Cryptographic Message Syntax (CMS) profile 13 for a general purpose listing of checksums (a 'checklist'), for use 14 with the Resource Public Key Infrastructure (RPKI). The objective is 15 to allow an attestation, in the form of a listing of one or more 16 checksums of arbitrary digital objects (files), to be signed "with 17 resources", and for validation to provide a means to confirm a 18 specific Internet Resource Holder produced the signed checklist. The 19 profile is intended to provide for the signing of a checksum listing 20 with an arbitrary set of Internet Number Resources. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 26 "OPTIONAL" in this document are to be interpreted as described in BCP 27 14 [RFC2119] [RFC8174] when, and only when, they appear in all 28 capitals, as shown here. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 9, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. RSC Profile and Distribution . . . . . . . . . . . . . . . . 3 66 3. The RSC ContentType . . . . . . . . . . . . . . . . . . . . . 3 67 4. The RSC eContent . . . . . . . . . . . . . . . . . . . . . . 3 68 4.1. version . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.2. resources . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.3. digestAlgorithm . . . . . . . . . . . . . . . . . . . . . 5 71 4.4. checkList . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Operational Considerations . . . . . . . . . . . . . . . . . 5 73 6. RSC Validation . . . . . . . . . . . . . . . . . . . . . . . 5 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 6 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 77 9.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 9.2. File Extension . . . . . . . . . . . . . . . . . . . . . 7 79 9.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 7 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 82 10.2. Informative References . . . . . . . . . . . . . . . . . 8 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 86 1. Introduction 88 This document defines a Cryptographic Message Syntax (CMS) [RFC5652] 89 profile for a general purpose listing of checksums (a 'checklist'), 90 for use with the Resource Public Key Infrastructure (RPKI) [RFC6480]. 91 The objective is to allow an attestation, in the form of a listing of 92 one or more checksums of arbitrary files, to be signed "with 93 resources", and for validation to provide a means to confirm a given 94 Internet Resource Holder produced the RPKI Signed Checklist (RSC). 96 The profile is intended to provide for the signing of a checksum 97 listing with an arbitrary set of Internet Number Resources. 99 RSC files are expected to facilitate Bring Your Own IP (BYOIP) 100 authentication, inter-domain interconnection provisioning, and 101 resource holdership verification processes. 103 The RSC concept borrows heavily from RTA [I-D.ietf-sidrops-rpki-rta], 104 Manifests [RFC6486], and OpenBSD's [signify] utility. The main 105 difference between RSC and RTA is that an RTA enables multiple 106 signers to attest a single anonymous digital object through a 107 checksum of its content, while an RSC allows a single signer to 108 attest the checksums of multiple named digital objects. This 109 difference is expected to represent a simplification for implementers 110 and operators. 112 2. RSC Profile and Distribution 114 RSC follows the Signed Object Template for the RPKI [RFC6488] with 115 one exception. Because RSCs MUST NOT be distributed through the 116 global RPKI repository system, the Subject Information Access (SIA) 117 extension is omitted from the RSC's X.509 EE certificate. 119 What constitutes suitable transport for RSC files is deliberately 120 unspecified. It might be a USB stick, a web interface secured with 121 conventional HTTPS, PGP-signed email, a T-shirt printed with a QR 122 code, or a carrier pigeon. 124 3. The RSC ContentType 126 The ContentType for an RSC is defined as rpkiSignedChecklist, and has 127 the numerical value of 1.2.840.113549.1.9.16.1.TBD. 129 This OID MUST appear both within the eContentType in the 130 encapContentInfo object as well as the ContentType signed attribute 131 in the signerInfo object (see [RFC6488]). 133 4. The RSC eContent 135 The content of an RSC indicates that an a checklist for arbitrary 136 named digital objects has been signed "with resources". An RSC is 137 formally defined as: 139 RpkiSignedChecklist-2021 140 { iso(1) member-body(2) us(840) rsadsi(113549) 141 pkcs(1) pkcs9(9) smime(16) mod(0) TBD } 143 DEFINITIONS EXPLICIT TAGS ::= 144 BEGIN 146 IMPORTS 147 CONTENT-TYPE, Digest, DigestAlgorithmIdentifier 148 FROM CryptographicMessageSyntax-2009 -- in [RFC5911] 149 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 150 pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } 152 ASIdOrRange, IPAddressFamily 153 FROM IPAddrAndASCertExtn -- in [RFC3779] 154 { iso(1) identified-organization(3) dod(6) internet(1) 155 security(5) mechanisms(5) pkix(7) mod(0) 156 id-mod-ip-addr-and-as-ident(30) } ; 158 ct-rpkiSignedChecklist CONTENT-TYPE ::= 159 { TYPE RpkiSignedChecklist IDENTIFIED BY 160 id-ct-signedChecklist } 162 id-ct-signedChecklist OBJECT IDENTIFIER ::= 163 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 164 pkcs-9(9) id-smime(16) id-ct(1) TBD } 166 RpkiSignedChecklist ::= SEQUENCE { 167 version [0] INTEGER DEFAULT 0, 168 resources ResourceBlock, 169 digestAlgorithm DigestAlgorithmIdentifier, 170 checkList SEQUENCE SIZE (1..MAX) OF FileAndHash } 172 FileAndHash ::= SEQUENCE { 173 file IA5String OPTIONAL, 174 hash Digest } 176 ResourceBlock ::= SEQUENCE { 177 asID [0] AsList OPTIONAL, 178 ipAddrBlocks [1] IPList OPTIONAL } 179 -- at least one of asID or ipAddrBlocks MUST be present 180 ( WITH COMPONENTS { ..., asID PRESENT} | 181 WITH COMPONENTS { ..., ipAddrBlocks PRESENT } ) 183 AsList ::= SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange 185 IPList ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamily 187 END 189 4.1. version 191 The version number of the RpkiSignedChecklist MUST be 0. 193 4.2. resources 195 The resources contained here are the resources used to mark the 196 attestation, and MUST match the set of resources listed by the EE 197 certificate carried in the CMS certificates field. 199 4.3. digestAlgorithm 201 The digest algorithm used to create the message digest of the 202 attested digital object. This algorithm MUST be a hashing algorithm 203 defined in [RFC7935]. 205 4.4. checkList 207 This field is a sequence of FileAndHash objects. There is one 208 FileAndHash entry for each arbitrary object referenced from the RSC. 209 Each FileAndHash is an ordered pair consisting an optional name of 210 the file containing the object, and the message digest of the digital 211 object. 213 5. Operational Considerations 215 When working with objects of a plain-text nature (ASCII, UTF-8, HTML, 216 Javascript, XML, etc) it is RECOMMENDED to distribute such objects in 217 a lossless compressed form, and sign the compressed form. Wrapping 218 plain-text objects in a compression envelope can help make those 219 appear as a single octet string to any intermediate systems, which 220 hopefully discourages in-transit modification of the file contents. 221 The use of lossless compression can help avoid checksum verification 222 errors. 224 6. RSC Validation 226 To validate an RSC the relying party MUST perform all the validation 227 checks specified in [RFC6488] as well as the following additional 228 RSC-specific validation steps. 230 o The message digest of each referenced digital object, using the 231 digest algorithm specified in the the digestAlgorithm field, MUST 232 be calculated and MUST match the value given in the messageDigest 233 field of the associated FileAndHash. 235 o If a filename is present, the filename MUST NOT contain a '/' 236 (slash) or '\' (backslash) character. 238 7. Security Considerations 240 Relying parties are hereby warned that the data in a RPKI Signed 241 Checklist is self-asserted. These data have not been verified by the 242 CA that issued the CA certificate to the entity that issued the EE 243 certificate used to validate the Signed Checklist. 245 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 247 This section records the status of known implementations of the 248 protocol defined by this specification at the time of posting of this 249 Internet-Draft, and is based on a proposal described in RFC 7942. 250 The description of implementations in this section is intended to 251 assist the IETF in its decision processes in progressing drafts to 252 RFCs. Please note that the listing of any individual implementation 253 here does not imply endorsement by the IETF. Furthermore, no effort 254 has been spent to verify the information presented here that was 255 supplied by IETF contributors. This is not intended as, and must not 256 be construed to be, a catalog of available implementations or their 257 features. Readers are advised to note that other implementations may 258 exist. 260 According to RFC 7942, "this will allow reviewers and working groups 261 to assign due consideration to documents that have the benefit of 262 running code, which may serve as evidence of valuable experimentation 263 and feedback that have made the implemented protocols more mature. 264 It is up to the individual working groups to use this information as 265 they see fit". 267 o A signer and validator implementation [rpki-rsc-demo] based on 268 perl and OpenSSL was provided by Tom Harrison from APNIC. 270 o A validator implementation based on OpenBSD's rpki-client is 271 expected to be published after IANA Early Allocation of the OIDs. 273 9. IANA Considerations 275 9.1. OID 277 The IANA has registered the OID for the RPKI Signed Checklist in the 278 registry created by [RFC6488] as follows: 280 Name OID Specification 281 --------------------------------------------------------- 282 Checklists 1.2.840.113549.1.9.16.1.TBD [RFC-TBD] 284 9.2. File Extension 286 The IANA has added an item for the signed Checklist file extension to 287 the "RPKI Repository Name Scheme" created by [RFC6481] as follows: 289 Filename Extension RPKI Object Reference 290 ----------------------------------------------------------- 291 .sig Signed Checklist [RFC-TBD] 293 9.3. Media Type 295 The IANA has registered the media type application/rpki-checklist as 296 follows: 298 Type name: application 299 Subtype name: rpki-checklist 300 Required parameters: None 301 Optional parameters: None 302 Encoding considerations: binary 303 Security considerations: Carries an RPKI Signed Checklist 304 [RFC-TBD]. 305 Interoperability considerations: None 306 Published specification: This document. 307 Applications that use this media type: RPKI operators. 308 Additional information: 309 Content: This media type is a signed object, as defined 310 in [RFC6488], which contains a payload of a list of 311 checksums as defined above in this document. 312 Magic number(s): None 313 File extension(s): .sig 314 Macintosh file type code(s): 315 Person & email address to contact for further information: 316 Job Snijders 317 Intended usage: COMMON 318 Restrictions on usage: None 319 Author: Job Snijders 320 Change controller: Job Snijders 322 10. References 324 10.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 332 RFC 5652, DOI 10.17487/RFC5652, September 2009, 333 . 335 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 336 Resource Certificate Repository Structure", RFC 6481, 337 DOI 10.17487/RFC6481, February 2012, 338 . 340 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 341 "Manifests for the Resource Public Key Infrastructure 342 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 343 . 345 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 346 Template for the Resource Public Key Infrastructure 347 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 348 . 350 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 351 Algorithms and Key Sizes for Use in the Resource Public 352 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 353 August 2016, . 355 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 356 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 357 May 2017, . 359 10.2. Informative References 361 [I-D.ietf-sidrops-rpki-rta] 362 Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T., 363 and M. Hoffmann, "A profile for Resource Tagged 364 Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work 365 in progress), January 2021. 367 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 368 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 369 February 2012, . 371 [rpki-rsc-demo] 372 Harrison, T., "A proof-of-concept for constructing and 373 validating RPKI Signed Checklists (RSCs).", February 2021, 374 . 376 [signify] Unangst, T. and M. Espie, "signify - cryptographically 377 sign and verify files", May 2014, 378 . 380 Appendix A. Acknowledgements 382 The author wishes to thank George Michaelson, Tom Harrison, Geoff 383 Huston, Randy Bush, Stephen Kent, Matt Lepinski, Rob Austein, Ted 384 Unangst, and Marc Espie for prior art. The author thanks Russ 385 Housley for reviewing the ASN.1 notation and providing suggestions. 386 The author would like to thank Nimrod Levy, Tom Harrison, Ben 387 Maddison, and Tim Bruijnzeels for document review and suggestions. 389 Author's Address 391 Job Snijders 392 Fastly 393 Amsterdam 394 Netherlands 396 Email: job@fastly.com