idnits 2.17.1 draft-ietf-sidrops-rpki-rsc-05.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 (11 August 2021) is 982 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: 'RFC6268' is mentioned on line 171, but not defined -- Looks like a reference, but probably isn't: '0' on line 200 -- Looks like a reference, but probably isn't: '1' on line 201 == Missing Reference: 'RFC-TBD' is mentioned on line 433, 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: 12 February 2022 APNIC 6 B. Maddison 7 Workonline 8 11 August 2021 10 Resource Public Key Infrastructure (RPKI) object profile for Signed 11 Checklist (RSC) 12 draft-ietf-sidrops-rpki-rsc-05 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 12 February 2022. 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 (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. RSC Profile and Distribution . . . . . . . . . . . . . . . . 3 68 2.1. RSC End-Entity Certificates . . . . . . . . . . . . . . . 4 69 3. The RSC ContentType . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5. RSC Validation . . . . . . . . . . . . . . . . . . . . . . . 6 76 6. Operational Considerations . . . . . . . . . . . . . . . . . 7 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 8. Implementation status . . . . . . . . . . . . . . . . . . . . 8 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 9.1. SMI Security for S/MIME CMS Content Type 81 (1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . . 9 82 9.2. RPKI Signed Objects sub-registry . . . . . . . . . . . . 9 83 9.3. File Extension . . . . . . . . . . . . . . . . . . . . . 10 84 9.4. SMI Security for S/MIME Module Identifier 85 (1.2.840.113549.1.9.16.0) . . . . . . . . . . . . . . . . 10 86 9.5. Media Type . . . . . . . . . . . . . . . . . . . . . . . 10 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 89 10.2. Informative References . . . . . . . . . . . . . . . . . 12 90 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 91 Appendix B. Document changelog . . . . . . . . . . . . . . . . . 13 92 B.1. changes from -04 -> -05 . . . . . . . . . . . . . . . . . 13 93 B.2. changes from -03 -> -04 . . . . . . . . . . . . . . . . . 13 94 B.3. changes from -02 -> -03 . . . . . . . . . . . . . . . . . 13 95 B.4. changes from -01 -> -02 . . . . . . . . . . . . . . . . . 14 96 B.5. changes from -00 -> -01 . . . . . . . . . . . . . . . . . 14 97 B.6. individual submission phase . . . . . . . . . . . . . . . 14 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 100 1. Introduction 102 This document defines a Cryptographic Message Syntax (CMS) [RFC5652] 103 profile for a general purpose listing of checksums (a 'checklist'), 104 for use with the Resource Public Key Infrastructure (RPKI) [RFC6480]. 105 The objective is to allow an attestation, in the form of a listing of 106 one or more checksums of arbitrary files, to be signed "with 107 resources", and for validation to provide a means to confirm a given 108 Internet Resource Holder produced the RPKI Signed Checklist (RSC). 109 The profile is intended to provide for the signing of a checksum 110 listing with a specific set of Internet Number Resources. 112 Signed Checklists are expected to facilitate inter-domain business 113 use-cases which depend on an ability to verify resource holdership. 114 RPKI-based validation processes are expected to become the industry 115 norm for automated Bring Your Own IP (BYOIP) on-boarding or 116 establishment of physical interconnection between Autonomous Systems. 118 The RSC concept borrows heavily from RTA [I-D.ietf-sidrops-rpki-rta], 119 Manifests [RFC6486], and OpenBSD's [signify] utility. The main 120 difference between RSC and RTA is that the RTA profile allows 121 multiple signers to attest a single digital object through a checksum 122 of its content, while the RSC profile allows a single signer to 123 attest the existence of multiple digital objects. A single signer 124 profile is considered a simplification for both implementers and 125 operators. 127 2. RSC Profile and Distribution 129 RSC follows the Signed Object Template for the RPKI [RFC6488] with 130 one exception. Because RSCs MUST NOT be distributed through the 131 global RPKI Repository system, the Subject Information Access (SIA) 132 extension MUST be omitted from the RSC's X.509 End-Entity (EE) 133 certificate. 135 What constitutes suitable transport for RSC files is deliberately 136 unspecified. It might be a USB stick, a web interface secured with 137 conventional HTTPS, PGP-signed email, a T-shirt printed with a QR 138 code, or a carrier pigeon. 140 2.1. RSC End-Entity Certificates 142 The CA MUST only sign one RSC with each EE Certificate, and MUST 143 generate a new key pair for each new RSC. This form of use of the 144 associated EE Certificate is termed a "one-time-use" EE certificate 145 Section 3 of [RFC6487]. 147 3. The RSC ContentType 149 The ContentType for an RSC is defined as rpkiSignedChecklist, and has 150 the numerical value of 1.2.840.113549.1.9.16.1.48. 152 This OID MUST appear both within the eContentType in the 153 encapContentInfo object as well as the ContentType signed attribute 154 in the signerInfo object (see [RFC6488]). 156 4. The RSC eContent 158 The content of an RSC indicates that a checklist for arbitrary 159 digital objects has been signed "with resources". An RSC is formally 160 defined as: 162 RpkiSignedChecklist-2021 163 { iso(1) member-body(2) us(840) rsadsi(113549) 164 pkcs(1) pkcs9(9) smime(16) mod(0) TBD } 166 DEFINITIONS EXPLICIT TAGS ::= 167 BEGIN 169 IMPORTS 170 CONTENT-TYPE, Digest, DigestAlgorithmIdentifier 171 FROM CryptographicMessageSyntax-2010 -- in [RFC6268] 172 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 173 pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } 175 ASIdOrRange, IPAddressOrRange 176 FROM IPAddrAndASCertExtn -- in [RFC3779] 177 { iso(1) identified-organization(3) dod(6) internet(1) 178 security(5) mechanisms(5) pkix(7) mod(0) 179 id-mod-ip-addr-and-as-ident(30) } ; 181 ct-rpkiSignedChecklist CONTENT-TYPE ::= 182 { TYPE RpkiSignedChecklist IDENTIFIED BY 183 id-ct-signedChecklist } 185 id-ct-signedChecklist OBJECT IDENTIFIER ::= 186 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 187 pkcs-9(9) id-smime(16) id-ct(1) 48 } 189 RpkiSignedChecklist ::= SEQUENCE { 190 version [0] INTEGER DEFAULT 0, 191 resources ResourceBlock, 192 digestAlgorithm DigestAlgorithmIdentifier, 193 checkList SEQUENCE SIZE (1..MAX) OF FileNameAndHash } 195 FileNameAndHash ::= SEQUENCE { 196 fileName IA5String OPTIONAL, 197 hash Digest } 199 ResourceBlock ::= SEQUENCE { 200 asID [0] AsList OPTIONAL, 201 ipAddrBlocks [1] IPList OPTIONAL } 202 -- at least one of asID or ipAddrBlocks MUST be present 203 ( WITH COMPONENTS { ..., asID PRESENT} | 204 WITH COMPONENTS { ..., ipAddrBlocks PRESENT } ) 206 AsList ::= SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange 208 IPList ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamilyItem 210 IPAddressFamilyItem ::= SEQUENCE { -- AFI & optional SAFI -- 211 addressFamily OCTET STRING (SIZE (2..3)), 212 iPAddressOrRange IPAddressOrRange } 214 END 216 4.1. version 218 The version number of the RpkiSignedChecklist MUST be 0. 220 4.2. resources 222 The resources contained here are the resources used to mark the 223 attestation, and MUST match the set of resources listed by the EE 224 Certificate carried in the CMS certificates field. 226 4.3. digestAlgorithm 228 The digest algorithm used to create the message digest of the 229 attested digital object. This algorithm MUST be a hashing algorithm 230 defined in [RFC7935]. 232 4.4. checkList 234 This field is a sequence of FileNameAndHash objects. There is one 235 FileNameAndHash entry for each arbitrary object referenced on the 236 Signed Checklist. Each FileNameAndHash is an ordered pair of the 237 name of the directory entry containing the digital object and the 238 message digest of the digital object. The filename field is 239 OPTIONAL. 241 5. RSC Validation 243 Before a Relying Party can use an RSC to validate a set of digital 244 objects, the Relying Party MUST first validate the RSC. To validate 245 an RSC, the Relying Party MUST perform all the validation checks 246 specified in [RFC6488] (except checking for the presence of a SIA 247 extension), and perform the following additional RSC-specific 248 validation steps: 250 1. The RSC specification deviates from Section 4.8.8.2 of [RFC6487], 251 the Subject Information Access extension MUST NOT be present on 252 the End-Entity (EE) certificate signing the RSC. 254 2. The IP Addresses and AS Identifiers extension [RFC3779] is 255 present in the end-entity (EE) certificate (contained within the 256 RSC), and each IP address prefix(es) and/or AS Identifier(s) in 257 the RSC is contained within the set of IP addresses specified by 258 the EE Certificate's IP Addresses and AS Identifiers delegation 259 extension. 261 3. For each FileNameAndHash entry in the RSC, if a filename field is 262 present, the field's content MUST contain only characters 263 specified in the Portable Filename Character Set as defined in 264 [POSIX]. 266 To validate a set of digital objects against an RSC: 268 * The message digest of each referenced digital object, using the 269 digest algorithm specified in the the digestAlgorithm field, MUST 270 be calculated and MUST match the value given in the messageDigest 271 field of the associated FileNameAndHash, for the digital object to 272 be considered valid as against the RSC. 274 6. Operational Considerations 276 When creating digital objects of a plain-text nature (such as ASCII, 277 UTF-8, HTML, Javascript, XML, etc) it is RECOMMENDED to convert such 278 objects into a lossless compressed form. Distributing plain-text 279 objects within a compression envelope (such as GZIP [RFC1952]) might 280 help avoid unexpected canonicalization at intermediate systems (which 281 in turn would lead to checksum verification errors). Validator 282 implementations are expected to treat a checksummed digital object as 283 string of arbitrary single octets. 285 If a filename field is present, but no referenced digital object has 286 a filename that matches the content of that field, a validator 287 implementation SHOULD compare the message digest of each digital 288 object to the value from the messageDigest field of the associated 289 FileNameAndHash, and report matches to the client for further 290 consideration. 292 7. Security Considerations 294 Relying parties are hereby warned that the data in a RPKI Signed 295 Checklist is self-asserted. When determining the meaning of any data 296 contained in an RPKI Signed Checklist, Relying Parties MUST NOT make 297 any assuptions about the signer beyond the fact that it had 298 sufficient control of the issuing CA to create the object. These 299 data have not been verified by the Certificate Authority (CA) that 300 issued the CA certificate to the entity that issued the EE 301 Certificate used to validate the Signed Checklist. 303 RPKI Certificates are not bound to real world identities, see 304 [I-D.ymbk-sidrops-rpki-has-no-identity] for an elaboration. Relying 305 Parties can only associate real world entities to Internet Number 306 Resources by additionally consulting an exogenous authority. Signed 307 Checklists are a tool to communicate assertions 'signed with Internet 308 Number Resources', not about any other aspect of the resource 309 holder's business operations such as the identity of the resource 310 holder itself. 312 RSC objects are not distributed through the RPKI Repository system. 313 From this, it follows that third parties who do not have a copy of a 314 given RSC, may not be aware of the existence of that RSC. Since RSC 315 objects use EE Certificates, but all other currently defined types of 316 RPKI object profiles are published in public CA repositories, an 317 observer may infer from discrepancies in the Repository that RSC 318 object(s) may exist. For example, if a CA does not use random serial 319 numbers for Certificates, an observer could detect gaps between the 320 serial numbers of the published EE Certificates. Similarly, if the 321 CA includes a serial number on a CRL that does not match any 322 published object, an observer could postulate an RSC EE Certificate 323 was revoked. 325 Conversely, a gap in serial numbers does not imply that an RSC 326 exists. Nor does an arbitrary (to the RP unknown) serial in a CRL 327 imply an RSC object exists: the implicitly referenced object might 328 not be a RSC, it might never have been published, or was revoked 329 before it was visible to RPs. In general, it is not possible to 330 confidentiality infer the existence or non-existence of RSCs from the 331 Repository state without access to a given RSC. 333 While an one-time-use EE Certificate must only be used to generate 334 and sign a single RSC object, CAs technically are not restricted from 335 generating and signing multiple different RSC objects with a single 336 keypair. Any RSC objects sharing the same EE Certificate can not be 337 revoked individually. 339 8. Implementation status 341 This section is to be removed before publishing as an RFC. 343 This section records the status of known implementations of the 344 protocol defined by this specification at the time of posting of this 345 Internet-Draft, and is based on a proposal described in RFC 7942. 346 The description of implementations in this section is intended to 347 assist the IETF in its decision processes in progressing drafts to 348 RFCs. Please note that the listing of any individual implementation 349 here does not imply endorsement by the IETF. Furthermore, no effort 350 has been spent to verify the information presented here that was 351 supplied by IETF contributors. This is not intended as, and must not 352 be construed to be, a catalog of available implementations or their 353 features. Readers are advised to note that other implementations may 354 exist. 356 According to RFC 7942, "this will allow reviewers and working groups 357 to assign due consideration to documents that have the benefit of 358 running code, which may serve as evidence of valuable experimentation 359 and feedback that have made the implemented protocols more mature. 360 It is up to the individual working groups to use this information as 361 they see fit". 363 * A signer and validator implementation [rpki-rsc-demo] written in 364 Perl based on OpenSSL was provided by Tom Harrison from APNIC. 366 * A signer implementation [rpkimancer] written in Python was 367 developed by Ben Maddison. 369 * Example .sig files were created by Job Snijders with the use of 370 OpenSSL. 372 * A validator implementation based on OpenBSD rpki-client and 373 LibreSSL was developed by Job Snijders. 375 * A validator implementation [FORT] based on the FORT validator was 376 developed by Alberto Leiva. 378 9. IANA Considerations 380 9.1. SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) 382 The IANA has permanently allocated for this document in the SMI 383 Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) 384 registry: 386 Decimal Description References 387 --------------------------------------------------------------- 388 48 id-ct-signedChecklist [draft-ietf-sidrops-rpki-rsc] 390 Upon publication of this document, IANA is requested to reference the 391 RFC publication instead of this draft. 393 9.2. RPKI Signed Objects sub-registry 395 The IANA is requested to register the OID for the RPKI Signed 396 Checklist in the registry created by [RFC6488] as following: 398 Name OID Specification 399 ------------------------------------------------------------- 400 Signed Checklist 1.2.840.113549.1.9.16.1.48 [draft-ietf-sidrops-rpki-rsc] 402 9.3. File Extension 404 The IANA is requested to add an item for the Signed Checklist file 405 extension to the "RPKI Repository Name Scheme" registry created by 406 [RFC6481] as follows: 408 Filename Extension RPKI Object Reference 409 ----------------------------------------------------------------------- 410 .sig Signed Checklist [draft-ietf-sidrops-rpki-rsc] 412 9.4. SMI Security for S/MIME Module Identifier 413 (1.2.840.113549.1.9.16.0) 415 The IANA is requested to add an item to the "SMI Security for S/MIME 416 Module Identifier" registry as follows: 418 Decimal Description References 419 ------------------------------------------------------------------------- 420 TBD id-mod-rpkiSignedChecklist-2021 [draft-ietf-sidrops-rpki-rsc] 422 9.5. Media Type 424 The IANA is requested to register the media type application/rpki- 425 checklist in the Provisional Standard Media Type registry as follows: 427 Type name: application 428 Subtype name: rpki-checklist 429 Required parameters: None 430 Optional parameters: None 431 Encoding considerations: binary 432 Security considerations: Carries an RPKI Signed Checklist 433 [RFC-TBD]. 434 Interoperability considerations: None 435 Published specification: This document. 436 Applications that use this media type: RPKI operators. 437 Additional information: 438 Content: This media type is a signed object, as defined 439 in [RFC6488], which contains a payload of a list of 440 checksums as defined above in this document. 441 Magic number(s): None 442 File extension(s): .sig 443 Macintosh file type code(s): 444 Person & email address to contact for further information: 445 Job Snijders 446 Intended usage: COMMON 447 Restrictions on usage: None 448 Author: Job Snijders 449 Change controller: Job Snijders 451 10. References 453 10.1. Normative References 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, 457 DOI 10.17487/RFC2119, March 1997, 458 . 460 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 461 Addresses and AS Identifiers", RFC 3779, 462 DOI 10.17487/RFC3779, June 2004, 463 . 465 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 466 RFC 5652, DOI 10.17487/RFC5652, September 2009, 467 . 469 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 470 Resource Certificate Repository Structure", RFC 6481, 471 DOI 10.17487/RFC6481, February 2012, 472 . 474 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 475 "Manifests for the Resource Public Key Infrastructure 476 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 477 . 479 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 480 X.509 PKIX Resource Certificates", RFC 6487, 481 DOI 10.17487/RFC6487, February 2012, 482 . 484 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 485 Template for the Resource Public Key Infrastructure 486 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 487 . 489 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 490 Algorithms and Key Sizes for Use in the Resource Public 491 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 492 August 2016, . 494 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 495 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 496 May 2017, . 498 10.2. Informative References 500 [FORT] LACNIC and NIC.MX, "FORT", May 2021, 501 . 503 [I-D.ietf-sidrops-rpki-rta] 504 Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T., 505 and M. Hoffmann, "A profile for Resource Tagged 506 Attestations (RTAs)", Work in Progress, Internet-Draft, 507 draft-ietf-sidrops-rpki-rta-00, 21 January 2021, 508 . 511 [I-D.ymbk-sidrops-rpki-has-no-identity] 512 Bush, R. and R. Housley, "The I in RPKI does not stand for 513 Identity", Work in Progress, Internet-Draft, draft-ymbk- 514 sidrops-rpki-has-no-identity-00, 16 March 2021, 515 . 518 [POSIX] IEEE and The Open Group, "The Open Group's Base 519 Specifications, Issue 7", 2016, 520 . 522 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", 523 RFC 1952, DOI 10.17487/RFC1952, May 1996, 524 . 526 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 527 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 528 February 2012, . 530 [rpki-rsc-demo] 531 Harrison, T., "A proof-of-concept for constructing and 532 validating RPKI Signed Checklists (RSCs).", February 2021, 533 . 535 [rpkimancer] 536 Maddison, B., "rpkimancer", May 2021, 537 . 539 [signify] Unangst, T. and M. Espie, "signify - cryptographically 540 sign and verify files", May 2014, 541 . 543 Appendix A. Acknowledgements 545 The authors wish to thank George Michaelson, Tom Harrison, Geoff 546 Huston, Randy Bush, Stephen Kent, Matt Lepinski, Rob Austein, Ted 547 Unangst, and Marc Espie for prior art. The authors thank Russ 548 Housley for reviewing the ASN.1 notation and providing suggestions. 549 The authors would like to thank Nimrod Levy, Tim Bruijnzeels, Alberto 550 Leiva, and Ties de Kock for document review and suggestions. 552 Appendix B. Document changelog 554 This section is to be removed before publishing as an RFC. 556 B.1. changes from -04 -> -05 558 * Ties contributed clarifications. 560 B.2. changes from -03 -> -04 562 * Alberto pointed out the asID validation also needs to be 563 documented. 565 B.3. changes from -02 -> -03 567 * Reference the IANA assigned OID 569 * Clarify validation rules 571 B.4. changes from -01 -> -02 573 * Clarify RSC is part of a puzzle, not panacea. Thanks Randy & 574 Russ. 576 B.5. changes from -00 -> -01 578 * Readability improvements 580 * Update document category to match the registry allocation policy 581 requirement. 583 B.6. individual submission phase 585 * On-the-wire change: the 'Filename' switched from 'required' to 586 'optional'. Some SIDROPS Working Group participants proposed a 587 checksum itself is the most minimal information required to 588 address digital objects. 590 Authors' Addresses 592 Job Snijders 593 Fastly 594 Amsterdam 595 Netherlands 597 Email: job@fastly.com 599 Tom Harrison 600 Asia Pacific Network Information Centre 601 6 Cordelia St 602 South Brisbane QLD 4101 603 Australia 605 Email: tomh@apnic.net 607 Ben Maddison 608 Workonline Communications 609 Cape Town 610 South Africa 612 Email: benm@workonline.africa