idnits 2.17.1 draft-ietf-sidr-res-certs-19.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 (October 14, 2010) is 4942 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 (-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 (~~), 8 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: April 17, 2011 APNIC 6 October 14, 2010 8 A Profile for X.509 PKIX Resource Certificates 9 draft-ietf-sidr-res-certs-19 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 Resources (INRs). The certificates issued under this profile are 16 used to convey the Issuer's authorisation of the Subject to be 17 regarded as the current holder of a "right-of-use" of the INRs that 18 are described in the certificate. This document contains the 19 normative specification of Certificate and Certificate Revocation 20 List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). 21 The document also specifies profiles for the format of certificate 22 requests. The document also specifies the Relying Party RPKI 23 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 April 17, 2011. 42 Copyright Notice 44 Copyright (c) 2010 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 3.1. Single-Use EE Certificates . . . . . . . . . . . . . . . . 6 65 3.2. Multi-Use EE Certificates . . . . . . . . . . . . . . . . 6 66 4. Resource Certificates . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Serial number . . . . . . . . . . . . . . . . . . . . . . 6 69 4.3. Signature Algorithm . . . . . . . . . . . . . . . . . . . 7 70 4.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.5. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.6. Valid From . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.7. Valid To . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.8. Subject Public Key Info . . . . . . . . . . . . . . . . . 8 75 4.9. Resource Certificate Extensions . . . . . . . . . . . . . 8 76 4.9.1. Basic Constraints . . . . . . . . . . . . . . . . . . 8 77 4.9.2. Subject Key Identifier . . . . . . . . . . . . . . . . 9 78 4.9.3. Authority Key Identifier . . . . . . . . . . . . . . . 9 79 4.9.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 9 80 4.9.5. Extended Key Usage . . . . . . . . . . . . . . . . . . 9 81 4.9.6. CRL Distribution Points . . . . . . . . . . . . . . . 9 82 4.9.7. Authority Information Access . . . . . . . . . . . . . 10 83 4.9.8. Subject Information Access . . . . . . . . . . . . . . 11 84 4.9.9. Certificate Policies . . . . . . . . . . . . . . . . . 12 85 4.9.10. IP Resources . . . . . . . . . . . . . . . . . . . . . 12 86 4.9.11. AS Resources . . . . . . . . . . . . . . . . . . . . . 13 87 5. Resource Certificate Revocation Lists . . . . . . . . . . . . 13 88 6. Resource Certificate Requests . . . . . . . . . . . . . . . . 14 89 6.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 14 90 6.1.1. PKCS#10 Resource Certificate Request Template 91 Fields . . . . . . . . . . . . . . . . . . . . . . . . 14 92 6.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 15 93 6.2.1. CRMF Resource Certificate Request Template Fields . . 15 94 6.2.2. Resource Certificate Request Control Fields . . . . . 16 95 6.3. Certificate Extension Attributes in Certificate 96 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. Security Considerations . . . . . . . . . . . . . . . . . . . 22 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 103 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 105 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 106 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 107 Appendix A. Example Resource Certificate . . . . . . . . . . . . 25 108 Appendix B. Example Certificate Revocation List . . . . . . . . . 27 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 111 1. Introduction 113 This document defines a standard profile for X.509 certificates 114 [X.509] for use in the context of certification of Internet Number 115 Resources (INRs), i.e., IP Addresses and Autonomous System (AS) 116 Numbers. Such certificates are termed "Resource Certificates". A 117 Resource Certificate is a certificate that conforms to the PKIX 118 profile [RFC5280], and that conforms to the constraints specified in 119 this profile. A Resource Certificate attests that the Issuer has 120 granted the Subject a "right-of-use" for a listed set of IP addresses 121 and/or Autonomous System numbers. 123 This document is referenced by Section 7 of the Certificate Policy 124 (CP) for the Resource Public Key Infrastructure (RPKI) [ID.sidr-cp]. 125 It is an integral part of that policy and the normative specification 126 for certificate and Certificate Revocation List (CRL) syntax used in 127 the RPKI. The document also specifies profiles for the format of 128 certificate requests, and the Relying Party (RP) RPKI certificate 129 path validation procedure. 131 Resource Certificates are to be used in a manner that is consistent 132 with the RPKI Certificate Policy [ID.sidr-cp]. They are issued by 133 entities that assign and/or allocate public INRs, and thus the RPKI 134 is aligned with the public INR distribution function. When an INR is 135 allocated or assigned by a number registry to an entity, this 136 allocation can be described by an associated Resource Certificate. 137 This certificate is issued by the number registry, and it binds the 138 certificate subject's key to the INRs enumerated in the certificate. 139 One or two critical extensions, the IP Address Delegation or AS 140 Identifier Delegation Extensions [RFC3779], enumerate the INRs that 141 were allocated or assigned by the Issuer to the Subject. 143 RP validation of a Resource Certificate is performed in the manner 144 specified in Section 7.1. This validation procedure differs from 145 that described in section 6 of [RFC5280], such that: 146 o additional validation processing imposed by the INR extensions is 147 required, 148 o a conformation of a public key match between the CRL issuer and 149 the Resource Certificate issuer is required, and 150 o the Resource Certificate is required to conform to this profile. 152 This profile defines those fields that are used in a Resource 153 Certificate that MUST be present for the certificate to be valid. 154 Any extensions not explicitly mentioned MUST be absent. The same 155 applies to the CRLs used in the RPKI, that are also profiled in this 156 document. A CA conforming to the RPKI CP MUST issue certificates and 157 CRLs consistent with this profile. 159 1.1. Terminology 161 It is assumed that the reader is familiar with the terms and concepts 162 described in "Internet X.509 Public Key Infrastructure Certificate 163 and Certificate Revocation List (CRL) Profile" [RFC5280], and "X.509 164 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119. 170 2. Describing Resources in Certificates 172 The framework for describing an association between the Subject of a 173 certificate and the INRs currently under the Subject's control is 174 described in [RFC3779]. This profile further requires that: 176 o Every Resource Certificate MUST contain either the IP Address 177 Delegation or the Autonomous System Identifier Delegation 178 extension, or both. 180 o These extensions MUST be marked as CRITICAL. 182 o The sorted canonical format describing INRs, with maximal spanning 183 ranges and maximal spanning prefix masks, as defined in [RFC3779], 184 MUST be used for the resource extension field, except where the 185 "inherit" construct is used instead. 187 When validating a Resource Certificate, a RP MUST verify that the 188 INRs described in the Issuer's Resource Certificate encompass the 189 INRs of the Resource Certificate being validated. In this context 190 "encompass" allows for the Issuer's INRs to be the same as, or a 191 strict superset of the Subject's INRs. 193 3. End-Entity (EE) Certificates and Signing Functions in the RPKI 195 As noted in [ID.sidr-arch], the primary function of End-Entity (EE) 196 certificates in the RPKI is the verification of signed objects that 197 relate to the usage of the INRs described in the certificate, e.g., 198 Route Origin Authorizations (ROAs) and manifests. There are two 199 types of EE certificates defined within the RPKI framework: single- 200 use and multi-use. 202 3.1. Single-Use EE Certificates 204 The private key associated with a "single-use" EE certificate is used 205 to sign a single RPKI signed object, i.e., the single-use EE 206 certificate is used to validate only one object. The certificate is 207 embedded in the object as part of a Cryptographic Message Syntax 208 (CMS) signed data structure [ID.sidr-signed-object].Because of the 209 one-to-one relationship between the single-use EE certificate and the 210 signed object, revocation of the certificate effectively revokes the 211 corresponding signed object. 213 3.2. Multi-Use EE Certificates 215 If the private key associated with an EE certificate is intended to 216 be used to validate more than one RPKI signed object, then the 217 certificate is termed a "multi-use" EE certificate. All objects that 218 can be verified under a multi-use EE certificate are revoked when the 219 certificate is revoked. 221 4. Resource Certificates 223 A Resource Certificate is a valid X.509 public key certificate, 224 consistent with the PKIX profile [RFC5280], containing the fields 225 listed in this section. Only the differences from [RFC5280] are 226 noted below. 228 Unless specifically noted as being OPTIONAL, all the fields listed 229 here MUST be present, and any other field MUST NOT appear in a 230 conforming Resource Certificate. Where a field value is specified 231 here, this value MUST be used in conforming Resource Certificates. 233 4.1. Version 235 As Resource Certificates are X.509 Version 3 certificates, the 236 version MUST be 3 (i.e. the value of this field is 2). 238 RPs need not process version 1 or version 2 certificates (in contrast 239 to [RFC5280]). 241 4.2. Serial number 243 The serial number value is a positive integer that is unique for each 244 certificate issued by a given CA. 246 4.3. Signature Algorithm 248 The algorithm used in this profile is specified in 249 [ID.sidr-rpki-algs]. 251 4.4. Issuer 253 The value of this field is a valid X.501 distinguished name. 255 An Issuer name MUST contain one instance of the Common Name attribute 256 and MAY contain one instance of the Serial Number attribute. If both 257 attributes are present, it is RECOMMENDED that they appear as a set. 258 The Common Name attribute MUST be encoded as a printable string. 259 Issuer names are not intended to be descriptive of the identity of 260 Issuer. 262 The RPKI does not rely on Issuer names being globally unique, for 263 reasons of security. However, it is RECOMMENDED that Issuer names be 264 generated in a fashion that minimizes the likelihood of collisions. 265 See Section 8 for (non-normative) suggested name generation 266 mechanisms that fulfil this recommendation. 268 4.5. Subject 270 The value of this field is a valid X.501 distinguished name, and is 271 subject to the same constraints as the Issuer name. 273 In the RPKI the Subject name is determined by the Issuer, not 274 proposed by the subject [ID.sidr-repos-struct]. Each distinct 275 subordinate CA and EE certified by the Issuer MUST be identified 276 using a Subject name that is unique per Issuer. In this context 277 "distinct" is defined as an entity and a given public key. An Issuer 278 SHOULD use a different Subject name if the Subject's key pair has 279 changed (i.e., when the CA issues a certificate as part of rekeying 280 the Subject.) Subject names are not intended to be descriptive of 281 the identity of Subject. 283 4.6. Valid From 285 The "Valid From" time SHOULD be no earlier than the time of 286 certificate generation. 288 In the RPKI it is valid for a certificate to have a value for this 289 field that pre-dates the same field value in any superior 290 certificate. Relying Parties SHOULD NOT attempt to infer from this 291 time information that a certificate was valid at a time in the past, 292 or will be valid at a time in the future, as the scope of a relying 293 party's test of validity of a certificate refers specifically to 294 validity at the current time. 296 4.7. Valid To 298 The Valid To time represents the anticipated lifetime of the current 299 resource allocation or assignment arrangement between the Issuer and 300 the Subject. 302 It is valid for a certificate to have a value for this field that 303 post-dates the same field value in any superior certificate. The 304 same caveats apply to RP's assumptions relating to the certificate's 305 validity at any time other than the current time. 307 While a CA is typically advised against issuing a certificate with a 308 validity interval that exceeds the validity interval of the CA's 309 certificate that will be used to validate the issued certificate, in 310 the context of this profile, a CA MAY have valid grounds to issue a 311 certificate with a validity interval that exceeds the validity 312 interval of its certificate. 314 4.8. Subject Public Key Info 316 The algorithm used in this profile is specified in 317 [ID.sidr-rpki-algs]. 319 4.9. Resource Certificate Extensions 321 The following X.509 V3 extensions MUST be present in a conforming 322 Resource Certificate, except where explicitly noted otherwise. Each 323 extension in a resource certificate is designated as either critical 324 or non-critical. A certificate-using system MUST reject the 325 certificate if it encounters a critical extension it does not 326 recognise; however, a non-critical extension MAY be ignored if it is 327 not recognised [RFC5280]. 329 4.9.1. Basic Constraints 331 The Basic Constraints extension field is a critical extension in the 332 Resource Certificate profile, and MUST be present when the Subject is 333 a CA, and MUST NOT be present otherwise. 335 The Issuer determines whether the "cA" boolean is set. 337 The Path Length Constraint is not specified for RPKI certificates, 338 and MUST NOT be present. 340 4.9.2. Subject Key Identifier 342 This extension MUST appear in all Resource Certificates. This 343 extension is non-critical. 345 The Key Identifier used for resource certificates is the 160-bit 346 SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the 347 Subject Public Key, as described in Section 4.2.1.2 of [RFC5280]. 349 4.9.3. Authority Key Identifier 351 This extension MUST appear in all Resource Certificates, with the 352 exception of a CA who issues a "self-signed" certificate. The 353 authorityCertIssuer and authorityCertSerialNumber fields MUST NOT be 354 present. This extension is non-critical. 356 The Key Identifier used for resource certificates is the 160-bit 357 SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the 358 Issuer's public key, as described in Section 4.2.1.1 of [RFC5280]. 360 4.9.4. Key Usage 362 This extension is a critical extension and MUST be present. 364 In certificates issued to Certification Authorities only the 365 keyCertSign and CRLSign bits are set to TRUE, and these MUST be the 366 only bits set to TRUE. 368 In EE certificates the digitalSignature bit MUST be set to TRUE and 369 MUST be the only bit set to TRUE. 371 4.9.5. Extended Key Usage 373 The Extended Key Usage (EKU) extension MUST NOT appear in any CA 374 certificate in the RPKI. This extension also MUST NOT appear in EE 375 certificates used to verify RPKI objects (e.g., ROAs or manifests. 376 The extension MUST NOT be marked critical. 378 The EKU extension MAY appear in EE certificates issued to routers or 379 other devices. Permitted values for the EKU OIDs will be specified 380 in Standards Track RFCs issued by other IETF working groups that 381 adopt the RPKI profile and that identify application-specific 382 requirements that motivate the use of such EKUs. 384 4.9.6. CRL Distribution Points 386 This extension MUST be present, except in "self-signed" certificates, 387 and it is non-critical. In a self-signed certificate this extension 388 MUST be omitted. 390 In this profile, the scope of the CRL is specified to be all 391 certificates issued by this CA Issuer. 393 The CRL Distribution Points (CRLDP) extension identifies the 394 location(s) of the CRL(s) associated with certificates issued by this 395 Issuer. The RPKI uses the URI form of object identification. The 396 preferred URI access mechanism is a single RSYNC URI ("rsync://") 397 [RFC5781] that references a single inclusive CRL for each Issuer. 399 In this profile the certificate Issuer is also the CRL Issuer, 400 implying that the CRLIssuer field MUST be omitted, and the 401 distributionPoint field MUST be present. The Reasons field MUST be 402 omitted. 404 The distributionPoint MUST contain the fullName field, and MUST NOT 405 contain a nameRelativeToCRLIssuer. The form of the generalName MUST 406 be of type URI. 408 The sequence of distributionPoint values MUST contain only a single 409 DistributionPoint. The DistributionPoint MAY contain more than one 410 URI value. An RSYNC URI [RFC5781] MUST be present in the 411 DistributionPoint, and reference the most recent instance of this 412 Issuer's CRL. Other access form URIs MAY be used in addition to the 413 RSYNC URI, representing alternate access mechanisms for this CRL. 415 4.9.7. Authority Information Access 417 In the context of the RPKI, this extension identifies the publication 418 point of the certificate of the issuer of the certificate in which 419 the extension appears. In this profile a single reference to the 420 publication point of the immediate superior certificate MUST be 421 present, except for a "self-signed" certificate, in which case the 422 extension MUST be omitted. This extension is non-critical. 424 This profile uses a URI form of object identification. The preferred 425 URI access mechanisms is "rsync", and an RSYNC URI [RFC5781] MUST be 426 specified with an accessMethod value of id-ad-caIssuers. The URI 427 MUST reference the point of publication of the certificate where this 428 Issuer is the Subject (the Issuer's immediate superior certificate). 429 Other accessMethod URIs referencing the same object MAY also be 430 included in the value sequence of this extension. 432 A CA MUST use a persistent URL name scheme for CA certificates that 433 it issues [ID.sidr-repos-struct]. This implies that a re-issued 434 certificate overwrites a previously issued certificate (to the same 435 Subject) in the publication repository. In this way certificates 436 subordinate to the re-issued (CA) certificate can maintain a constant 437 Authority Information Access (AIA) extension pointer and thus need 438 not be re-issued when the parent certificate is re-issued. 440 4.9.8. Subject Information Access 442 In the context of the RPKI, this extension (SIA) identifies the 443 publication point of products signed by the Subject of the 444 certificate. 446 4.9.8.1. SIA for CAs 448 This extension MUST be present, and is non-critical. 450 This extension MUST have an instance of an accessMethod of id-ad- 451 caRepository, with an accessLocation form of a URI that MUST specify 452 an RSYNC URI [RFC5781]. This URI points to the directory containing 453 all material issued by this CA. i.e., all valid CA certificates, 454 multi-use EE certificates, the current CRL, manifest and signed 455 objects signed by single-use EE certificates that have been issued by 456 this CA [ID.sidr-repos-struct]. Other accessDescription elements 457 with an accessMethod of id-ad-caRepository MAY be present. In such 458 cases, the accessLocation values describe alternate supported URI 459 access mechanisms for the same directory. The ordering of URIs in 460 this accessDescription sequence reflect the CA's relative preferences 461 for access methods to be used by relying parties, with he first 462 element of the sequence being the most preferred by the CA. 464 This extension MUST have an instance of an AccessDescription with an 465 accessMethod of id-ad-rpkiManifest, 467 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 469 id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 } 471 with an RSYNC URI [RFC5781] form of accessLocation. The URI points 472 to the CA's manifest of published objects [ID.sidr-rpki-manifests] as 473 an object URL. Other accessDescription elements MAY exist for the 474 id-ad-rpkiManifest accessMethod, where the accessLocation value 475 indicates alternate access mechanisms for the same manifest object. 477 4.9.8.2. SIA for Multi-use EEs 479 This extension MUST be present, and is non-critical. 481 This extension MUST have an instance of an accessMethod of id-ad- 482 signedObjectRepository, 483 id-ad-signedObjectRepository OBJECT IDENTIFIER ::= { id-ad 9 } 485 with an accessLocation form of a URI that MUST specify an RSYNC URI 486 [RFC5781]. This URI points to the directory containing all signed 487 objects that are verified using this EE certificate 488 [ID.sidr-repos-struct]. Other accessDescription elements MAY exist 489 for the id-ad-signedObjectRepository accessMethod, where the 490 accessLocation value indicates alternate supported access mechanisms 491 for the same directory, ordered in terms of the EE's relative 492 preference for supported access mechanisms. 494 This extension MUST have an instance of an AccessDescription with an 495 accessMethod of id-ad-rpkiManifest, with the same specification as 496 the CA's manifest. 498 4.9.8.3. SIA for Single-use EEs 500 This extension MUST be present, and is non-critical. 502 This extension MUST have an instance of an accessMethod of id-ad- 503 signedObject, 505 id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 } 507 with an accessLocation form of a URI that MUST include a RSYNC URI 508 [RFC5781]. This URI points to the signed object that is verified 509 using this EE certificate [ID.sidr-repos-struct]. Other 510 accessDescription elements may exist for the id-ad-signedObject 511 accessMethod, where the accessLocation value indicates alternate URI 512 access mechanisms for the same object, ordered in terms of the EE's 513 relative preference for supported access mechanisms. 515 Other AccessMethods MUST NOT be used for a single-use EE's SIA. 517 4.9.9. Certificate Policies 519 This extension MUST be present, and MUST be marked critical. It MUST 520 include exactly one policy, as specified in the RPKI CP [ID.sidr-cp] 522 4.9.10. IP Resources 524 Either the IP Resources extension, or the AS Resources extension, or 525 both, MUST be present in all RPKI certificates, and if present, MUST 526 be marked critical. 528 This extension contains the list of IP address resources as per 529 [RFC3779]. The value may specify the "inherit" element for a 530 particular AFI value. In the context of resource certificates 531 describing public number resources for use in the public Internet, 532 the SAFI value MUST NOT be used. 534 This extension MUST either specify a non-empty set IP address 535 records, or use the "inherit" setting to indicate that the IP address 536 resource set of this certificate is inherited from that of the 537 certificate's issuer. 539 4.9.11. AS Resources 541 Either the AS Resources extension, or the IP Resources extension, or 542 both, MUST be present in all RPKI certificates, and if present, MUST 543 be marked critical. 545 This extension contains the list of AS number resources as per 546 [RFC3779], or may specify the "inherit" element. RDI values are NOT 547 supported in this profile and MUST NOT be used. 549 This extension MUST either specify a non-empty set AS number records, 550 or use the "inherit" setting to indicate that the AS number resource 551 set of this certificate is inherited from that of the certificate's 552 issuer. 554 5. Resource Certificate Revocation Lists 556 Each CA MUST issue a version 2 Certificate Revocation List (CRL), 557 consistent with [RFC5280]. RPs are NOT required to process version 1 558 CRLs (in contrast to [RFC5280]). The CRL Issuer is the CA. CRLs 559 conforming to this profile MUST NOT include Indirect or Delta CRLs. 560 The scope of each CRL MUST be all certificates issued by this CA. 562 The Issuer name is as in Section 4.4 above. 564 Where two or more CRLs issued by the same CA, the CRL with the 565 highest value of the "CRL Number" field supersedes all other CRLs 566 issued by this CA. 568 The algorithm used in CRLs issued under this profile is specified in 569 [ID.sidr-rpki-algs]. 571 The contents of the CRL are a list of all non-expired certificates 572 that have been revoked by the CA. 574 An RPKI CA MUST include the two extensions Authority Key Identifier 575 and CRL Number in every CRL that it issues. RPs MUST be prepared to 576 process CRLs with these extensions. No other CRL extensions are 577 allowed. 579 For each revoked resource certificate only the two fields Serial 580 Number and Revocation Date MUST be present, and all other fields MUST 581 NOT be present. No CRL entry extensions are supported in this 582 profile, and CRL entry extensions MUST NOT be present in a CRL. 584 6. Resource Certificate Requests 586 A resource certificate request MAY use either of PKCS#10 or 587 Certificate Request Message Format (CRMF). A CA MUST support 588 certificate issuance in PKCS#10 and a CA MAY support CRMF requests. 590 Note that there is no certificate response defined in this profile. 591 For CA certificate and multi-use EE certificate requests, the CA 592 places the Resource Certificate in the repository, as per 593 [ID.sidr-cp]. No response is defined for single-use EE Certificate 594 requests. 596 6.1. PCKS#10 Profile 598 This profile refines the specification in [RFC2986], as it relates to 599 Resource Certificates. A Certificate Request Message object, 600 formatted according to PKCS#10, is passed to a CA as the initial step 601 in issuing a certificate. 603 With the exception of the SubjectPublicKeyinfo and the SIA extension 604 request, the CA is permitted to alter any field in the request when 605 issuing a certificate. 607 6.1.1. PKCS#10 Resource Certificate Request Template Fields 609 This profile applies the following additional requirements to fields 610 that MAY appear in a CertificationRequestInfo: 612 Version 613 This field is mandatory and MUST have the value 0. 615 Subject 616 This field MAY be omitted. If present, the value of this field 617 SHOULD be empty (i.e., NULL), in which case the CA MUST 618 generate a Subject name that is unique in the context of 619 certificates issued by this CA. This field is allowed to be 620 non-empty only for a rekey/reissuance request, and only if the 621 CA has adopted a policy (in its Certificate Practice Statement 622 (CPS)) that permits name reuse in these circumstances. 624 SubjectPublicKeyInfo 625 This field specifies the Subject's public key and the algorithm 626 with which the key is used. The algorithm used in this profile 627 is specified in [ID.sidr-rpki-algs]. 629 Attributes 630 [RFC2986] defines the attributes field as key-value pairs where 631 the key is an OID and the value's structure depends on the key. 633 The only attribute used in this profile is the ExtensionRequest 634 attribute as defined in [RFC2985]. This attribute contains 635 certificate Extensions. The profile for extensions in 636 certificate requests is specified in Section 6.3. 638 This profile applies the following additional constraints to fields 639 that MAY appear in a CertificationRequest Object: 641 signatureAlgorithm 642 The signatureAlgorithm value is specified in 643 [ID.sidr-rpki-algs]. 645 6.2. CRMF Profile 647 This profile refines the Certificate Request Message Format (CRMF) 648 specification in [RFC4211], as it relates to Resource Certificates. 649 A Certificate Request Message object, formatted according to the 650 CRMF, is passed to a CA as the initial step in certificate issuance. 652 With the exception of the SubjectPublicKeyinfo and the SIA extension 653 request, the CA is permitted to alter any requested field when 654 issuing the certificate. 656 6.2.1. CRMF Resource Certificate Request Template Fields 658 This profile applies the following additional requirements to fields 659 that may appear in a Certificate Request Template: 661 version 662 This field SHOULD be omitted. If present, it MUST specify a 663 request for a Version 3 Certificate. It 665 serialNumber 666 This field MUST be omitted. 668 signingAlgorithm 669 This field MUST be omitted. 671 issuer 672 This MUST be omitted in this profile. 674 Validity 675 This field MAY be omitted. If omitted, the CA will issue a 676 Certificate with Validity dates as determined by the CA. If 677 specified, then the CA MAY override the requested values with 678 dates as determined by the CA. 680 Subject 681 This field MAY be omitted. If present, the value of this field 682 SHOULD be empty (i.e., NULL), in which case the CA MUST 683 generate a Subject name that is unique in the context of 684 certificates issued by this CA. This field is allowed to be 685 non-empty only for a rekey/reissuance request, and only if the 686 CA has adopted a policy (in its CPS) that permits name reuse in 687 these circumstances. 689 PublicKey 690 This field MUST be present. 692 extensions 693 The profile for extensions in certificate requests is specified 694 in Section 6.3. 696 6.2.2. Resource Certificate Request Control Fields 698 The following control fields are supported in this profile: 700 Authenticator Control 701 'The intended model of authentication of the Subject is a "long 702 term" model, and the guidance offered in [RFC4211] is that the 703 Authenticator Control field be used. 705 6.3. Certificate Extension Attributes in Certificate Requests 707 The following extensions MAY appear in a PKCS#10 or CRMF Certificate 708 Request. Any other extensions MUST NOT appear in a Certificate 709 Request. This profile places the following additional constraints on 710 these extensions: 712 BasicConstraints 713 If this is omitted then the CA will issue an EE certificate 714 (hence no BasicConstraints extension will be included). 716 The pathLengthConstraint is not supported in this profile, and 717 this field MUST be omitted. 719 The CA MAY honour the cA boolean if set to true (CA certificate 720 request). If this bit is set, then it indicates that the 721 Subject is requesting a CA certificate. 723 The CA MUST honour the cA bit if set to false (EE certificate 724 request), in which case the corresponding EE certificate will 725 not contain a Basic Constraints extension. 727 KeyUsage 728 The CA MAY honour KeyUsage extensions of keyCertSign and 729 cRLSign if present, as long as this is consistent with the 730 BasicConstraints SubjectType sub field, when specified. 732 ExtendedKeyUsage 733 The CA MAY honour ExtendedKeyUsage extensions of keyCertSign 734 and cRLSign if present, as long as this is consistent with the 735 BasicConstraints SubjectType sub field, when specified. 737 SubjectInformationAccess 738 This field MUST be present, and the field value SHOULD be 739 honoured by the CA if it conforms to the requirements set forth 740 in Section 4.9.8. If the CA is unable to honour the requested 741 value for this field, then the CA MUST reject the Certificate 742 Request. 744 7. Resource Certificate Validation 746 This section describes the Resource Certificate validation procedure. 747 This refines the generic procedure described in section 6 of 748 [RFC5280]. 750 7.1. Resource Extension Validation 752 The IP Resources and AS Resources extensions definitions [RFC3779] 753 define critical extensions for INRs. These are ASN.1 encoded 754 representations of the IPv4 and IPv6 address range and an AS number 755 set. 757 Valid Resource Certificates MUST have a valid IP address and/or AS 758 number resource extension. In order to validate a Resource 759 Certificate the resource extension MUST also be validated. This 760 validation process relies on definitions of comparison of resource 761 sets: 763 more specific 764 Given two IP address or AS number contiguous ranges, A and B, A 765 is "more specific" than B if range B includes all IP addresses 766 or AS numbers described by range A, and if range B is larger 767 than range A. 769 equal 770 Given two IP address or AS number contiguous ranges, A and B, A 771 is "equal" to B if range A describes precisely the same 772 collection of IP addresses or AS numbers as described by range 773 B. The definition of "inheritance" in [RFC3779] is equivalent 774 to this "equality" comparison. 776 encompass 777 Given two IP address and AS number sets X and Y, X 778 "encompasses" Y if, for every contiguous range of IP addresses 779 or AS numbers elements in set Y, the range element is either 780 "more specific" than or "equal" to a contiguous range element 781 within the set X. 783 Validation of a certificate's resource extension in the context of a 784 Certification Path (see Section 7.2 entails that for every adjacent 785 pair of certificates in the certification path (certificates 'x' and 786 'x + 1'), the number resources described in certificate 'x' 787 "encompass" the number resources described in certificate 'x + 1', 788 and the resources described in the trust anchor information 789 "encompass" the resources described in the first certificate in the 790 certification path. 792 7.2. Resource Certification Path Validation 794 Validation of signed resource data using a target resource 795 certificate consists of verifying that the digital signature of the 796 signed resource data is valid, using the public key of the target 797 resource certificate, and also validating the resource certificate in 798 the context of the RPKI, using the path validation process. This 799 path validation process verifies, among other things, that a 800 prospective certification path (a sequence of n certificates) 801 satisfies the following conditions: 803 1. for all 'x' in {1, ..., n-1}, the Subject of certificate 'x' 804 is the Issuer of certificate ('x' + 1); 806 2. certificate '1' is issued by a trust anchor; 808 3. certificate 'n' is the certificate to be validated; and 810 4. for all 'x' in {1, ..., n}, certificate 'x' is valid. 812 Certificate validation entails verifying that all of the following 813 conditions hold, in addition to the Certification Path Validation 814 criteria specified in Section 6 of [RFC5280]: 816 1. The certificate can be verified using the Issuer's public key 817 and the signature algorithm 819 2. The current time lies within the certificate's Validity From 820 and To values. 822 3. The certificate contains all fields that MUST be present, as 823 defined by this specification, and contains values for 824 selected fields that are defined as allowable values by this 825 specification. 827 4. No field, or field value, that this specification defines as 828 MUST NOT be present is used in the certificate. 830 5. The Issuer has not revoked the certificate. A revoked 831 certificate is identified by the certificate's serial number 832 being listed on the Issuer's current CRL, as identified by the 833 CRLDP of the certificate, the CRL is itself valid, and the 834 public key used to verify the signature on the CRL is the same 835 public key used to verify the certificate itself. 837 6. That the resource extension data is "encompassed" by the 838 resource extension data contained in a valid certificate where 839 this Issuer is the Subject (the previous certificate in the 840 context of the ordered sequence defined by the Certification 841 Path). 843 7. The Certification Path originates with a certificate issued by 844 a trust anchor, and there exists a signing chain across the 845 Certification Path where the Subject of Certificate 'x' in the 846 Certification Path matches the Issuer in Certificate 'x + 1' 847 in the Certification Path, and the public key in Certificate 848 'x' can verify the signature value in Certificate 'x+1'. 850 A certificate validation algorithm MAY perform these tests in any 851 chosen order. 853 Certificates and CRLs used in this process MAY be found in a locally 854 maintained cache, maintained by a regular synchronisation across the 855 distributed publication repository structure [ID.sidr-repos-struct]. 857 There exists the possibility of encountering certificate paths that 858 are arbitrarily long, or attempting to generate paths with loops as 859 means of creating a potential DOS attack on a RP. A RP executing 860 this procedure MAY apply further heuristics to guide halting the 861 certification path validation process in order to avoid some of the 862 issues associated with attempts to validate such malformed 863 certification path structures. Implementations of Resource 864 Certificate validation MAY halt with a validation failure if the 865 certification path length exceeds a locally defined configuration 866 parameter. 868 8. Design Notes 870 The following notes provide some additional commentary on the 871 considerations that lie behind some of the design choices that were 872 made in the design of this certificate profile. These notes are non- 873 normative, i.e. this section of the document does not constitute a 874 formal part of the profile specification, and the interpretation of 875 key words as defined in RFC2119 are not applicable in this section of 876 the document. 878 Certificate Extensions: 879 This profile does not permit the use of any other critical or 880 non-critical extensions. The rationale for this restriction is 881 that the resource certificate profile is intended for a 882 specific define use. In this context it is not seen as being 883 appropriate to be in the position of having certificates with 884 additional non-critical extensions that RPs may see as valid 885 certificates without understanding the extensions, but were the 886 RP in a position to understand the extensions, would contradict 887 or qualify in some way this original judgment of validity. 888 This profile takes the position of minimalism over 889 extensibility. The specific goal for the associated RPKI is to 890 precisely match the INR allocation structure through an aligned 891 certificate structure that describes the allocation and its 892 context within the INR distribution hierarchy. The profile 893 defines a resource certificate that is structured to meet these 894 requirements. 896 Certification Authorities and Key Values: 897 This profile uses a definition of an instance of a CA as a 898 combination of a named entity and a key pair. Within this 899 definition a CA instance cannot rollover a key pair. However, 900 the entity can generate a new instance of a CA with a new key 901 pair and roll over all the signed subordinate products to the 902 new CA [ID.sidr-keyroll]. 904 This has a number of implications in terms of Subject name 905 management, CRL Scope and repository publication point 906 management. 908 CRL Scope and Key Values: 909 For CRL Scope this profile specifies that a CA issues a single 910 CRL at a time, and the scope of the CRL is all certificates 911 issued by this CA. Because the CA instance is bound to a 912 single key pair this implies that the CA's public key, the key 913 used to validate the CA's CRL, and the key used to validate the 914 certificates revoked by that CRL are all the same key value. 916 Repository Publication Point: 917 The definition of a CA affects the design of the repository 918 publication system. In order to minimize the amount of forced 919 re-certification on key rollover events, a repository 920 publication regime that uses the same repository publication 921 point for all CA instances that refers to the same entity, but 922 with different key values will minimize the extent of re- 923 generation of certificates to only immediate subordinate 924 certificates. This is described in [ID.sidr-keyroll]. 926 Subject Name: 927 This profile specifies that Subject names must be unique per 928 Issuer, and does not specify that Subject names must be 929 globally unique (in terms of assured uniqueness). This is due 930 to the nature of the RPKI as a distributed PKI, implying that 931 there is no ready ability for Certification authorities to 932 coordinate a simple RPKI-wide unique name space without 933 resorting to additional critical external dependencies. CAs 934 are advised to use Subject name generation procedures that 935 minimize the potential for name clashes. 937 One way to achieve this is for a CA to use a Subject name 938 practice that uses the CommonName component of the 939 Distinguished Name as a constant value for any given entity 940 that is the Subject of CA-issued certificates, and set the 941 serialNumber component of the Distinguished Name to a value 942 that is derived from the hash of the subject public key value. 944 If the CA elects not to use the serialNumber component of the 945 DistinguishedName, then it is considered beneficial that a CA 946 generates CommonNames that have themselves a random component 947 that includes significantly more than 40 bits of entropy in the 948 name. Some non-normative recommendations to achieve this 949 include: 951 1) Hash of the subject public key (encoded as ASCII HEX). 952 example: cn="999d99d564de366a29cd8468c45ede1848e2cc14" 954 2) A Universally Unique IDentifier (UUID) [RFC4122] 955 example: cn="6437d442-6fb5-49ba-bbdb-19c260652098" 957 3) A randomly generated ASCII HEX encoded string of length 958 20 or greater: 959 example: cn="0f8fcc28e3be4869bc5f8fa114db05e1"> 960 (A string of 20 ASCII HEX digits would have 80-bits of 961 entropy) 963 4) An internal database key or subscriber ID combined with 964 one of the above 965 example: cn=" (6437d442-6fb5-49ba-bbdb- 966 19c2606520980)" 967 (The issuing CA may wish to be able to extract the 968 database key or subscriber ID from the commonName. Since 969 only the issuing CA would need to be able to parse the 970 commonName, the database key and the source of entropy 971 (e.g., a UUID) could be separated in any way that the CA 972 wanted, as long as it conformed to the rules for 973 PrintableString. The separator could be a space 974 character, parenthesis, hyphen, slash, question mark, 975 etc. 977 9. Security Considerations 979 The Security Considerations of [RFC5280] and [RFC3779] apply to 980 Resource Certificates. The Security Considerations of [RFC2986] and 981 [RFC4211] apply to Resource Certificate certification requests. 983 A Resource Certificate PKI cannot in and of itself resolve any forms 984 of ambiguity relating to uniqueness of assertions of rights of use in 985 the event that two or more valid certificates encompass the same 986 resource. If the issuance of resource certificates is aligned to the 987 status of resource allocations and assignments then the information 988 conveyed in a certificate is no better than the information in the 989 allocation and assignment databases. 991 This profile requires that the key used to sign an issued certificate 992 is the same key used to sign the CRL that can revoke the certificate, 993 implying that the certificate path used to validate a signature on a 994 certificates is the same as that used to validate a signatures the 995 CRL that revokes the certificate. It is noted that this is a higher 996 constraint than required in X.509 PKIs, and there may be a risk in 997 using a path validation implementation that is capable of using 998 separate validation paths for a certificate and the corresponding 999 CRL. If there are subject name collisions in the RPKI as a result of 1000 CAs not following the guidelines provided here relating to ensuring 1001 sufficient entropy in constructing subject names, and this is 1002 combined with the situation that an RP uses an implementation of 1003 validation path construction that is not in conformance with this 1004 RPKI profile, then it is possible that the subject name collisions 1005 can cause an RP to conclude that an otherwise valid certificate has 1006 been revoked. 1008 10. IANA Considerations 1010 [Note to IANA, to be removed prior to publication: there are no IANA 1011 considerations stated in this document.] 1013 11. Acknowledgements 1015 The authors would like to particularly acknowledge the valued 1016 contribution from Stephen Kent in reviewing this document and 1017 proposing numerous sections of text that have been incorporated into 1018 the text. The authors also acknowledge the contributions of Sandy 1019 Murphy, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo Patara 1020 and Rob Austein in the preparation and subsequent review of this 1021 document. The document also reflects review comments received from 1022 Roque Gagliano, Sean Turner and David Cooper. 1024 12. References 1026 12.1. Normative References 1028 [ID.sidr-cp] 1029 Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 1030 Policy (CP) for the Resource PKI (RPKI)", Work in 1031 progress: Internet Drafts draft-ietf-sidr-c-13.txt, 1032 September 2010. 1034 [ID.sidr-rpki-algs] 1035 Huston, G., "A Profile for Algorithms and Key Sizes for 1036 use in the Resource Public Key Infrastructure", Work in 1037 progress: Internet 1038 Drafts draft-ietf-sidr-rpki-algs-00.txt, August 2009. 1040 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1041 Request Syntax Specification Version 1.7", RFC 2986, 1042 November 2000. 1044 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1045 Addresses and AS Identifiers", RFC 3779, June 2004. 1047 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1048 Certificate Request Message Format (CRMF)", RFC 4211, 1049 September 2005. 1051 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1052 Housley, R., and W. Polk, "Internet X.509 Public Key 1053 Infrastructure Certificate and Certificate Revocation List 1054 (CRL) Profile", RFC 5280, May 2008. 1056 [X.509] ITU-T, "Recommendation X.509: The Directory - 1057 Authentication Framework", 2000. 1059 12.2. Informative References 1061 [ID.sidr-arch] 1062 Lepinski, M. and S. Kent, "An Infrastructure to Support 1063 Secure Internet Routing", Work in progress: Internet 1064 Drafts draft-ietf-sidr-arch-04.txt, November 2008. 1066 [ID.sidr-keyroll] 1067 Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover 1068 in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in 1069 progress), October 2010. 1071 [ID.sidr-repos-struct] 1072 Huston, G., Loomans, R., and G. Michaleson, "A Profile for 1073 Resource Certificate Repository Structure", 1074 draft-ietf-sidr-repos-struct-04.txt (work in progress), 1075 May 2010. 1077 [ID.sidr-rpki-manifests] 1078 Austein, R., Huston, G., Kent, S., and M. Lepinski, 1079 "Manifests for the Resource Public Key Infrastructure", 1080 Work in progress: Internet 1081 Drafts draft-ietf-sidr-rpki-manifests-04.txt, 1082 October 2008. 1084 [ID.sidr-signed-object] 1085 Lepinski, M., Chi, A., and S. Kent, "Signed Object 1086 Template for the Resource Public Key Infrastructure", 1087 draft-ietf-sidr-signed-object-01.txt (work in progress), 1088 October 2010. 1090 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1091 Classes and Attribute Types Version 2.0", RFC 2985, 1092 November 2000. 1094 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1095 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1096 July 2005. 1098 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 1099 Scheme", RFC 5781, February 2010. 1101 Appendix A. Example Resource Certificate 1103 The following is an example Resource Certificate. 1105 Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer 1107 Data: 1108 Version: 3 (0x2) 1109 Serial: 1500 (0x5dc) 1110 Signature Algorithm: SHA256WithRSAEncryption 1111 Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s 1112 Validity 1113 Not Before: Oct 25 12:50:00 2008 GMT 1114 Not After : Jan 31 00:00:00 2010 GMT 1115 Subject: CN=A91872ED 1116 Subject Public Key Info: 1117 Public Key Algorithm: rsaEncryption 1118 RSA Public Key: (2048 bit) 1119 Modulus (2048 bit): 1120 00:bb:fb:4a:af:a4:b9:dc:d0:fa:6f:67:cc:27:39: 1121 34:d1:80:40:37:de:88:d1:64:a2:f1:b3:fa:c6:7f: 1122 bb:51:df:e1:c7:13:92:c3:c8:a2:aa:8c:d1:11:b3: 1123 aa:99:c0:ac:54:d3:65:83:c6:13:bf:0d:9f:33:2d: 1124 39:9f:ab:5f:cd:a3:e9:a1:fb:80:7d:1d:d0:2b:48: 1125 a5:55:e6:24:1f:06:41:35:1d:00:da:1f:99:85:13: 1126 26:39:24:c5:9a:81:15:98:fb:5f:f9:84:38:e5:d6: 1127 70:ce:5a:02:ca:dd:61:85:b3:43:2d:0b:35:d5:91: 1128 98:9d:da:1e:0f:c2:f6:97:b7:97:3e:e6:fc:c1:c4: 1129 3f:30:c4:81:03:25:99:09:4c:e2:4a:85:e7:46:4b: 1130 60:63:02:43:46:51:4d:ed:fd:a1:06:84:f1:4e:98: 1132 32:da:27:ee:80:82:d4:6b:cf:31:ea:21:af:6f:bd: 1133 70:34:e9:3f:d7:e4:24:cd:b8:e0:0f:8e:80:eb:11: 1134 1f:bc:c5:7e:05:8e:5c:7b:96:26:f8:2c:17:30:7d: 1135 08:9e:a4:72:66:f5:ca:23:2b:f2:ce:54:ec:4d:d9: 1136 d9:81:72:80:19:95:57:da:91:00:d9:b1:e8:8c:33: 1137 4a:9d:3c:4a:94:bf:74:4c:30:72:9b:1e:f5:8b:00: 1138 4d:e3 1139 Exponent: 65537 (0x10001) 1140 X509v3 extensions: 1141 X509v3 Subject Key Identifier: 1142 F4:97:E0:00:47:2A:ED:0F:B8:EC:8C:0C:0B:90:89: 1143 20:9A:FA:10:9B 1145 X509v3 Authority Key Identifier: 1146 keyid:09:53:D0:4A:05:24:2F:2E:E9:39:77:4D:79: 1147 55:86:BE:71:57:FF:4B 1149 X509v3 Key Usage: critical 1150 Certificate Sign, CRL Sign 1152 X509v3 Basic Constraints: critical 1153 CA:TRUE 1155 X509v3 CRL Distribution Points: 1156 URI:rsync://rpki.apnic.net/repository/A3C38A24 1157 D60311DCAB08F31979BDBE39/CVPQSgUkLy7pOXdNe 1158 VWGvnFX_0s.crl 1160 Authority Information Access: 1161 CA Issuers - URI:rsync://rpki.apnic.net/repos 1162 itory/8BDFC7DED5FD11DCB14CF4B1A703F9B7/CVP 1163 QSgUkLy7pOXdNeVWGvnFX_0s.cer 1165 X509v3 Certificate Policies: critical 1166 Policy: 1.3.6.1.5.5.7.14.2 1168 Subject Information Access: 1169 CA Repository - URI:rsync://rpki.apnic.net/mem 1170 ber_repository/A91872ED/06A83982887911DD81 1171 3F432B2086D636/ 1172 Manifest - URI:rsync://rpki.apnic.net/member_r 1173 epository/A91872ED/06A83982887911DD813F432 1174 B2086D636/9JfgAEcq7Q-47IwMC5CJIJr6EJs.mft 1176 sbgp-autonomousSysNum: critical 1177 Autonomous System Numbers: 1178 24021 1179 38610 1180 131072 1181 131074 1183 sbgp-ipAddrBlock: critical 1184 IPv4: 1185 203.133.248.0/22 1186 203.147.108.0/23 1188 Signature Algorithm: sha256WithRSAEncryption 1189 51:4c:77:e4:21:64:80:e9:35:30:20:9f:d8:4b:88:60:b8:1f: 1190 73:24:9d:b5:17:60:65:6a:28:cc:43:4b:68:97:ca:76:07:eb: 1191 dc:bd:a2:08:3c:8c:56:38:c6:0a:1e:a8:af:f5:b9:42:02:6b: 1192 77:e0:b1:1c:4a:88:e6:6f:b6:17:d3:59:41:d7:a0:62:86:59: 1193 29:79:26:76:34:d1:16:2d:75:05:cb:b2:99:bf:ca:c6:68:1b: 1194 b6:a9:b0:f4:43:2e:df:e3:7f:3c:b3:72:1a:99:fa:5d:94:a1: 1195 eb:57:9c:9a:2c:87:d6:40:32:c9:ff:a6:54:b8:91:87:fd:90: 1196 55:ef:12:3e:1e:2e:cf:c5:ea:c3:4c:09:62:4f:88:00:a0:7f: 1197 cd:67:83:bc:27:e1:74:2c:18:4e:3f:12:1d:ef:29:0f:e3:27: 1198 00:ce:14:eb:f0:01:f0:36:25:a2:33:a8:c6:2f:31:18:22:30: 1199 cf:ca:97:43:ed:84:75:53:ab:b7:6c:75:f7:2f:55:5c:2e:82: 1200 0a:be:91:59:bf:c9:06:ef:bb:b4:a2:71:9e:03:b1:25:8e:29: 1201 7a:30:88:66:b4:f2:16:6e:df:ad:78:ff:d3:b2:9c:29:48:e3: 1202 be:87:5c:fc:20:2b:df:da:ca:30:58:c3:04:c9:63:72:48:8c: 1203 0a:5f:97:71 1205 Appendix B. Example Certificate Revocation List 1207 The following is an example Certificate Revocation List. 1209 CRL Name: q66IrWSGuBE7jqx8PAUHAlHCqRw.crl 1210 Data: 1211 Version: 2 1212 Signature Algorithm: 1213 Hash: SHA256, Encryption: RSA 1214 Issuer: CN=Demo Production APNIC CA - Not for real use, 1215 E=ca@apnic.net 1216 This Update: Thu Jul 27 06:30:34 2006 GMT 1217 Next Update: Fri Jul 28 06:30:34 2006 GMT 1218 Authority Key Identifier: Key Identifier: 1219 ab:ae:88:ad:64:86:b8:11:3b:8e:ac:7c:3c:05: 1220 07:02:51:c2:a9:1c 1221 Authority Key Identifier: Key Identifier g(AKI): 1222 q66IrWSGuBE7jqx8PAUHAlHCqRw 1223 CRLNumber: 4 1224 Revoked Certificates: 1 1225 Serial Number: 1 1226 Revocation Date: Mon Jul 17 05:10:19 2006 GMT 1227 Serial Number: 2 1228 Revocation Date: Mon Jul 17 05:12:25 2006 GMT 1229 Serial Number: 4 1230 Revocation Date: Mon Jul 17 05:40:39 2006 GMT 1231 Signature: 1232 b2:5a:e8:7c:bd:a8:00:0f:03:1a:17:fd:40:2c:46: 1233 0e:d5:64:87:e7:e7:bc:10:7d:b6:3e:39:21:a9:12: 1234 f4:5a:d8:b8:d4:bd:57:1a:7d:2f:7c:0d:c6:4f:27: 1235 17:c8:0e:ae:8c:89:ff:00:f7:81:97:c3:a1:6a:0a: 1236 f7:d2:46:06:9a:d1:d5:4d:78:e1:b7:b0:58:4d:09: 1237 d6:7c:1e:a0:40:af:86:5d:8c:c9:48:f6:e6:20:2e: 1238 b9:b6:81:03:0b:51:ac:23:db:9f:c1:8e:d6:94:54: 1239 66:a5:68:52:ee:dd:0f:10:5d:21:b8:b8:19:ff:29: 1240 6f:51:2e:c8:74:5c:2a:d2:c5:fa:99:eb:c5:c2:a2: 1241 d0:96:fc:54:b3:ba:80:4b:92:7f:85:54:76:c9:12: 1242 cb:32:ea:1d:12:7b:f8:f9:a2:5c:a1:b1:06:8e:d8: 1243 c5:42:61:00:8c:f6:33:11:29:df:6e:b2:cc:c3:7c: 1244 d3:f3:0c:8d:5c:49:a5:fb:49:fd:e7:c4:73:68:0a: 1245 09:0e:6d:68:a9:06:52:3a:36:4f:19:47:83:59:da: 1246 02:5b:2a:d0:8a:7a:33:0a:d5:ce:be:b5:a2:7d:8d: 1247 59:a1:9d:ee:60:ce:77:3d:e1:86:9a:84:93:90:9f: 1248 34:a7:02:40:59:3a:a5:d1:18:fb:6f:fc:af:d4:02: 1249 d9 1251 Authors' Addresses 1253 Geoff Huston 1254 APNIC 1256 Email: gih@apnic.net 1257 URI: http://www.apnic.net 1259 George Michaelson 1260 APNIC 1262 Email: ggm@apnic.net 1263 URI: http://www.apnic.net 1265 Robert Loomans 1266 APNIC 1268 Email: robertl@apnic.net 1269 URI: http://www.apnic.net