idnits 2.17.1 draft-ietf-sidr-res-certs-22.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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 6, 2011) is 4739 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) -- No information found for draft-ietf-sidr-c - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ID.sidr-cp' == Outdated reference: A later version (-05) exists of draft-ietf-sidr-rpki-algs-00 ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-algorithm-agility-00 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-04 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-keyroll-02 == Outdated reference: A later version (-09) exists of draft-ietf-sidr-repos-struct-04 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rpki-manifests-04 == Outdated reference: A later version (-04) exists of draft-ietf-sidr-signed-object-01 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR G. Huston 3 Internet-Draft G. Michaelson 4 Intended status: Standards Track R. Loomans 5 Expires: November 7, 2011 APNIC 6 May 6, 2011 8 A Profile for X.509 PKIX Resource Certificates 9 draft-ietf-sidr-res-certs-22 11 Abstract 13 This document defines a standard profile for X.509 certificates for 14 the purposes of supporting validation of assertions of "right-of-use" 15 of Internet Number Resources (INRs). The certificates issued under 16 this profile are used to convey the Issuer's authorisation of the 17 Subject to be regarded as the current holder of a "right-of-use" of 18 the INRs that are described in the certificate. This document 19 contains the normative specification of Certificate and Certificate 20 Revocation List (CRL) syntax in the Resource Public Key 21 Infrastructure (RPKI). The document also specifies profiles for the 22 format of certificate requests. The document also specifies the 23 Relying Party RPKI certificate path validation procedure. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 7, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Describing Resources in Certificates . . . . . . . . . . . . . 5 62 3. End-Entity (EE) Certificates and Signing Functions in the 63 RPKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Resource Certificates . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Serial number . . . . . . . . . . . . . . . . . . . . . . 6 67 4.3. Signature Algorithm . . . . . . . . . . . . . . . . . . . 6 68 4.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.5. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.6. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.6.1. notBefore . . . . . . . . . . . . . . . . . . . . . . 8 72 4.6.2. notAfter . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.7. Subject Public Key Info . . . . . . . . . . . . . . . . . 8 74 4.8. Resource Certificate Extensions . . . . . . . . . . . . . 8 75 4.8.1. Basic Constraints . . . . . . . . . . . . . . . . . . 8 76 4.8.2. Subject Key Identifier . . . . . . . . . . . . . . . . 9 77 4.8.3. Authority Key Identifier . . . . . . . . . . . . . . . 9 78 4.8.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 9 79 4.8.5. Extended Key Usage . . . . . . . . . . . . . . . . . . 9 80 4.8.6. CRL Distribution Points . . . . . . . . . . . . . . . 10 81 4.8.7. Authority Information Access . . . . . . . . . . . . . 10 82 4.8.8. Subject Information Access . . . . . . . . . . . . . . 11 83 4.8.9. Certificate Policies . . . . . . . . . . . . . . . . . 12 84 4.8.10. IP Resources . . . . . . . . . . . . . . . . . . . . . 12 85 4.8.11. AS Resources . . . . . . . . . . . . . . . . . . . . . 12 86 5. Resource Certificate Revocation Lists . . . . . . . . . . . . 13 87 6. Resource Certificate Requests . . . . . . . . . . . . . . . . 13 88 6.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 14 89 6.1.1. PKCS#10 Resource Certificate Request Template 90 Fields . . . . . . . . . . . . . . . . . . . . . . . . 14 91 6.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 15 92 6.2.1. CRMF Resource Certificate Request Template Fields . . 15 93 6.2.2. Resource Certificate Request Control Fields . . . . . 16 94 6.3. Certificate Extension Attributes in Certificate 95 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 7. Resource Certificate Validation . . . . . . . . . . . . . . . 17 98 7.1. Resource Extension Validation . . . . . . . . . . . . . . 17 99 7.2. Resource Certification Path Validation . . . . . . . . . . 18 100 8. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 9. Operational Considerations for Profile Agility . . . . . . . . 22 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 103 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 104 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 105 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 106 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 107 13.2. Informative References . . . . . . . . . . . . . . . . . . 26 108 Appendix A. Example Resource Certificate . . . . . . . . . . . . 27 109 Appendix B. Example Certificate Revocation List . . . . . . . . . 30 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 112 1. Introduction 114 This document defines a standard profile for X.509 certificates 115 [X.509] for use in the context of certification of Internet Number 116 Resources (INRs), i.e., IP Addresses and Autonomous System (AS) 117 Numbers. Such certificates are termed "Resource Certificates". A 118 Resource Certificate is a certificate that conforms to the PKIX 119 profile [RFC5280], and that conforms to the constraints specified in 120 this profile. A Resource Certificate attests that the Issuer has 121 granted the Subject a "right-of-use" for a listed set of IP addresses 122 and/or Autonomous System numbers. 124 This document is referenced by Section 7 of the Certificate Policy 125 (CP) for the Resource Public Key Infrastructure (RPKI) [ID.sidr-cp]. 126 It is an integral part of that policy and the normative specification 127 for certificate and Certificate Revocation List (CRL) syntax used in 128 the RPKI. The document also specifies profiles for the format of 129 certificate requests, and the Relying Party (RP) RPKI certificate 130 path validation procedure. 132 Resource Certificates are to be used in a manner that is consistent 133 with the RPKI Certificate Policy [ID.sidr-cp]. They are issued by 134 entities that assign and/or allocate public INRs, and thus the RPKI 135 is aligned with the public INR distribution function. When an INR is 136 allocated or assigned by a number registry to an entity, this 137 allocation can be described by an associated Resource Certificate. 138 This certificate is issued by the number registry, and it binds the 139 certificate subject's key to the INRs enumerated in the certificate. 140 One or two critical extensions, the IP Address Delegation or AS 141 Identifier Delegation Extensions [RFC3779], enumerate the INRs that 142 were allocated or assigned by the Issuer to the Subject. 144 RP validation of a Resource Certificate is performed in the manner 145 specified in Section 7.1. This validation procedure differs from 146 that described in section 6 of [RFC5280], such that: 147 o additional validation processing imposed by the INR extensions is 148 required, 149 o a confirmation of a public key match between the CRL issuer and 150 the Resource Certificate issuer is required, and 151 o the Resource Certificate is required to conform to this profile. 153 This profile defines those fields that are used in a Resource 154 Certificate that MUST be present for the certificate to be valid. 155 Any extensions not explicitly mentioned MUST be absent. The same 156 applies to the CRLs used in the RPKI, that are also profiled in this 157 document. A CA conforming to the RPKI CP MUST issue certificates and 158 CRLs consistent with this profile. 160 1.1. Terminology 162 It is assumed that the reader is familiar with the terms and concepts 163 described in "Internet X.509 Public Key Infrastructure Certificate 164 and Certificate Revocation List (CRL) Profile" [RFC5280], and "X.509 165 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 2. Describing Resources in Certificates 173 The framework for describing an association between the Subject of a 174 certificate and the INRs currently under the Subject's control is 175 described in [RFC3779]. This profile further requires that: 177 o Every Resource Certificate MUST contain either the IP Address 178 Delegation or the Autonomous System Identifier Delegation 179 extension, or both. 181 o These extensions MUST be marked as CRITICAL. 183 o The sorted canonical format describing INRs, with maximal spanning 184 ranges and maximal spanning prefix masks, as defined in [RFC3779], 185 MUST be used for the resource extension field, except where the 186 "inherit" construct is used instead. 188 When validating a Resource Certificate, an RP MUST verify that the 189 INRs described in the Issuer's Resource Certificate encompass the 190 INRs of the Resource Certificate being validated. In this context 191 "encompass" allows for the Issuer's INRs to be the same as, or a 192 strict superset of the Subject's INRs. 194 3. End-Entity (EE) Certificates and Signing Functions in the RPKI 196 As noted in [ID.sidr-arch], the primary function of End-Entity (EE) 197 certificates in the RPKI is the verification of signed objects that 198 relate to the usage of the INRs described in the certificate, e.g., 199 Route Origin Authorizations (ROAs) and manifests. 201 The private key associated with an EE certificate is used to sign a 202 single RPKI signed object, i.e., the EE certificate is used to 203 validate only one object. The EE certificate is embedded in the 204 object as part of a Cryptographic Message Syntax (CMS) signed data 205 structure [ID.sidr-signed-object]. Because of the one-to-one 206 relationship between the EE certificate and the signed object, 207 revocation of the certificate effectively revokes the corresponding 208 signed object. 210 A EE certificate may be used to validate a sequence of signed 211 objects, were each signed object in the sequence overwrites the 212 previous instance of the signed object in the repository publication 213 point, such that only one instance of the signed object is published 214 at any point in time (e.g., an EE certificate MAY be used to sign a 215 sequence of manifests [ID.sidr-rpki-manifests]). Such EE 216 certificates are termed "sequential use" EE certificates. 218 EE certificates used to validate only one instance of a signed 219 object, and are not used thereafter, or in any other validation 220 context, are termed "one-time-use" EE certificates. 222 4. Resource Certificates 224 A Resource Certificate is a valid X.509 public key certificate, 225 consistent with the PKIX profile [RFC5280], containing the fields 226 listed in this section. Only the differences from [RFC5280] are 227 noted below. 229 Unless specifically noted as being OPTIONAL, all the fields listed 230 here MUST be present, and any other field MUST NOT appear in a 231 conforming Resource Certificate. Where a field value is specified 232 here, this value MUST be used in conforming Resource Certificates. 234 4.1. Version 236 As Resource Certificates are X.509 Version 3 certificates, the 237 version MUST be 3 (i.e. the value of this field is 2). 239 RPs need not process version 1 or version 2 certificates (in contrast 240 to [RFC5280]). 242 4.2. Serial number 244 The serial number value is a positive integer that is unique for each 245 certificate issued by a given CA. 247 4.3. Signature Algorithm 249 The algorithm used in this profile is specified in 250 [ID.sidr-rpki-algs]. 252 4.4. Issuer 254 The value of this field is a valid X.501 distinguished name. 256 An Issuer name MUST contain one instance of the Common Name attribute 257 and MAY contain one instance of the Serial Number attribute. If both 258 attributes are present, it is RECOMMENDED that they appear as a set. 259 The Common Name attribute MUST be encoded using the ASN.1 type 260 PrintableString [X.680]. Issuer names are not intended to be 261 descriptive of the identity of Issuer. 263 The RPKI does not rely on Issuer names being globally unique, for 264 reasons of security. However, it is RECOMMENDED that Issuer names be 265 generated in a fashion that minimizes the likelihood of collisions. 266 See Section 8 for (non-normative) suggested name generation 267 mechanisms that fulfill this recommendation. 269 4.5. Subject 271 The value of this field is a valid X.501 distinguished name 272 [RFC4514], and is subject to the same constraints as the Issuer name. 274 In the RPKI the Subject name is determined by the Issuer, not 275 proposed by the subject [ID.sidr-repos-struct]. Each distinct 276 subordinate CA and EE certified by the Issuer MUST be identified 277 using a Subject name that is unique per Issuer. In this context 278 "distinct" is defined as an entity and a given public key. An Issuer 279 SHOULD use a different Subject name if the Subject's key pair has 280 changed (i.e., when the CA issues a certificate as part of re-keying 281 the Subject.) Subject names are not intended to be descriptive of 282 the identity of Subject. 284 4.6. Validity 286 The certificate validity period is represented as a SEQUENCE of two 287 dates: the date on which the certificate validity period begins 288 (notBefore) and the date on which the certificate validity period 289 ends (notAfter). 291 While a CA is typically advised against issuing a certificate with a 292 validity period that spans a greater period of time than the validity 293 period of the CA's certificate that will be used to validate the 294 issued certificate, in the context of this profile, a CA MAY have 295 valid grounds to issue a subordinate certificate with a validity 296 period that exceeds the validity period of the CA's certificate. 298 4.6.1. notBefore 300 The "notBefore" time SHOULD be no earlier than the time of 301 certificate generation. 303 In the RPKI it is valid for a certificate to have a value for this 304 field that pre-dates the same field value in any superior 305 certificate. Relying Parties SHOULD NOT attempt to infer from this 306 time information that a certificate was valid at a time in the past, 307 or will be valid at a time in the future, as the scope of an RP's 308 test of validity of a certificate refers specifically to validity at 309 the current time. 311 4.6.2. notAfter 313 The "notAfter" time represents the anticipated lifetime of the 314 current resource allocation or assignment arrangement between the 315 Issuer and the Subject. 317 It is valid for a certificate to have a value for this field that 318 post-dates the same field value in any superior certificate. The 319 same caveats apply to RP's assumptions relating to the certificate's 320 validity at any time other than the current time. 322 4.7. Subject Public Key Info 324 The algorithm used in this profile is specified in 325 [ID.sidr-rpki-algs]. 327 4.8. Resource Certificate Extensions 329 The following X.509 V3 extensions MUST be present in a conforming 330 Resource Certificate, except where explicitly noted otherwise. Each 331 extension in a resource certificate is designated as either critical 332 or non-critical. A certificate-using system MUST reject the 333 certificate if it encounters a critical extension it does not 334 recognise; however, a non-critical extension MAY be ignored if it is 335 not recognised [RFC5280]. 337 4.8.1. Basic Constraints 339 The Basic Constraints extension field is a critical extension in the 340 Resource Certificate profile, and MUST be present when the Subject is 341 a CA, and MUST NOT be present otherwise. 343 The Issuer determines whether the "cA" boolean is set. 345 The Path Length Constraint is not specified for RPKI certificates, 346 and MUST NOT be present. 348 4.8.2. Subject Key Identifier 350 This extension MUST appear in all Resource Certificates. This 351 extension is non-critical. 353 The Key Identifier used for resource certificates is the 160-bit 354 SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the 355 Subject Public Key, as described in Section 4.2.1.2 of [RFC5280]. 357 4.8.3. Authority Key Identifier 359 This extension MUST appear in all Resource Certificates, with the 360 exception of a CA who issues a "self-signed" certificate. In a self- 361 signed certificate, a CA MAY include this extension, and set it equal 362 to the Subject Key Identifier. The authorityCertIssuer and 363 authorityCertSerialNumber fields MUST NOT be present. This extension 364 is non-critical. 366 The Key Identifier used for resource certificates is the 160-bit 367 SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the 368 Issuer's public key, as described in Section 4.2.1.1 of [RFC5280]. 370 4.8.4. Key Usage 372 This extension is a critical extension and MUST be present. 374 In certificates issued to Certification Authorities only the 375 keyCertSign and CRLSign bits are set to TRUE, and these MUST be the 376 only bits set to TRUE. 378 In EE certificates the digitalSignature bit MUST be set to TRUE and 379 MUST be the only bit set to TRUE. 381 4.8.5. Extended Key Usage 383 The Extended Key Usage (EKU) extension MUST NOT appear in any CA 384 certificate in the RPKI. This extension also MUST NOT appear in EE 385 certificates used to verify RPKI objects (e.g., ROAs or manifests. 386 The extension MUST NOT be marked critical. 388 The EKU extension MAY appear in EE certificates issued to routers or 389 other devices. Permitted values for the EKU OIDs will be specified 390 in Standards Track RFCs issued by other IETF working groups that 391 adopt the RPKI profile and that identify application-specific 392 requirements that motivate the use of such EKUs. 394 4.8.6. CRL Distribution Points 396 This extension MUST be present, except in "self-signed" certificates, 397 and it is non-critical. In a self-signed certificate this extension 398 MUST be omitted. 400 In this profile, the scope of the CRL is specified to be all 401 certificates issued by this CA Issuer. 403 The CRL Distribution Points (CRLDP) extension identifies the 404 location(s) of the CRL(s) associated with certificates issued by this 405 Issuer. The RPKI uses the URI form of object identification. The 406 preferred URI access mechanism is a single RSYNC URI ("rsync://") 407 [RFC5781] that references a single inclusive CRL for each Issuer. 409 In this profile the certificate Issuer is also the CRL Issuer, 410 implying that the CRLIssuer field MUST be omitted, and the 411 distributionPoint field MUST be present. The Reasons field MUST be 412 omitted. 414 The distributionPoint MUST contain the fullName field, and MUST NOT 415 contain a nameRelativeToCRLIssuer. The form of the generalName MUST 416 be of type URI. 418 The sequence of distributionPoint values MUST contain only a single 419 DistributionPoint. The DistributionPoint MAY contain more than one 420 URI value. An RSYNC URI [RFC5781] MUST be present in the 421 DistributionPoint, and reference the most recent instance of this 422 Issuer's CRL. Other access form URIs MAY be used in addition to the 423 RSYNC URI, representing alternate access mechanisms for this CRL. 425 4.8.7. Authority Information Access 427 In the context of the RPKI, this extension identifies the publication 428 point of the certificate of the issuer of the certificate in which 429 the extension appears. In this profile a single reference to the 430 publication point of the immediate superior certificate MUST be 431 present, except for a "self-signed" certificate, in which case the 432 extension MUST be omitted. This extension is non-critical. 434 This profile uses a URI form of object identification. The preferred 435 URI access mechanisms is "rsync", and an RSYNC URI [RFC5781] MUST be 436 specified with an accessMethod value of id-ad-caIssuers. The URI 437 MUST reference the point of publication of the certificate where this 438 Issuer is the Subject (the Issuer's immediate superior certificate). 439 Other accessMethod URIs referencing the same object MAY also be 440 included in the value sequence of this extension. 442 A CA MUST use a persistent URL name scheme for CA certificates that 443 it issues [ID.sidr-repos-struct]. This implies that a re-issued 444 certificate overwrites a previously issued certificate (to the same 445 Subject) in the publication repository. In this way certificates 446 subordinate to the re-issued (CA) certificate can maintain a constant 447 Authority Information Access (AIA) extension pointer and thus need 448 not be re-issued when the parent certificate is re-issued. 450 4.8.8. Subject Information Access 452 In the context of the RPKI, this extension (SIA) identifies the 453 publication point of products signed by the Subject of the 454 certificate. 456 4.8.8.1. SIA for CA Certificates 458 This extension MUST be present, and is non-critical. 460 This extension MUST have an instance of an accessMethod of id-ad- 461 caRepository, with an accessLocation form of a URI that MUST specify 462 an RSYNC URI [RFC5781]. This URI points to the directory containing 463 all published material issued by this CA. i.e., all valid CA 464 certificates, published EE certificates, the current CRL, manifest 465 and signed objects validated via EE certificates that have been 466 issued by this CA [ID.sidr-repos-struct]. Other accessDescription 467 elements with an accessMethod of id-ad-caRepository MAY be present. 468 In such cases, the accessLocation values describe alternate supported 469 URI access mechanisms for the same directory. The ordering of URIs 470 in this accessDescription sequence reflect the CA's relative 471 preferences for access methods to be used by RPs, with the first 472 element of the sequence being the most preferred by the CA. 474 This extension MUST have an instance of an AccessDescription with an 475 accessMethod of id-ad-rpkiManifest, 477 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 479 id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 } 481 with an RSYNC URI [RFC5781] form of accessLocation. The URI points 482 to the CA's manifest of published objects [ID.sidr-rpki-manifests] as 483 an object URL. Other accessDescription elements MAY exist for the 484 id-ad-rpkiManifest accessMethod, where the accessLocation value 485 indicates alternate access mechanisms for the same manifest object. 487 4.8.8.2. SIA for EE Certificates 489 This extension MUST be present, and is non-critical. 491 This extension MUST have an instance of an accessMethod of id-ad- 492 signedObject, 494 id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 } 496 with an accessLocation form of a URI that MUST include an RSYNC URI 497 [RFC5781]. This URI points to the signed object that is verified 498 using this EE certificate [ID.sidr-repos-struct]. Other 499 accessDescription elements may exist for the id-ad-signedObject 500 accessMethod, where the accessLocation value indicates alternate URI 501 access mechanisms for the same object, ordered in terms of the EE's 502 relative preference for supported access mechanisms. 504 Other AccessMethods MUST NOT be used for an EE certificates's SIA. 506 4.8.9. Certificate Policies 508 This extension MUST be present, and MUST be marked critical. It MUST 509 include exactly one policy, as specified in the RPKI CP [ID.sidr-cp] 511 4.8.10. IP Resources 513 Either the IP Resources extension, or the AS Resources extension, or 514 both, MUST be present in all RPKI certificates, and if present, MUST 515 be marked critical. 517 This extension contains the list of IP address resources as per 518 [RFC3779]. The value may specify the "inherit" element for a 519 particular AFI value. In the context of resource certificates 520 describing public number resources for use in the public Internet, 521 the SAFI value MUST NOT be used. 523 This extension MUST either specify a non-empty set IP address 524 records, or use the "inherit" setting to indicate that the IP address 525 resource set of this certificate is inherited from that of the 526 certificate's issuer. 528 4.8.11. AS Resources 530 Either the AS Resources extension, or the IP Resources extension, or 531 both, MUST be present in all RPKI certificates, and if present, MUST 532 be marked critical. 534 This extension contains the list of AS number resources as per 536 [RFC3779], or may specify the "inherit" element. RDI values are NOT 537 supported in this profile and MUST NOT be used. 539 This extension MUST either specify a non-empty set AS number records, 540 or use the "inherit" setting to indicate that the AS number resource 541 set of this certificate is inherited from that of the certificate's 542 issuer. 544 5. Resource Certificate Revocation Lists 546 Each CA MUST issue a version 2 Certificate Revocation List (CRL), 547 consistent with [RFC5280]. RPs are NOT required to process version 1 548 CRLs (in contrast to [RFC5280]). The CRL Issuer is the CA. CRLs 549 conforming to this profile MUST NOT include Indirect or Delta CRLs. 550 The scope of each CRL MUST be all certificates issued by this CA. 552 The Issuer name is as in Section 4.4 above. 554 Where two or more CRLs issued by the same CA, the CRL with the 555 highest value of the "CRL Number" field supersedes all other CRLs 556 issued by this CA. 558 The algorithm used in CRLs issued under this profile is specified in 559 [ID.sidr-rpki-algs]. 561 The contents of the CRL are a list of all non-expired certificates 562 that have been revoked by the CA. 564 An RPKI CA MUST include the two extensions Authority Key Identifier 565 and CRL Number in every CRL that it issues. RPs MUST be prepared to 566 process CRLs with these extensions. No other CRL extensions are 567 allowed. 569 For each revoked resource certificate only the two fields Serial 570 Number and Revocation Date MUST be present, and all other fields MUST 571 NOT be present. No CRL entry extensions are supported in this 572 profile, and CRL entry extensions MUST NOT be present in a CRL. 574 6. Resource Certificate Requests 576 A resource certificate request MAY use either of PKCS#10 or 577 Certificate Request Message Format (CRMF). A CA MUST support 578 certificate issuance in PKCS#10 and a CA MAY support CRMF requests. 580 Note that there is no certificate response defined in this profile. 581 For CA certificate requests, the CA places the Resource Certificate 582 in the repository, as per [ID.sidr-cp]. No response is defined for 583 EE Certificate requests. 585 6.1. PCKS#10 Profile 587 This profile refines the specification in [RFC2986], as it relates to 588 Resource Certificates. A Certificate Request Message object, 589 formatted according to PKCS#10, is passed to a CA as the initial step 590 in issuing a certificate. 592 With the exception of the SubjectPublicKeyinfo and the SIA extension 593 request, the CA is permitted to alter any field in the request when 594 issuing a certificate. 596 6.1.1. PKCS#10 Resource Certificate Request Template Fields 598 This profile applies the following additional requirements to fields 599 that MAY appear in a CertificationRequestInfo: 601 Version 602 This field is mandatory and MUST have the value 0. 604 Subject 605 This field MAY be omitted. If present, the value of this field 606 SHOULD be empty (i.e., NULL), in which case the CA MUST 607 generate a Subject name that is unique in the context of 608 certificates issued by this CA. This field is allowed to be 609 non-empty only for a rekey/reissuance request, and only if the 610 CA has adopted a policy (in its Certificate Practice Statement 611 (CPS)) that permits name reuse in these circumstances. 613 SubjectPublicKeyInfo 614 This field specifies the Subject's public key and the algorithm 615 with which the key is used. The algorithm used in this profile 616 is specified in [ID.sidr-rpki-algs]. 618 Attributes 619 [RFC2986] defines the attributes field as key-value pairs where 620 the key is an OID and the value's structure depends on the key. 622 The only attribute used in this profile is the ExtensionRequest 623 attribute as defined in [RFC2985]. This attribute contains 624 certificate Extensions. The profile for extensions in 625 certificate requests is specified in Section 6.3. 627 This profile applies the following additional constraints to fields 628 that MAY appear in a CertificationRequest Object: 630 signatureAlgorithm 631 The signatureAlgorithm value is specified in 632 [ID.sidr-rpki-algs]. 634 6.2. CRMF Profile 636 This profile refines the Certificate Request Message Format (CRMF) 637 specification in [RFC4211], as it relates to Resource Certificates. 638 A Certificate Request Message object, formatted according to the 639 CRMF, is passed to a CA as the initial step in certificate issuance. 641 With the exception of the SubjectPublicKeyinfo and the SIA extension 642 request, the CA is permitted to alter any requested field when 643 issuing the certificate. 645 6.2.1. CRMF Resource Certificate Request Template Fields 647 This profile applies the following additional requirements to fields 648 that may appear in a Certificate Request Template: 650 version 651 This field SHOULD be omitted. If present, it MUST specify a 652 request for a Version 3 Certificate. 654 serialNumber 655 This field MUST be omitted. 657 signingAlgorithm 658 This field MUST be omitted. 660 issuer 661 This MUST be omitted in this profile. 663 Validity 664 This field MAY be omitted. If omitted, the CA will issue a 665 Certificate with Validity dates as determined by the CA. If 666 specified, then the CA MAY override the requested values with 667 dates as determined by the CA. 669 Subject 670 This field MAY be omitted. If present, the value of this field 671 SHOULD be empty (i.e., NULL), in which case the CA MUST 672 generate a Subject name that is unique in the context of 673 certificates issued by this CA. This field is allowed to be 674 non-empty only for a rekey/reissuance request, and only if the 675 CA has adopted a policy (in its CPS) that permits name reuse in 676 these circumstances. 678 PublicKey 679 This field MUST be present. 681 extensions 682 The profile for extensions in certificate requests is specified 683 in Section 6.3. 685 6.2.2. Resource Certificate Request Control Fields 687 The following control fields are supported in this profile: 689 Authenticator Control 690 'The intended model of authentication of the Subject is a "long 691 term" model, and the guidance offered in [RFC4211] is that the 692 Authenticator Control field be used. 694 6.3. Certificate Extension Attributes in Certificate Requests 696 The following extensions MAY appear in a PKCS#10 or CRMF Certificate 697 Request. Any other extensions MUST NOT appear in a Certificate 698 Request. This profile places the following additional constraints on 699 these extensions: 701 BasicConstraints 702 If this is omitted then the CA will issue an EE certificate 703 (hence no BasicConstraints extension will be included). 705 The pathLengthConstraint is not supported in this profile, and 706 this field MUST be omitted. 708 The CA MAY honour the cA boolean if set to true (CA certificate 709 request). If this bit is set, then it indicates that the 710 Subject is requesting a CA certificate. 712 The CA MUST honour the cA bit if set to false (EE certificate 713 request), in which case the corresponding EE certificate will 714 not contain a Basic Constraints extension. 716 KeyUsage 717 The CA MAY honour KeyUsage extensions of keyCertSign and 718 cRLSign if present, as long as this is consistent with the 719 BasicConstraints SubjectType sub field, when specified. 721 ExtendedKeyUsage 722 The CA MAY honour ExtendedKeyUsage extensions of keyCertSign 723 and cRLSign if present, as long as this is consistent with the 724 BasicConstraints SubjectType sub field, when specified. 726 SubjectInformationAccess 727 This field MUST be present, and the field value SHOULD be 728 honoured by the CA if it conforms to the requirements set forth 729 in Section 4.8.8. If the CA is unable to honour the requested 730 value for this field, then the CA MUST reject the Certificate 731 Request. 733 7. Resource Certificate Validation 735 This section describes the Resource Certificate validation procedure. 736 This refines the generic procedure described in section 6 of 737 [RFC5280]. 739 7.1. Resource Extension Validation 741 The IP Resources and AS Resources extensions definitions [RFC3779] 742 define critical extensions for INRs. These are ASN.1 encoded 743 representations of the IPv4 and IPv6 address range and an AS number 744 set. 746 Valid Resource Certificates MUST have a valid IP address and/or AS 747 number resource extension. In order to validate a Resource 748 Certificate the resource extension MUST also be validated. This 749 validation process relies on definitions of comparison of resource 750 sets: 752 more specific 753 Given two IP address or AS number contiguous ranges, A and B, A 754 is "more specific" than B if range B includes all IP addresses 755 or AS numbers described by range A, and if range B is larger 756 than range A. 758 equal 759 Given two IP address or AS number contiguous ranges, A and B, A 760 is "equal" to B if range A describes precisely the same 761 collection of IP addresses or AS numbers as described by range 762 B. The definition of "inheritance" in [RFC3779] is equivalent 763 to this "equality" comparison. 765 encompass 766 Given two IP address and AS number sets X and Y, X 767 "encompasses" Y if, for every contiguous range of IP addresses 768 or AS numbers elements in set Y, the range element is either 769 "more specific" than or "equal" to a contiguous range element 770 within the set X. 772 Validation of a certificate's resource extension in the context of a 773 Certification Path (see Section 7.2 entails that for every adjacent 774 pair of certificates in the certification path (certificates 'x' and 775 'x + 1'), the number resources described in certificate 'x' 776 "encompass" the number resources described in certificate 'x + 1', 777 and the resources described in the trust anchor information 778 "encompass" the resources described in the first certificate in the 779 certification path. 781 7.2. Resource Certification Path Validation 783 Validation of signed resource data using a target resource 784 certificate consists of verifying that the digital signature of the 785 signed resource data is valid, using the public key of the target 786 resource certificate, and also validating the resource certificate in 787 the context of the RPKI, using the path validation process. This 788 path validation process verifies, among other things, that a 789 prospective certification path (a sequence of n certificates) 790 satisfies the following conditions: 792 1. for all 'x' in {1, ..., n-1}, the Subject of certificate 'x' 793 is the Issuer of certificate ('x' + 1); 795 2. certificate '1' is issued by a trust anchor; 797 3. certificate 'n' is the certificate to be validated; and 799 4. for all 'x' in {1, ..., n}, certificate 'x' is valid. 801 Certificate validation entails verifying that all of the following 802 conditions hold, in addition to the Certification Path Validation 803 criteria specified in Section 6 of [RFC5280]: 805 1. The certificate can be verified using the Issuer's public key 806 and the signature algorithm 808 2. The current time lies within the certificate's Validity From 809 and To values. 811 3. The certificate contains all fields that MUST be present, as 812 defined by this specification, and contains values for 813 selected fields that are defined as allowable values by this 814 specification. 816 4. No field, or field value, that this specification defines as 817 MUST NOT be present is used in the certificate. 819 5. The Issuer has not revoked the certificate. A revoked 820 certificate is identified by the certificate's serial number 821 being listed on the Issuer's current CRL, as identified by the 822 CRLDP of the certificate, the CRL is itself valid, and the 823 public key used to verify the signature on the CRL is the same 824 public key used to verify the certificate itself. 826 6. That the resource extension data is "encompassed" by the 827 resource extension data contained in a valid certificate where 828 this Issuer is the Subject (the previous certificate in the 829 context of the ordered sequence defined by the Certification 830 Path). 832 7. The Certification Path originates with a certificate issued by 833 a trust anchor, and there exists a signing chain across the 834 Certification Path where the Subject of Certificate 'x' in the 835 Certification Path matches the Issuer in Certificate 'x + 1' 836 in the Certification Path, and the public key in Certificate 837 'x' can verify the signature value in Certificate 'x+1'. 839 A certificate validation algorithm MAY perform these tests in any 840 chosen order. 842 Certificates and CRLs used in this process MAY be found in a locally 843 maintained cache, maintained by a regular synchronisation across the 844 distributed publication repository structure [ID.sidr-repos-struct]. 846 There exists the possibility of encountering certificate paths that 847 are arbitrarily long, or attempting to generate paths with loops as 848 means of creating a potential DOS attack on an RP. A RP executing 849 this procedure MAY apply further heuristics to guide halting the 850 certification path validation process in order to avoid some of the 851 issues associated with attempts to validate such malformed 852 certification path structures. Implementations of Resource 853 Certificate validation MAY halt with a validation failure if the 854 certification path length exceeds a locally defined configuration 855 parameter. 857 8. Design Notes 859 The following notes provide some additional commentary on the 860 considerations that lie behind some of the design choices that were 861 made in the design of this certificate profile. These notes are non- 862 normative, i.e. this section of the document does not constitute a 863 formal part of the profile specification, and the interpretation of 864 key words as defined in RFC2119 are not applicable in this section of 865 the document. 867 Certificate Extensions: 868 This profile does not permit the use of any other critical or 869 non-critical extensions. The rationale for this restriction is 870 that the resource certificate profile is intended for a 871 specific define use. In this context it is not seen as being 872 appropriate to be in the position of having certificates with 873 additional non-critical extensions that RPs may see as valid 874 certificates without understanding the extensions, but were the 875 RP in a position to understand the extensions, would contradict 876 or qualify in some way this original judgment of validity. 877 This profile takes the position of minimalism over 878 extensibility. The specific goal for the associated RPKI is to 879 precisely match the INR allocation structure through an aligned 880 certificate structure that describes the allocation and its 881 context within the INR distribution hierarchy. The profile 882 defines a resource certificate that is structured to meet these 883 requirements. 885 Certification Authorities and Key Values: 886 This profile uses a definition of an instance of a CA as a 887 combination of a named entity and a key pair. Within this 888 definition a CA instance cannot rollover a key pair. However, 889 the entity can generate a new instance of a CA with a new key 890 pair and roll over all the signed subordinate products to the 891 new CA [ID.sidr-keyroll]. 893 This has a number of implications in terms of Subject name 894 management, CRL Scope and repository publication point 895 management. 897 CRL Scope and Key Values: 898 For CRL Scope this profile specifies that a CA issues a single 899 CRL at a time, and the scope of the CRL is all certificates 900 issued by this CA. Because the CA instance is bound to a 901 single key pair this implies that the CA's public key, the key 902 used to validate the CA's CRL, and the key used to validate the 903 certificates revoked by that CRL are all the same key value. 905 Repository Publication Point: 906 The definition of a CA affects the design of the repository 907 publication system. In order to minimize the amount of forced 908 re-certification on key rollover events, a repository 909 publication regime that uses the same repository publication 910 point for all CA instances that refers to the same entity, but 911 with different key values will minimize the extent of re- 912 generation of certificates to only immediate subordinate 913 certificates. This is described in [ID.sidr-keyroll]. 915 Subject Name: 916 This profile specifies that Subject names must be unique per 917 Issuer, and does not specify that Subject names must be 918 globally unique (in terms of assured uniqueness). This is due 919 to the nature of the RPKI as a distributed PKI, implying that 920 there is no ready ability for Certification authorities to 921 coordinate a simple RPKI-wide unique name space without 922 resorting to additional critical external dependencies. CAs 923 are advised to use Subject name generation procedures that 924 minimize the potential for name clashes. 926 One way to achieve this is for a CA to use a Subject name 927 practice that uses the CommonName component of the 928 Distinguished Name as a constant value for any given entity 929 that is the Subject of CA-issued certificates, and set the 930 serialNumber component of the Distinguished Name to a value 931 that is derived from the hash of the subject public key value. 933 If the CA elects not to use the serialNumber component of the 934 DistinguishedName, then it is considered beneficial that a CA 935 generates CommonNames that have themselves a random component 936 that includes significantly more than 40 bits of entropy in the 937 name. Some non-normative recommendations to achieve this 938 include: 940 1) Hash of the subject public key (encoded as ASCII HEX). 941 example: cn="999d99d564de366a29cd8468c45ede1848e2cc14" 943 2) A Universally Unique IDentifier (UUID) [RFC4122] 944 example: cn="6437d442-6fb5-49ba-bbdb-19c260652098" 946 3) A randomly generated ASCII HEX encoded string of length 947 20 or greater: 948 example: cn="0f8fcc28e3be4869bc5f8fa114db05e1"> 949 (A string of 20 ASCII HEX digits would have 80-bits of 950 entropy) 952 4) An internal database key or subscriber ID combined with 953 one of the above 954 example: cn=" (6437d442-6fb5-49ba-bbdb- 955 19c2606520980)" 956 (The issuing CA may wish to be able to extract the 957 database key or subscriber ID from the commonName. Since 958 only the issuing CA would need to be able to parse the 959 commonName, the database key and the source of entropy 960 (e.g., a UUID) could be separated in any way that the CA 961 wanted, as long as it conformed to the rules for 962 PrintableString. The separator could be a space 963 character, parenthesis, hyphen, slash, question mark, 964 etc. 966 9. Operational Considerations for Profile Agility 968 This profile requires that relying parties reject certificates or 969 CRLs that do not conform to the profile. (Through the remainder of 970 this section the term "certificate" is used to refer to both 971 certificates and CRLs.) This includes certificates that contain 972 extensions that are prohibited, but which are otherwise valid as per 973 [RFC5280]. This means that any change in the profile (e.g., 974 extensions, permitted attributes or optional fields, or field 975 encodings) for certificates used in the RPKI will not be backward 976 compatible. In a general PKI context this constraint probably would 977 cause serious problems. In the RPKI, several factors minimize the 978 difficulty of effecting changes of this sort. 980 Note that the RPKI is unique in that every relying party (RP) 981 requires access to every certificate and every CRL issued by the CAs 982 in this system. An important update of the certificates and CRLs 983 used in the RPKI must be supported by all CAs and RPs in the system, 984 lest views of the RPKI data differ across RPs. Thus incremental 985 changes require very careful coordination. It would not be 986 appropriate to introduce a new extension, or authorize use of an 987 extant, standard extension, for a security-relevant purpose on a 988 piecemeal basis. 990 One might imagine that the "critical" flag in X.509 certificate and 991 CRL extensions could be used to ameliorate this problem. However, 992 this solution is not comprehensive, and does not address the problem 993 of adding a new, security-critical extension. (This is because such 994 an extension needs to be supported universally, by all CAs and RPs.) 995 Also, while some standard extensions can be marked either critical or 996 non-critical, at the discretion of the issuer, not all have this 997 property, i.e., some standard extensions are always non-critical. 998 Moreover, there is no notion of criticality for attributes within a 999 name or optional fields within a field or an extension. Thus the 1000 critical flag is not a solution to this problem. 1002 In typical PKI deployments there are few CAs and many RPs. However, 1003 in the RPKI, essentially every CA in the RPKI is also an RP. Thus 1004 the set of entities that will need to change in order to issue 1005 certificates under a new format is the same set of entities that will 1006 need to change to accept these new certificates. To the extent that 1007 this is literally true it says that CA/RP coordination for a change 1008 is tightly linked anyway. In reality there is an important exception 1009 to this general observation. Small ISPs and holders of provider- 1010 independent allocations are expected to use managed CA services, 1011 offered by Regional Internet Registries (RIRs) and potentially by 1012 wholesale Internet Service Providers (ISPs). This reduces the number 1013 of distinct CA implementations that are needed, and makes it easier 1014 to effect changes for certificate issuance. It seems very likely 1015 that these entities also will make use of RP software provided by 1016 their managed CA service provider, which reduces the number of 1017 distinct RP software implementations. Also note that many small ISPs 1018 (and holders of provider-independent allocations) employ default 1019 routes, and thus need not perform RP validation of RPKI data, 1020 eliminating these entities as RPs. 1022 Widely available PKI RP software does not cache large numbers of 1023 certificates and CRLs, an essential strategy for the RPKI. It does 1024 not process manifest or ROA data structures, essential elements of 1025 the RPKI repository system. Experience shows that such software 1026 deals poorly with revocation status data. Thus extant RP software is 1027 not adequate for the RPKI, although some open source tools (e.g., 1028 OpenSSL and cryptlib) can be used as building blocks for an RPKI RP 1029 implementation. Thus it is anticipated that RPs will make use of 1030 software designed specifically for the RPKI environment, and 1031 available from a limited number of open sources. Several RIRs and 1032 two companies are providing such software today. Thus it is feasible 1033 to coordinate change to this software among the small number of 1034 developers/maintainers. 1036 If the resource certificate profile is changed in the future, e.g., 1037 by adding a new extension or changing the allowed set of name 1038 attributes or encoding of these attributes, the following procedure 1039 will be employed to effect deployment in the RPKI. The model is 1040 analogous to that described in [ID.sidr-algorithm-agility], but is 1041 simpler. 1043 A new document will be issued as an update to this RFC. The CP for 1044 the RPKI [ID.sidr-cp] will be updated to reference the new 1045 certificate profile. The new CP will define a new policy OID for 1046 certificates issued under the new certificate profile. The updated 1047 CP also will define a timeline for transition to the new certificate 1048 (CRL) format. This timeline will define 3 phases and associated 1049 dates: 1051 1. At the end of phase 1, all RPKI CAs MUST be capable of issuing 1052 certificates under the new profile, if requested by a subject. 1053 Any certificate issued under the new format will contain the 1054 new policy OID. 1056 2. During phase 2 CAs MUST issue certificates under the new 1057 profile, and these certificates MUST co-exist with 1058 certificates issued under the old format. (CAs will continue 1059 to issue certificates under the old OID/format as well.) The 1060 old and new certificates MUST be identical, except for the 1061 policy OID and any new extensions, encodings, etc. The new 1062 certificates, and associated signed objects, will coexist in 1063 the RPKI repository system during this phase, analogous to 1064 what is required by an algorithm transition for the RPKI 1065 [ID.sidr-algorithm-agility]. Relying parties MAY make use of 1066 the old or the new certificate formats when processing signed 1067 objects retrieved from the RPKI repository system. During 1068 this phase, a relying party that elects to process both 1069 formats will acquire the same values for all certificate 1070 fields that overlap between the old and new formats. Thus if 1071 either certificate format is verifiable, the relying party 1072 accepts the data from that certificate. This allows CAs to 1073 issue certificates under the new format before all relying 1074 parties are prepared to process that format. 1076 3. At the beginning of phase 3, all relying parties MUST be 1077 capable of processing certificates under the new format. 1078 During this phase CAs will issue new certificates ONLY under 1079 the new format. During this phase, certificates issued under 1080 the old OID will be replaced with certificates containing the 1081 new policy OID. The repository system will no longer require 1082 matching old and new certificates under the different formats. 1084 At the end of phase 3, all certificates under the old OID will have 1085 been replaced. The resource certificate profile RFC will be replaced 1086 to remove support for the old certificate format, and the CP will be 1087 replaced to remove reference to the old policy OID and to the old 1088 resource certificate profile RFC. The system will have returned to a 1089 new, steady state. 1091 10. Security Considerations 1093 The Security Considerations of [RFC5280] and [RFC3779] apply to 1094 Resource Certificates. The Security Considerations of [RFC2986] and 1095 [RFC4211] apply to Resource Certificate certification requests. 1097 A Resource Certificate PKI cannot in and of itself resolve any forms 1098 of ambiguity relating to uniqueness of assertions of rights of use in 1099 the event that two or more valid certificates encompass the same 1100 resource. If the issuance of resource certificates is aligned to the 1101 status of resource allocations and assignments then the information 1102 conveyed in a certificate is no better than the information in the 1103 allocation and assignment databases. 1105 This profile requires that the key used to sign an issued certificate 1106 is the same key used to sign the CRL that can revoke the certificate, 1107 implying that the certification path used to validate the signature 1108 on a certificate is the same as that used to validate the signature 1109 of the CRL that can revoke the certificate. It is noted that this is 1110 a higher constraint than required in X.509 PKIs, and there may be a 1111 risk in using a path validation implementation that is capable of 1112 using separate validation paths for a certificate and the 1113 corresponding CRL. If there are subject name collisions in the RPKI 1114 as a result of CAs not following the guidelines provided here 1115 relating to ensuring sufficient entropy in constructing subject 1116 names, and this is combined with the situation that an RP uses an 1117 implementation of validation path construction that is not in 1118 conformance with this RPKI profile, then it is possible that the 1119 subject name collisions can cause an RP to conclude that an otherwise 1120 valid certificate has been revoked. 1122 11. IANA Considerations 1124 [Note to IANA, to be removed prior to publication: there are no IANA 1125 considerations stated in this document.] 1127 12. Acknowledgements 1129 The authors would like to particularly acknowledge the valued 1130 contribution from Stephen Kent in reviewing this document and 1131 proposing numerous sections of text that have been incorporated into 1132 the text. The authors also acknowledge the contributions of Sandy 1133 Murphy, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo Patara 1134 and Rob Austein in the preparation and subsequent review of this 1135 document. The document also reflects review comments received from 1136 Roque Gagliano, Sean Turner and David Cooper. 1138 13. References 1139 13.1. Normative References 1141 [ID.sidr-cp] 1142 Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 1143 Policy (CP) for the Resource PKI (RPKI)", Work in 1144 progress: Internet Drafts draft-ietf-sidr-c-13.txt, 1145 September 2010. 1147 [ID.sidr-rpki-algs] 1148 Huston, G., "A Profile for Algorithms and Key Sizes for 1149 use in the Resource Public Key Infrastructure", Work in 1150 progress: Internet 1151 Drafts draft-ietf-sidr-rpki-algs-00.txt, August 2009. 1153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1154 Requirement Levels", BCP 14, RFC 2119, March 1997. 1156 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1157 Request Syntax Specification Version 1.7", RFC 2986, 1158 November 2000. 1160 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1161 Addresses and AS Identifiers", RFC 3779, June 2004. 1163 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1164 Certificate Request Message Format (CRMF)", RFC 4211, 1165 September 2005. 1167 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1168 Housley, R., and W. Polk, "Internet X.509 Public Key 1169 Infrastructure Certificate and Certificate Revocation List 1170 (CRL) Profile", RFC 5280, May 2008. 1172 [X.509] ITU-T, "Recommendation X.509: The Directory - 1173 Authentication Framework", 2000. 1175 [X.680] ITU-T, "Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 1176 Information technology - Abstract Syntax Notation One 1177 (ASN.1): Specification of basic notation", 2002. 1179 13.2. Informative References 1181 [ID.sidr-algorithm-agility] 1182 Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 1183 Procedure for RPKI", Work in progress: Internet 1184 Drafts draft-ietf-sidr-algorithm-agility-00.txt, 1185 February 2011. 1187 [ID.sidr-arch] 1188 Lepinski, M. and S. Kent, "An Infrastructure to Support 1189 Secure Internet Routing", Work in progress: Internet 1190 Drafts draft-ietf-sidr-arch-04.txt, November 2008. 1192 [ID.sidr-keyroll] 1193 Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover 1194 in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in 1195 progress), October 2010. 1197 [ID.sidr-repos-struct] 1198 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1199 Resource Certificate Repository Structure", 1200 draft-ietf-sidr-repos-struct-04.txt (work in progress), 1201 May 2010. 1203 [ID.sidr-rpki-manifests] 1204 Austein, R., Huston, G., Kent, S., and M. Lepinski, 1205 "Manifests for the Resource Public Key Infrastructure", 1206 Work in progress: Internet 1207 Drafts draft-ietf-sidr-rpki-manifests-04.txt, 1208 October 2008. 1210 [ID.sidr-signed-object] 1211 Lepinski, M., Chi, A., and S. Kent, "Signed Object 1212 Template for the Resource Public Key Infrastructure", 1213 draft-ietf-sidr-signed-object-01.txt (work in progress), 1214 October 2010. 1216 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1217 Classes and Attribute Types Version 2.0", RFC 2985, 1218 November 2000. 1220 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1221 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1222 July 2005. 1224 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 1225 (LDAP): String Representation of Distinguished Names", 1226 RFC 4514, June 2006. 1228 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 1229 Scheme", RFC 5781, February 2010. 1231 Appendix A. Example Resource Certificate 1233 The following is an example Resource Certificate. 1235 Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer 1237 Data: 1238 Version: 3 (0x2) 1239 Serial: 1500 (0x5dc) 1240 Signature Algorithm: SHA256WithRSAEncryption 1241 Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s 1242 Validity 1243 Not Before: Oct 25 12:50:00 2008 GMT 1244 Not After : Jan 31 00:00:00 2010 GMT 1245 Subject: CN=A91872ED 1246 Subject Public Key Info: 1247 Public Key Algorithm: rsaEncryption 1248 RSA Public Key: (2048 bit) 1249 Modulus (2048 bit): 1250 00:bb:fb:4a:af:a4:b9:dc:d0:fa:6f:67:cc:27:39: 1251 34:d1:80:40:37:de:88:d1:64:a2:f1:b3:fa:c6:7f: 1252 bb:51:df:e1:c7:13:92:c3:c8:a2:aa:8c:d1:11:b3: 1253 aa:99:c0:ac:54:d3:65:83:c6:13:bf:0d:9f:33:2d: 1254 39:9f:ab:5f:cd:a3:e9:a1:fb:80:7d:1d:d0:2b:48: 1255 a5:55:e6:24:1f:06:41:35:1d:00:da:1f:99:85:13: 1256 26:39:24:c5:9a:81:15:98:fb:5f:f9:84:38:e5:d6: 1257 70:ce:5a:02:ca:dd:61:85:b3:43:2d:0b:35:d5:91: 1258 98:9d:da:1e:0f:c2:f6:97:b7:97:3e:e6:fc:c1:c4: 1259 3f:30:c4:81:03:25:99:09:4c:e2:4a:85:e7:46:4b: 1260 60:63:02:43:46:51:4d:ed:fd:a1:06:84:f1:4e:98: 1261 32:da:27:ee:80:82:d4:6b:cf:31:ea:21:af:6f:bd: 1262 70:34:e9:3f:d7:e4:24:cd:b8:e0:0f:8e:80:eb:11: 1263 1f:bc:c5:7e:05:8e:5c:7b:96:26:f8:2c:17:30:7d: 1264 08:9e:a4:72:66:f5:ca:23:2b:f2:ce:54:ec:4d:d9: 1265 d9:81:72:80:19:95:57:da:91:00:d9:b1:e8:8c:33: 1266 4a:9d:3c:4a:94:bf:74:4c:30:72:9b:1e:f5:8b:00: 1267 4d:e3 1268 Exponent: 65537 (0x10001) 1269 X509v3 extensions: 1270 X509v3 Subject Key Identifier: 1271 F4:97:E0:00:47:2A:ED:0F:B8:EC:8C:0C:0B:90:89: 1272 20:9A:FA:10:9B 1274 X509v3 Authority Key Identifier: 1275 keyid:09:53:D0:4A:05:24:2F:2E:E9:39:77:4D:79: 1276 55:86:BE:71:57:FF:4B 1278 X509v3 Key Usage: critical 1279 Certificate Sign, CRL Sign 1281 X509v3 Basic Constraints: critical 1282 CA:TRUE 1284 X509v3 CRL Distribution Points: 1285 URI:rsync://rpki.apnic.net/repository/A3C38A24 1286 D60311DCAB08F31979BDBE39/CVPQSgUkLy7pOXdNe 1287 VWGvnFX_0s.crl 1289 Authority Information Access: 1290 CA Issuers - URI:rsync://rpki.apnic.net/repos 1291 itory/8BDFC7DED5FD11DCB14CF4B1A703F9B7/CVP 1292 QSgUkLy7pOXdNeVWGvnFX_0s.cer 1294 X509v3 Certificate Policies: critical 1295 Policy: 1.3.6.1.5.5.7.14.2 1297 Subject Information Access: 1298 CA Repository - URI:rsync://rpki.apnic.net/mem 1299 ber_repository/A91872ED/06A83982887911DD81 1300 3F432B2086D636/ 1301 Manifest - URI:rsync://rpki.apnic.net/member_r 1302 epository/A91872ED/06A83982887911DD813F432 1303 B2086D636/9JfgAEcq7Q-47IwMC5CJIJr6EJs.mft 1305 sbgp-autonomousSysNum: critical 1306 Autonomous System Numbers: 1307 24021 1308 38610 1309 131072 1310 131074 1312 sbgp-ipAddrBlock: critical 1313 IPv4: 1314 203.133.248.0/22 1315 203.147.108.0/23 1317 Signature Algorithm: sha256WithRSAEncryption 1318 51:4c:77:e4:21:64:80:e9:35:30:20:9f:d8:4b:88:60:b8:1f: 1319 73:24:9d:b5:17:60:65:6a:28:cc:43:4b:68:97:ca:76:07:eb: 1320 dc:bd:a2:08:3c:8c:56:38:c6:0a:1e:a8:af:f5:b9:42:02:6b: 1321 77:e0:b1:1c:4a:88:e6:6f:b6:17:d3:59:41:d7:a0:62:86:59: 1322 29:79:26:76:34:d1:16:2d:75:05:cb:b2:99:bf:ca:c6:68:1b: 1323 b6:a9:b0:f4:43:2e:df:e3:7f:3c:b3:72:1a:99:fa:5d:94:a1: 1324 eb:57:9c:9a:2c:87:d6:40:32:c9:ff:a6:54:b8:91:87:fd:90: 1325 55:ef:12:3e:1e:2e:cf:c5:ea:c3:4c:09:62:4f:88:00:a0:7f: 1326 cd:67:83:bc:27:e1:74:2c:18:4e:3f:12:1d:ef:29:0f:e3:27: 1327 00:ce:14:eb:f0:01:f0:36:25:a2:33:a8:c6:2f:31:18:22:30: 1328 cf:ca:97:43:ed:84:75:53:ab:b7:6c:75:f7:2f:55:5c:2e:82: 1329 0a:be:91:59:bf:c9:06:ef:bb:b4:a2:71:9e:03:b1:25:8e:29: 1330 7a:30:88:66:b4:f2:16:6e:df:ad:78:ff:d3:b2:9c:29:48:e3: 1331 be:87:5c:fc:20:2b:df:da:ca:30:58:c3:04:c9:63:72:48:8c: 1333 0a:5f:97:71 1335 Appendix B. Example Certificate Revocation List 1337 The following is an example Certificate Revocation List. 1339 CRL Name: q66IrWSGuBE7jqx8PAUHAlHCqRw.crl 1340 Data: 1341 Version: 2 1342 Signature Algorithm: 1343 Hash: SHA256, Encryption: RSA 1344 Issuer: CN=Demo Production APNIC CA - Not for real use, 1345 E=ca@apnic.net 1346 This Update: Thu Jul 27 06:30:34 2006 GMT 1347 Next Update: Fri Jul 28 06:30:34 2006 GMT 1348 Authority Key Identifier: Key Identifier: 1349 ab:ae:88:ad:64:86:b8:11:3b:8e:ac:7c:3c:05: 1350 07:02:51:c2:a9:1c 1351 CRLNumber: 4 1352 Revoked Certificates: 1 1353 Serial Number: 1 1354 Revocation Date: Mon Jul 17 05:10:19 2006 GMT 1355 Serial Number: 2 1356 Revocation Date: Mon Jul 17 05:12:25 2006 GMT 1357 Serial Number: 4 1358 Revocation Date: Mon Jul 17 05:40:39 2006 GMT 1359 Signature: 1360 b2:5a:e8:7c:bd:a8:00:0f:03:1a:17:fd:40:2c:46: 1361 0e:d5:64:87:e7:e7:bc:10:7d:b6:3e:39:21:a9:12: 1362 f4:5a:d8:b8:d4:bd:57:1a:7d:2f:7c:0d:c6:4f:27: 1363 17:c8:0e:ae:8c:89:ff:00:f7:81:97:c3:a1:6a:0a: 1364 f7:d2:46:06:9a:d1:d5:4d:78:e1:b7:b0:58:4d:09: 1365 d6:7c:1e:a0:40:af:86:5d:8c:c9:48:f6:e6:20:2e: 1366 b9:b6:81:03:0b:51:ac:23:db:9f:c1:8e:d6:94:54: 1367 66:a5:68:52:ee:dd:0f:10:5d:21:b8:b8:19:ff:29: 1368 6f:51:2e:c8:74:5c:2a:d2:c5:fa:99:eb:c5:c2:a2: 1369 d0:96:fc:54:b3:ba:80:4b:92:7f:85:54:76:c9:12: 1370 cb:32:ea:1d:12:7b:f8:f9:a2:5c:a1:b1:06:8e:d8: 1371 c5:42:61:00:8c:f6:33:11:29:df:6e:b2:cc:c3:7c: 1372 d3:f3:0c:8d:5c:49:a5:fb:49:fd:e7:c4:73:68:0a: 1373 09:0e:6d:68:a9:06:52:3a:36:4f:19:47:83:59:da: 1374 02:5b:2a:d0:8a:7a:33:0a:d5:ce:be:b5:a2:7d:8d: 1375 59:a1:9d:ee:60:ce:77:3d:e1:86:9a:84:93:90:9f: 1376 34:a7:02:40:59:3a:a5:d1:18:fb:6f:fc:af:d4:02: 1377 d9 1379 Authors' Addresses 1381 Geoff Huston 1382 APNIC 1384 Email: gih@apnic.net 1385 URI: http://www.apnic.net 1387 George Michaelson 1388 APNIC 1390 Email: ggm@apnic.net 1391 URI: http://www.apnic.net 1393 Robert Loomans 1394 APNIC 1396 Email: robertl@apnic.net 1397 URI: http://www.apnic.net