idnits 2.17.00 (12 Aug 2021) /tmp/idnits58384/draft-ietf-sidrops-rpki-rsc-06.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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (12 February 2022) is 91 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 172, but not defined -- Looks like a reference, but probably isn't: '0' on line 201 -- Looks like a reference, but probably isn't: '1' on line 202 == Missing Reference: 'RFC-TBD' is mentioned on line 433, but not defined Summary: 1 error (**), 0 flaws (~~), 2 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: 16 August 2022 APNIC 6 B. Maddison 7 Workonline 8 12 February 2022 10 Resource Public Key Infrastructure (RPKI) object profile for Signed 11 Checklist (RSC) 12 draft-ietf-sidrops-rpki-rsc-06 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 16 August 2022. 50 Copyright Notice 52 Copyright (c) 2022 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 Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised 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 -05 -> -06 . . . . . . . . . . . . . . . . . 13 93 B.2. changes from -04 -> -05 . . . . . . . . . . . . . . . . . 13 94 B.3. changes from -03 -> -04 . . . . . . . . . . . . . . . . . 13 95 B.4. changes from -02 -> -03 . . . . . . . . . . . . . . . . . 14 96 B.5. changes from -01 -> -02 . . . . . . . . . . . . . . . . . 14 97 B.6. changes from -00 -> -01 . . . . . . . . . . . . . . . . . 14 98 B.7. individual submission phase . . . . . . . . . . . . . . . 14 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 101 1. Introduction 103 This document defines a Cryptographic Message Syntax (CMS) [RFC5652] 104 profile for a general purpose listing of checksums (a 'checklist'), 105 for use with the Resource Public Key Infrastructure (RPKI) [RFC6480]. 106 The objective is to allow an attestation, in the form of a listing of 107 one or more checksums of arbitrary files, to be signed "with 108 resources", and for validation to provide a means to confirm a given 109 Internet Resource Holder produced the RPKI Signed Checklist (RSC). 110 The profile is intended to provide for the signing of a checksum 111 listing with a specific set of Internet Number Resources. 113 Signed Checklists are expected to facilitate inter-domain business 114 use-cases which depend on an ability to verify resource holdership. 115 RPKI-based validation processes are expected to become the industry 116 norm for automated Bring Your Own IP (BYOIP) on-boarding or 117 establishment of physical interconnection between Autonomous Systems. 119 The RSC concept borrows heavily from RTA [I-D.ietf-sidrops-rpki-rta], 120 Manifests [RFC6486], and OpenBSD's [signify] utility. The main 121 difference between RSC and RTA is that the RTA profile allows 122 multiple signers to attest a single digital object through a checksum 123 of its content, while the RSC profile allows a single signer to 124 attest the existence of multiple digital objects. A single signer 125 profile is considered a simplification for both implementers and 126 operators. 128 2. RSC Profile and Distribution 130 RSC follows the Signed Object Template for the RPKI [RFC6488] with 131 one exception. Because RSCs MUST NOT be distributed through the 132 global RPKI Repository system, the Subject Information Access (SIA) 133 extension MUST be omitted from the RSC's X.509 End-Entity (EE) 134 certificate. 136 What constitutes suitable transport for RSC files is deliberately 137 unspecified. It might be a USB stick, a web interface secured with 138 conventional HTTPS, PGP-signed email, a T-shirt printed with a QR 139 code, or a carrier pigeon. 141 2.1. RSC End-Entity Certificates 143 The CA MUST only sign one RSC with each EE Certificate, and MUST 144 generate a new key pair for each new RSC. This form of use of the 145 associated EE Certificate is termed a "one-time-use" EE certificate 146 Section 3 of [RFC6487]. 148 3. The RSC ContentType 150 The ContentType for an RSC is defined as rpkiSignedChecklist, and has 151 the numerical value of 1.2.840.113549.1.9.16.1.48. 153 This OID MUST appear both within the eContentType in the 154 encapContentInfo object as well as the ContentType signed attribute 155 in the signerInfo object (see [RFC6488]). 157 4. The RSC eContent 159 The content of an RSC indicates that a checklist for arbitrary 160 digital objects has been signed "with resources". An RSC is formally 161 defined as: 163 RpkiSignedChecklist-2021 164 { iso(1) member-body(2) us(840) rsadsi(113549) 165 pkcs(1) pkcs9(9) smime(16) mod(0) TBD } 167 DEFINITIONS EXPLICIT TAGS ::= 168 BEGIN 170 IMPORTS 171 CONTENT-TYPE, Digest, DigestAlgorithmIdentifier 172 FROM CryptographicMessageSyntax-2010 -- in [RFC6268] 173 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 174 pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } 176 ASIdOrRange, IPAddressOrRange 177 FROM IPAddrAndASCertExtn -- in [RFC3779] 178 { iso(1) identified-organization(3) dod(6) internet(1) 179 security(5) mechanisms(5) pkix(7) mod(0) 180 id-mod-ip-addr-and-as-ident(30) } ; 182 ct-rpkiSignedChecklist CONTENT-TYPE ::= 183 { TYPE RpkiSignedChecklist IDENTIFIED BY 184 id-ct-signedChecklist } 186 id-ct-signedChecklist OBJECT IDENTIFIER ::= 187 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 188 pkcs-9(9) id-smime(16) id-ct(1) 48 } 190 RpkiSignedChecklist ::= SEQUENCE { 191 version [0] INTEGER DEFAULT 0, 192 resources ResourceBlock, 193 digestAlgorithm DigestAlgorithmIdentifier, 194 checkList SEQUENCE SIZE (1..MAX) OF FileNameAndHash } 196 FileNameAndHash ::= SEQUENCE { 197 fileName IA5String OPTIONAL, 198 hash Digest } 200 ResourceBlock ::= SEQUENCE { 201 asID [0] AsList OPTIONAL, 202 ipAddrBlocks [1] IPList OPTIONAL } 203 -- at least one of asID or ipAddrBlocks MUST be present 204 ( WITH COMPONENTS { ..., asID PRESENT} | 205 WITH COMPONENTS { ..., ipAddrBlocks PRESENT } ) 207 AsList ::= SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange 209 IPList ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamilyItem 211 IPAddressFamilyItem ::= SEQUENCE { -- AFI & optional SAFI -- 212 addressFamily OCTET STRING (SIZE (2..3)), 213 iPAddressOrRange IPAddressOrRange } 215 END 217 4.1. version 219 The version number of the RpkiSignedChecklist MUST be 0. 221 4.2. resources 223 The resources contained here are the resources used to mark the 224 attestation, and MUST match the set of resources listed by the EE 225 Certificate carried in the CMS certificates field. 227 4.3. digestAlgorithm 229 The digest algorithm used to create the message digest of the 230 attested digital object. This algorithm MUST be a hashing algorithm 231 defined in [RFC7935]. 233 4.4. checkList 235 This field is a sequence of FileNameAndHash objects. There is one 236 FileNameAndHash entry for each arbitrary object referenced on the 237 Signed Checklist. Each FileNameAndHash is an ordered pair of the 238 name of the directory entry containing the digital object and the 239 message digest of the digital object. The filename field is 240 OPTIONAL. 242 5. RSC Validation 244 Before a Relying Party can use an RSC to validate a set of digital 245 objects, the Relying Party MUST first validate the RSC. To validate 246 an RSC, the Relying Party MUST perform all the validation checks 247 specified in [RFC6488] (except checking for the presence of a SIA 248 extension), and perform the following additional RSC-specific 249 validation steps: 251 1. The RSC specification deviates from Section 4.8.8.2 of [RFC6487], 252 the Subject Information Access extension MUST NOT be present on 253 the End-Entity (EE) certificate signing the RSC. 255 2. The IP Addresses and AS Identifiers extension [RFC3779] is 256 present in the end-entity (EE) certificate (contained within the 257 RSC), and each IP address prefix(es) and/or AS Identifier(s) in 258 the RSC is contained within the set of IP addresses specified by 259 the EE Certificate's IP Addresses and AS Identifiers delegation 260 extension. 262 3. For each FileNameAndHash entry in the RSC, if a filename field is 263 present, the field's content MUST contain only characters 264 specified in the Portable Filename Character Set as defined in 265 [POSIX]. 267 To verify a set of digital objects with an RSC: 269 * The message digest of each referenced digital object, using the 270 digest algorithm specified in the the digestAlgorithm field, MUST 271 be calculated and MUST match the value given in the messageDigest 272 field of the associated FileNameAndHash, for the digital object to 273 be considered as verified with the RSC. 275 6. Operational Considerations 277 When creating digital objects of a plain-text nature (such as ASCII, 278 UTF-8, HTML, Javascript, XML, etc) it is RECOMMENDED to convert such 279 objects into a lossless compressed form. Distributing plain-text 280 objects within a compression envelope (such as GZIP [RFC1952]) might 281 help avoid unexpected canonicalization at intermediate systems (which 282 in turn would lead to checksum verification errors). Validator 283 implementations are expected to treat a checksummed digital object as 284 string of arbitrary single octets. 286 If a filename field is present, but no referenced digital object has 287 a filename that matches the content of that field, a validator 288 implementation SHOULD compare the message digest of each digital 289 object to the value from the messageDigest field of the associated 290 FileNameAndHash, and report matches to the client for further 291 consideration. 293 7. Security Considerations 295 Relying parties are hereby warned that the data in a RPKI Signed 296 Checklist is self-asserted. When determining the meaning of any data 297 contained in an RPKI Signed Checklist, Relying Parties MUST NOT make 298 any assumptions about the signer beyond the fact that it had 299 sufficient control of the issuing CA to create the object. These 300 data have not been verified by the Certificate Authority (CA) that 301 issued the CA certificate to the entity that issued the EE 302 Certificate used to validate the Signed Checklist. 304 RPKI Certificates are not bound to real world identities, see 305 [I-D.ymbk-sidrops-rpki-has-no-identity] for an elaboration. Relying 306 Parties can only associate real world entities to Internet Number 307 Resources by additionally consulting an exogenous authority. Signed 308 Checklists are a tool to communicate assertions 'signed with Internet 309 Number Resources', not about any other aspect of the resource 310 holder's business operations such as the identity of the resource 311 holder itself. 313 RSC objects are not distributed through the RPKI Repository system. 314 From this, it follows that third parties who do not have a copy of a 315 given RSC, may not be aware of the existence of that RSC. Since RSC 316 objects use EE Certificates, but all other currently defined types of 317 RPKI object profiles are published in public CA repositories, an 318 observer may infer from discrepancies in the Repository that RSC 319 object(s) may exist. For example, if a CA does not use random serial 320 numbers for Certificates, an observer could detect gaps between the 321 serial numbers of the published EE Certificates. Similarly, if the 322 CA includes a serial number on a CRL that does not match any 323 published object, an observer could postulate an RSC EE Certificate 324 was revoked. 326 Conversely, a gap in serial numbers does not imply that an RSC 327 exists. Nor does an arbitrary (to the RP unknown) serial in a CRL 328 imply an RSC object exists: the implicitly referenced object might 329 not be a RSC, it might never have been published, or was revoked 330 before it was visible to RPs. In general, it is not possible to 331 confidently infer the existence or non-existence of RSCs from the 332 Repository state without access to a given RSC. 334 While an one-time-use EE Certificate must only be used to generate 335 and sign a single RSC object, CAs technically are not restricted from 336 generating and signing multiple different RSC objects with a single 337 keypair. Any RSC objects sharing the same EE Certificate can not be 338 revoked individually. 340 8. Implementation status 342 This section is to be removed before publishing as an RFC. 344 This section records the status of known implementations of the 345 protocol defined by this specification at the time of posting of this 346 Internet-Draft, and is based on a proposal described in RFC 7942. 347 The description of implementations in this section is intended to 348 assist the IETF in its decision processes in progressing drafts to 349 RFCs. Please note that the listing of any individual implementation 350 here does not imply endorsement by the IETF. Furthermore, no effort 351 has been spent to verify the information presented here that was 352 supplied by IETF contributors. This is not intended as, and must not 353 be construed to be, a catalog of available implementations or their 354 features. Readers are advised to note that other implementations may 355 exist. 357 According to RFC 7942, "this will allow reviewers and working groups 358 to assign due consideration to documents that have the benefit of 359 running code, which may serve as evidence of valuable experimentation 360 and feedback that have made the implemented protocols more mature. 361 It is up to the individual working groups to use this information as 362 they see fit". 364 * A signer and validator implementation [rpki-rsc-demo] written in 365 Perl based on OpenSSL was provided by Tom Harrison from APNIC. 367 * A signer implementation [rpkimancer] written in Python was 368 developed by Ben Maddison. 370 * Example .sig files were created by Job Snijders with the use of 371 OpenSSL. 373 * A validator implementation based on OpenBSD rpki-client and 374 LibreSSL was developed by Job Snijders. 376 * A validator implementation [FORT] based on the FORT validator was 377 developed by Alberto Leiva. 379 9. IANA Considerations 381 9.1. SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) 383 The IANA has permanently allocated for this document in the SMI 384 Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) 385 registry: 387 Decimal Description References 388 --------------------------------------------------------------- 389 48 id-ct-signedChecklist [draft-ietf-sidrops-rpki-rsc] 391 Upon publication of this document, IANA is requested to reference the 392 RFC publication instead of this draft. 394 9.2. RPKI Signed Objects sub-registry 396 The IANA is requested to register the OID for the RPKI Signed 397 Checklist in the registry created by [RFC6488] as following: 399 Name OID Specification 400 ------------------------------------------------------------- 401 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, Ties de Kock, and Peter Peele for document review and 551 suggestions. 553 Appendix B. Document changelog 555 This section is to be removed before publishing as an RFC. 557 B.1. changes from -05 -> -06 559 * Non-content-related updates. 561 B.2. changes from -04 -> -05 563 * Ties contributed clarifications. 565 B.3. changes from -03 -> -04 567 * Alberto pointed out the asID validation also needs to be 568 documented. 570 B.4. changes from -02 -> -03 572 * Reference the IANA assigned OID 574 * Clarify validation rules 576 B.5. changes from -01 -> -02 578 * Clarify RSC is part of a puzzle, not panacea. Thanks Randy & 579 Russ. 581 B.6. changes from -00 -> -01 583 * Readability improvements 585 * Update document category to match the registry allocation policy 586 requirement. 588 B.7. individual submission phase 590 * On-the-wire change: the 'Filename' switched from 'required' to 591 'optional'. Some SIDROPS Working Group participants proposed a 592 checksum itself is the most minimal information required to 593 address digital objects. 595 Authors' Addresses 597 Job Snijders 598 Fastly 599 Amsterdam 600 Netherlands 602 Email: job@fastly.com 604 Tom Harrison 605 Asia Pacific Network Information Centre 606 6 Cordelia St 607 South Brisbane QLD 4101 608 Australia 610 Email: tomh@apnic.net 611 Ben Maddison 612 Workonline Communications 613 Cape Town 614 South Africa 616 Email: benm@workonline.africa