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