idnits 2.17.1 draft-ietf-sidr-res-certs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1261. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 157: '...Certificate that MUST be present for t...' RFC 2119 keyword, line 159: '... Relying Parties SHOULD check that a R...' RFC 2119 keyword, line 186: '...esource extension SHOULD be a CRITICAL...' RFC 2119 keyword, line 189: '... extension MUST be used and MUST...' RFC 2119 keyword, line 194: '... MUST use this sorted canonical ...' (116 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 28, 2006) is 6480 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) ** Obsolete normative reference: RFC 2050 (Obsoleted by RFC 7020) ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Downref: Normative reference to an Informational RFC: RFC 4158 Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 7 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: January 29, 2007 APNIC 6 July 28, 2006 8 A Profile for X.509 PKIX Resource Certificates 9 draft-ietf-sidr-res-certs-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 29, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document defines a standard profile for X.509 certificates for 43 the purposes of supporting validation of assertions of "right-to-use" 44 of an Internet Number Resource (IP Addresses and Autonomous System 45 Numbers). This profile is used to convey the issuer's authorization 46 of the subject to be regarded as the current holder of a "right-of- 47 use" of the IP addresses and AS numbers that are described in the 48 associated Resource Certificate. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 54 2. Describing Resources in Certificates . . . . . . . . . . . . . 5 55 3. Resource Certificate Fields . . . . . . . . . . . . . . . . . 6 56 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2. Serial number . . . . . . . . . . . . . . . . . . . . . . 6 58 3.3. Signature Algorithm . . . . . . . . . . . . . . . . . . . 6 59 3.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.5. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.6. Valid From . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.7. Valid To . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.8. Subject Public Key Info . . . . . . . . . . . . . . . . . 8 64 3.9. Resource Certificate Version 3 Extension Fields . . . . . 8 65 3.9.1. Basic Constraints . . . . . . . . . . . . . . . . . . 8 66 3.9.2. Subject Key Identifier . . . . . . . . . . . . . . . . 9 67 3.9.3. Authority Key Identifier . . . . . . . . . . . . . . . 9 68 3.9.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 9 69 3.9.5. CRL Distribution Points . . . . . . . . . . . . . . . 10 70 3.9.6. Authority Information Access . . . . . . . . . . . . . 10 71 3.9.7. Subject Information Access . . . . . . . . . . . . . . 11 72 3.9.8. Certificate Policies . . . . . . . . . . . . . . . . . 11 73 3.9.9. Subject Alternate Name . . . . . . . . . . . . . . . . 11 74 3.9.10. IP Resources . . . . . . . . . . . . . . . . . . . . . 11 75 3.9.11. AS Resources . . . . . . . . . . . . . . . . . . . . . 12 76 4. Resource Certificate Revocation List Profile . . . . . . . . . 12 77 4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 4.2. Issuer Name . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.3. This Update . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.4. Next Update . . . . . . . . . . . . . . . . . . . . . . . 13 81 4.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 13 82 4.6. Revoked Certificate List . . . . . . . . . . . . . . . . . 13 83 4.6.1. Serial Number . . . . . . . . . . . . . . . . . . . . 13 84 4.6.2. Revocation Date . . . . . . . . . . . . . . . . . . . 13 85 4.7. CRL Extensions . . . . . . . . . . . . . . . . . . . . . . 13 86 4.7.1. Authority Key Identifier . . . . . . . . . . . . . . . 14 87 4.7.2. CRL Number . . . . . . . . . . . . . . . . . . . . . . 14 88 5. Resource Certificate Request Profile . . . . . . . . . . . . . 14 89 5.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 14 90 5.1.1. PKCS#10 Resource Certificate Request Template 91 Fields . . . . . . . . . . . . . . . . . . . . . . . . 14 92 5.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 15 93 5.2.1. CRMF Resource Certificate Request Template Fields . . 16 94 5.2.2. Resource Certificate Request Control Fields . . . . . 16 95 5.3. Certificate Extension Attributes in Certificate 96 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 6. Resource Certificate Validation . . . . . . . . . . . . . . . 19 98 6.1. Trust Anchors for Resource Certificates . . . . . . . . . 20 99 6.2. Resource Extension Validation . . . . . . . . . . . . . . 20 100 6.3. Resource Certificate Path Validation . . . . . . . . . . . 21 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 103 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 104 10. Normative References . . . . . . . . . . . . . . . . . . . . . 23 105 Appendix A. Example Resource Certificate . . . . . . . . . . . . 24 106 Appendix B. Example Certificate Revocation List . . . . . . . . . 26 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 108 Intellectual Property and Copyright Statements . . . . . . . . . . 29 110 1. Introduction 112 This document defines a standard profile for X.509 certificates for 113 use in the context of certification of IP Addresses and AS Numbers. 114 These Resource Certificates are X.509 certificates that conform to 115 the PKIX profile [RFC3280] and also conform to the constraints 116 specified in this profile. Resource Certificates attest that the 117 issuer has granted the subject a "right-to-use" a listed set of IP 118 addresses and Autonomous System numbers. 120 A Resource Certificate describes an action by the certificate issuer 121 that binds a list of IP Address blocks and AS Numbers to the subject 122 of the certificate. The binding is identified by the association of 123 the subject's private key with the subject's public key contained in 124 the Resource Certificate, signed by the private key of the 125 certificate's issuer. 127 In the context of the public Internet, and use of public number 128 resources in this context, it is intended that Resource Certificates 129 are used in a manner that is aligned to the public number resource 130 distribution function. Specifically, when a number resource is 131 allocated or assigned by a number registry to an entity, this 132 allocation can be described by a Resource Certificate that is issued 133 by the registry with a subject corresponding to the entity that is 134 the recipient of this number assignment or allocation. In the 135 context of the public number distribution function, this corresponds 136 to a hierarchical PKI structure, where Resource Certificates are only 137 issued in one 'direction' and there is a single unique path from a 138 "Root" Certificate Authority to a valid certificate. 140 Validation of a Resource Certificate in such a hierarchical PKI can 141 be undertaken by establishing a valid issuer - subject chain from a 142 trust anchor certificate authority to the certificate [RFC4158], with 143 the additional constraint of ensuring that each subject's listed 144 resources are fully encompassed by those of the issuer at each step 145 in the issuer-subject chain. 147 Resource Certificates may be used in the context of the operation of 148 secure inter-domain routing protocols to convey a right-to-use of an 149 IP number resource that is being passed within the routing protocol, 150 to verify legitimacy and correctness of routing information. Related 151 use contexts include validation of access to Internet Routing 152 Registries for nominated routing objects, validation of routing 153 requests, and detection of potential unauthorized used of IP 154 addresses. 156 This profile defines those fields that are used in a Resource 157 Certificate that MUST be present for the certificate to be valid. 159 Relying Parties SHOULD check that a Resource Certificate conforms to 160 this profile as a requisite for validation of a Resource Certificate. 162 1.1. Terminology 164 It is assumed that the reader is familiar with the terms and concepts 165 described in "Internet X.509 Public Key Infrastructure Certificate 166 and Certificate Revocation List (CRL) Profile" [RFC3280], "X.509 167 Extensions for IP Addresses and AS Identifiers" [RFC3779], "Internet 168 Protocol" [RFC0791], "Internet Protocol Version 6 (IPv6) Addressing 169 Architecture" [RFC4291], "Internet Registry IP Allocation Guidelines" 170 [RFC2050], and related regional Internet registry address management 171 policy documents. 173 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119. 177 2. Describing Resources in Certificates 179 The framework for describing an association between the subject of a 180 certificate and the resources currently under the subject's current 181 control is described in [RFC3779]. 183 There are three aspects of this resource extension that are noted in 184 this profile: 186 1. RFC 3779 notes that this resource extension SHOULD be a CRITICAL 187 extension to the X.509 Certificate. This Resource Certificate 188 profile further specifies that the use of this certificate 189 extension MUST be used and MUST be marked as CRITICAL. 191 2. RFC 3779 defines a sorted canonical form of describing a resource 192 set, with maximal spanning ranges and maximal spanning prefix 193 masks as appropriate. All valid certificates in this profile 194 MUST use this sorted canonical form of resource description 196 3. A test of the resource extension in the context of certificate 197 validity includes the first condition that the resources 198 described in the issuer's resource extension must encompass those 199 of the subject's resource extension. In this context "encompass" 200 allows for the issuer's resource set to be the same as, or a 201 strict superset of, any subject's resource set. Appropriate 202 Resource Certificate management in the context of this profile 203 also includes the constraint that no two (or more) certificates 204 issued by a single issuer to two (or more) different subjects 205 have a non-null intersection of resources. In other words an 206 issuer can certify at most one unique entity as the unique holder 207 of a right-to-use for any particular resource. 209 A test of certificate validity entails the identification of a 210 sequence of valid certificates in an issuer-subject chain (where the 211 subject field of one certificate appears as the issuer in the next 212 certificate in the sequence) from one, and only one, trust anchor to 213 the certificate being validated, and that the resource extensions in 214 this certificate sequence from the trust anchor to the certificate 215 form a sequence of encompassing relationships. 217 3. Resource Certificate Fields 219 A Resource Certificate is a valid X.509 v3 public key certificate, 220 consistent with the PKIX profile [RFC3280], containing the fields 221 listed in this section. Unless specifically noted as being OPTIONAL, 222 all the fields listed here MUST be present, and any other field MUST 223 NOT appear in a conforming Resource Certificate. Where a field value 224 is specified here this value MUST be used in conforming Resource 225 Certificates. 227 3.1. Version 229 Resource Certificates are X.509 Version 3 certificates. This field 230 MUST be present, and the Version MUST be 3 (i.e. the value of this 231 field is 2). 233 3.2. Serial number 235 The serial number value is a positive integer that is unique per 236 Issuer. 238 3.3. Signature Algorithm 240 This field describes the algorithm used to compute the signature on 241 this certificate. This profile specifies SHA-256 with RSA 242 (sha256WithRSAEncryption), and, accordingly, the value for this field 243 MUST be the OID value 1.2.840.113549.1.1.11 [RFC4055]. 245 3.4. Issuer 247 This field identifies the entity that has signed and issued the 248 certificate. The value of this field is a valid X.501 name. 250 If the certificate is a subordinate certificate issued by virtue of 251 the CA bit set in the immediate superior certificate, then the issuer 252 name MUST correspond to the subject name as contained in the 253 immediate superior certificate. 255 3.5. Subject 257 This field identifies the entity to whom the resource has been 258 allocated / assigned. The value of this field is a valid X.501 name. 260 In this profile the subject name is determined by the issuer, and 261 each distinct entity certified by the issuer MUST be identified using 262 a subject name that is unique per issuer. 264 This field MUST be non-empty. 266 3.6. Valid From 268 The starting time at which point the certificate is valid. In this 269 profile the "Valid From" time SHOULD be no earlier than the time of 270 certificate generation. As per Section 4.1.2.5 of [RFC3280], 271 Certificate Authorities (CAs) conforming to this profile MUST always 272 encode the certificate's "Valid From" date through the year 2049 as 273 UTCTime, and dates in 2050 or later MUST be encoded as 274 GeneralizedTime. These two time formats are defined in [RFC3280]. 276 In this profile, it is valid for a certificate to have a value for 277 this field that pre-dates the same field value in any superior 278 certificate. However, it is not valid to infer from this information 279 that a certificate was, or will be, valid at any particular time 280 other than the current time. 282 3.7. Valid To 284 The Valid To time is the date and time at which point in time the 285 certificate's validity ends. It represents the anticipated lifetime 286 of the resource allocation / assignment arrangement between the 287 issuer and the subject. As per Section 4.1.2.5 of [RFC3280], CAs 288 conforming to this profile MUST always encode the certificate's 289 "Valid To" date through the year 2049 as UTCTime, and dates in 2050 290 or later MUST be encoded as GeneralizedTime. These two time formats 291 are defined in [RFC3280]. 293 In this profile, it is valid for a certificate to have a value for 294 this field that post-dates the same field value in any superior 295 certificate. However, it is not valid to infer from this information 296 that a certificate was, or will be, valid at any particular time 297 other than the current time. 299 Certificate Authorities typically are advised against issuing a 300 certificate with a validity interval that exceeds the validity 301 interval of the CA certificate that will be used to validate the 302 issued certificate. However, in the context of this profile, it is 303 anticipated that a CA may have good reason to issue a certificate 304 with a validity interval that exceeds the validity interval of the 305 CA's certificate. 307 3.8. Subject Public Key Info 309 This field specifies the subject's public key and the algorithm with 310 which the key is used. The public key algorithm MUST be RSA, and, 311 accordingly, the OID for the algorithm is 1.2.840.113549.1.1.1. A 312 minimum key size of 1024 bits is mandated in this profile. In the 313 context of certifying resources it is recommended that certificates 314 that are intended to be used as root certificates, and their 315 immediate subordinates SHOULD use a key size of 2048 bits. 316 Subordinates of these subordinate certificates, in the context of 317 continued level of high trust, SHOULD use a key size of 2048 bits. 319 In the application of this profile to certification of public number 320 resources, it would be consistent with this recommendation that the 321 Regional Internet Registries used a key size of 2048 bits, and that 322 their immediate subordinate certificate authorities also use a key 323 size of 2048 bits. All other subordinate certificates MAY use a key 324 size of 1024 bits. 326 3.9. Resource Certificate Version 3 Extension Fields 328 As noted in Section 4.2 of [RFC3280], each extension in a certificate 329 is designated as either critical or non-critical. A certificate- 330 using system MUST reject the certificate if it encounters a critical 331 extension it does not recognize; however, a non-critical extension 332 MAY be ignored if it is not recognized [RFC3280]. 334 The following X.509 V3 extensions MUST be present in a conforming 335 Resource Certificate. 337 3.9.1. Basic Constraints 339 The basic constraints extension identifies whether the subject of the 340 certificate is a CA and the maximum depth of valid certification 341 paths that include this certificate. 343 The issuer determines whether the cA boolean is set. If this bit is 344 set, then it indicates that the subject is allowed to issue resources 345 certificates within this overall framework (i.e. the subject is 346 permitted be a CA). 348 The Path Length Constraint is not specified in this profile and MUST 349 NOT be present. 351 The Basic Constraints extension field is a critical extension in the 352 Resource Certificate profile, and MUST be present. 354 3.9.2. Subject Key Identifier 356 The subject key identifier extension provides a means of identifying 357 certificates that contain a particular public key. To facilitate 358 certification path construction, this extension MUST appear in all 359 Resource Certificates. This extension is non-critical. 361 The value of the subject key identifier MUST be the value placed in 362 the key identifier field of the Authority Key Identifier extension of 363 immediate subordinate certificates (all certificates issued by the 364 subject of this certificate). 366 The Key Identifier used here is the 160-bit SHA-1 hash of the value 367 of the DER-encoded ASN.1 bit string of the subject public key, as 368 described in Section 4.2.1.2 of[RFC3280]. 370 3.9.3. Authority Key Identifier 372 The subject key identifier extension provides a means of identifying 373 certificates that are signed by the issuer's private key, by 374 providing a hash value of the issuer's public key. To facilitate 375 path construction, this extension MUST appear in all Resource 376 Certificates. The keyIdentifier subfield MUST be present in all 377 Resource Certificates, with the exception of a CA who issues a "self- 378 signed" certificate. The authorityCertIssuer and 379 authorityCertSerialNumber subfields MUST NOT be present. This 380 extension is non-critical. 382 The Key Identifier used here is the 160-bit SHA-1 hash of the value 383 of the DER-encoded ASN.1 bit string of the issuer's public key, as 384 described in Section 4.2.1.1 of [RFC3280]. 386 3.9.4. Key Usage 388 This describes the purpose of the certificate. This is a critical 389 extension, and it MUST be present. 391 In certificates issued to CAs only the keyCertSign and CRLSign bits 392 are set to TRUE and must be the only bits set to TRUE. In end-entity 393 certificates the digitialSignature bit MUST be set and MUST be the 394 only bit set to TRUE. 396 3.9.5. CRL Distribution Points 398 This field (CRLDP) identifies the location(s) of the CRL(s) 399 associated with certificates issued by this Issuer. This profile 400 uses the URI form of object identification. The preferred URI access 401 mechanism is a single RSYNC URI ("rsync://") [rsync] that references 402 a single inclusive CRL for each issuer. 404 In this profile the certificate issuer is also the CRL issuer, 405 implying at the CRLIssuer subfield MUST be omitted, and the 406 distributionPoint subfield MUST be present. The Reasons subfield 407 MUST be omitted. 409 The distributionPoint MUST contain general names, and MUST NOT 410 contain a nameRelativeToCRLIssuer. The type of the general name MUST 411 be of type URI. In this profile, the scope of the CRL is specified 412 to be all certificates issued by this issuer. The sequence of 413 distributionPoint values MUST contain only a single 414 DistributionPointName set. The DistributionPointName set MAY contain 415 more than one URI value. An RSYNC URI MUST be present in the 416 DistributionPointName set. 418 This extension MUST be present and it is non-critical. 420 3.9.6. Authority Information Access 422 This field (AIA) identifies the point of publication of all 423 certificates that are issued by the issuer's immediate superior CA. 424 This is specified in RFC3280 as a sequence of reference objects. In 425 this profile a single reference object to the immediate superior's 426 publication location MUST be used. 428 This profile uses a URI form of object identification. The preferred 429 URI access mechanisms is "rsync", and an RSYNC URI MUST be specified 430 with an accessMethod value of id-ad-caIssuers. The URI MUST 431 reference the point of publication of all objects published by the 432 issuer's immediate superior issuer. Other access method URIs 433 referencing the same publication point MAY also be included in the 434 value sequence of this extension. 436 In the case of self-signed certificates that undertake the role of a 437 "root" trust anchor within a certificate hierarchy the AIA extension 438 field SHOULD be omitted. In all other cases this field MUST be 439 present, and is non-critical. 441 3.9.7. Subject Information Access 443 This field (SIA) identifies the location of information and services 444 relating to the subject of the certificate in which the SIA extension 445 appears. Where the Subject is a CA in this profile, this information 446 and service collection will include all current valid certificates 447 that have been issued by this subject that are signed with the 448 subject's corresponding private key. 450 This profile uses a URI form of location identification. The 451 preferred URI access mechanism is "rsync", and an RSYNC URI MUST be 452 specified, with an access method value of id-ad-caRepository when the 453 subject of the certificate is a CA. Other access method URIs that 454 reference the same location MAY also be included in the value 455 sequence of this extension. 457 This field MUST be present when the subject is a CA, and is non- 458 critical. Where the subject is not a CA this field MUST NOT be 459 present. 461 3.9.8. Certificate Policies 463 This extension MUST reference the Resource Certificate Policy, using 464 the OID Policy Identifier value of "1.3.6.1.5.5.7.14.2". This field 465 MUST be present and MUST contain only this value for Resource 466 Certificates. 468 PolicyQualifiers MUST NOT be used in this profile. 470 This extension MUST be present and it is critical. 472 3.9.9. Subject Alternate Name 474 This is an optional extension, and MAY contain an X.501 Name as 475 supplied by the subject in the Certificate Request, or as assigned by 476 the issuer. 478 3.9.10. IP Resources 480 This field contains the list of IP address resources as per 481 [RFC3779]. The value may specify the "inherit" element for a 482 particular AFI value. In the context of resource certificates 483 describing public number resources for use in the public Internet, 484 the SAFI value MUST NOT be used. All Resource Certificates MUST 485 include an IP Resources extension, an AS Resources extension, or both 486 extensions. 488 This extension, if present, MUST be marked critical. 490 3.9.11. AS Resources 492 This field contains the list of AS number resources as per [RFC3779], 493 or may specify the "inherit" element. RDI values are NOT supported 494 in this profile and MUST NOT be used. All Resource Certificates MUST 495 include an IP Resources extension, an AS Resources extension, or both 496 extensions. 498 This extension, if present, MUST be marked critical. 500 4. Resource Certificate Revocation List Profile 502 Each CA MUST issue a version 2 Certificate Revocation List (CRL), 503 consistent with [RFC3280]. The CRL issuer is the CA, and no indirect 504 CRLs are supported in this profile. The scope of the CRL MUST be 505 "all certificates issued by this CA". The contents of the CRL are a 506 list of all unexpired certificates issued by the CA that have been 507 revoked by the CA. 509 An entry MUST NOT be removed from the CRL until it appears on one 510 regularly scheduled CRL issued beyond the revoked certificate's 511 validity period. 513 This profile does not allow issuance of Delta CRLs. 515 The profile does not allow the issuance of multiple current CRLs with 516 different scope by a single CA. 518 No CRL fields other than those listed below are allowed in CRLs 519 issued under this profile. Unless otherwise indicated, these fields 520 MUST be present in the CRL. Where two or more CRLs issued by a 521 single CA are present in a certificate repository, the CRL with the 522 highest value of the "CRL Number" field supersedes all other CRLs 523 issued by this CA. 525 4.1. Version 527 Resource Certificate Revocation Lists are Version 2 certificates (the 528 integer value of this field is 1). 530 4.2. Issuer Name 532 The value of this field is the X.501 name of the issuing CA who is 533 also the signer of the CRL, and is identical to the Issuer name in 534 the Resource Certificates that are issued by this issuer. 536 4.3. This Update 538 This field contains the date and time that this CRL was issued. The 539 value of this field MUST be encoded as UTCTime for dates through the 540 year 2049, and MUST be encoded as GeneralizedTime for dates in the 541 year 2050 or later. 543 4.4. Next Update 545 This is the date and time by which the next CRL SHOULD be issued. 546 The value of this field MUST be encoded as UTCTime for dates through 547 the year 2049, and MUST be encoded as GeneralizedTime for dates in 548 the year 2050 or later. 550 4.5. Signature 552 This field contains the algorithm used to sign this CRL. The 553 signature algorithm MUST be SHA-256 with RSA. This field MUST be 554 present. 556 4.6. Revoked Certificate List 558 When there are no revoked certificates, then the revoked certificate 559 list MUST be absent. 561 For each revoked resource certificate only the following fields MUST 562 be present. No CRL entry extensions are supported in this profile, 563 and CRL entry extensions MUST NOT be present in a CRL. 565 4.6.1. Serial Number 567 The issuer's serial number of the revoked certificate. 569 4.6.2. Revocation Date 571 The time the certificate was revoked. This time SHOULD NOT be a 572 future date. The value of this field MUST be encoded as UTCTime for 573 dates through the year 2049, and MUST be encoded as GeneralizedTime 574 for dates in the year 2050 or later. 576 4.7. CRL Extensions 578 The X.509 v2 CRL format allows extensions to be placed in a CRL. The 579 following extensions are supported in this profile, and MUST be 580 present in a CRL. 582 4.7.1. Authority Key Identifier 584 The authority key identifier extension provides a means of 585 identifying the public key corresponding to the private key used to 586 sign a CRL. Conforming CRL issuers MUST use the key identifier 587 method. The syntax for this CRL extension is defined in section 588 4.2.1.1 of [RFC3280]. 590 This extension is non-critical. 592 4.7.2. CRL Number 594 The CRL Number extension conveys a monotonically increasing sequence 595 number for a given CA. This extension allows users to easily 596 determine when a particular CRL supersedes another CRL. The highest 597 CRL Number value supersedes all other CRLs issued by the CA within 598 the scope of this profile. 600 This extension is non-critical. 602 5. Resource Certificate Request Profile 604 5.1. PCKS#10 Profile 606 This profile refines the specification in [RFC2986], as it relates to 607 Resource Certificates. A Certificate Request Message object, 608 formatted according to PKCS#10, is passed to a Certificate Authority 609 as the initial step in issuing a certificate. 611 This request may be conveyed to the CA via a Registration Authority 612 (RA), acting under the direction of a Subject. 614 With the exception of the public key related fields, the CA is 615 permitted to alter any requested field. 617 5.1.1. PKCS#10 Resource Certificate Request Template Fields 619 This profile applies the following additional constraints to fields 620 that may appear in a CertificationRequestInfo: 622 Version 623 This field is mandatory and MUST have the value 0. 625 Subject 626 The CA SHOULD consider this name as the subject's suggestion, but 627 the CA is NOT bound to honour this suggestion, as the subject name 628 MUST be unique per issuer. This field MAY be empty, in which case 629 the issuer MUST generate a subject name that is unique in the 630 context of the issuer. 632 SubjectPublicKeyInfo 633 This field specifies the subject's public key and the algorithm 634 with which the key is used. The public key algorithm MUST be RSA, 635 and the OID for the algorithm is 1.2.840.113549.1.1.1. This field 636 also includes a bit-string representation of the entity's public 637 key. For the RSA public-key algorithm the bit string contains the 638 DER encoding of a value of PKCS #1 type RSAPublicKey. 640 Attributes 641 [RFC2986] defines the attributes field as key-value pairs where 642 the key is an OID and the value's structure depends on the key. 644 The only attribute used in this profile is the ExtensionRequest 645 attribute as defined in [RFC2985]. This attribute contains X509v3 646 Certificate Extensions. The profile for extensions in certificate 647 requests is specified in Section 5.3. 649 This profile applies the following additional constraints to fields 650 that may appear in a CertificationRequest Object: 652 signatureAlgorithm 653 Must be SHA-256 with RSA encryption (sha256WithRSAEncryption). 654 Accordingly, the value for this field MUST be the OID value 655 1.2.840.113549.1.1.11 657 5.2. CRMF Profile 659 This profile refines the Certificate Request Message Format (CRMF) 660 specification in [RFC4211], as it relates to Resource Certificates. 661 A Certificate Request Message object, formatted according to the 662 CRMF, is passed to a Certificate Authority as the initial step in 663 issuing a certificate. 665 This request may be conveyed to the CA via a Registration Authority 666 (RA), acting under the direction of a subject. 668 With the exception of the public key related fields, the CA is 669 permitted to alter any requested field. 671 5.2.1. CRMF Resource Certificate Request Template Fields 673 This profile applies the following additional constraints to fields 674 that may appear in a Certificate Request Template: 676 Version 677 This field MAY be absent, or MAY specify the request of a Version 678 3 Certificate. It SHOULD be omitted. 680 SerialNumber 681 As per [RFC4211], this field is assigned by the CA and MUST be 682 omitted in this profile. 684 SigningAlgorithm 685 As per [RFC4211], this field is assigned by the CA and MUST be 686 omitted in this profile. 688 Issuer 689 This field is assigned by the CA and MUST be omitted in this 690 profile. 692 Validity 693 This field MAY be omitted. If omitted, the CA will issue a 694 Certificate with Validity dates as determined by the CA. If 695 specified, then the CA MAY override the requested values with 696 dates as determined by the CA. 698 Subject As the subject name is assigned by the CA, this field MAY be 699 omitted, in which case the subject name will be generated by the 700 CA. If specified, the CA SHOULD consider this as the subject's 701 suggestion, but the CA is NOT bound to honour this suggestion. 703 PublicKey 704 This field MUST be present. 706 extensions 707 This attribute contains X509v3 Certificate Extensions. The 708 profile for extensions in certificate requests is specified in 709 Section 5.3. 711 5.2.2. Resource Certificate Request Control Fields 713 The following control fields are supported in this profile: 715 Authenticator Control 716 It is noted that the intended model of authentication of the 717 subject in a long term one, and the advice as offered in [RFC4211] 718 is that the Authenticator Control field be used. 720 [Note - not for publication: The method of generation and 721 authentication of this field is to be specified. The desirable 722 properties include the ability to validate the subject and the 723 authenticity of the provided public key.] 725 Resource Class 726 The profile defines an additional control for Resource Certificate 727 Requests, namely a Resource Class control. 729 The Subject MUST specify a Resource Class value as specified by 730 the CA to which the request refers. The CA will issue a 731 certificate with the IP Address and AS Number resources that match 732 the subject's right-of-use of these resources with the class of 733 resources specified by the Resource Class control value. 735 [Note - not for publication: This specification of the resource 736 class is related the various forms of resource allocation which 737 imply that an entity may be the holder of resources with differing 738 validation dates and differing validation paths, even when the 739 entity is the recipient of resources allocated from a single 740 'upstream' issuing registry. Due to this consideration it may not 741 be possible to issue a single certificate with an all-encompassing 742 resource set. Alternatively it is possible to define a structure 743 where there is no Resource Class specified and the issuer issues a 744 set of spanning certificates for all resources held by the subject 745 (i.e. all resources that fall under the subject's "right-of-use")] 747 5.3. Certificate Extension Attributes in Certificate Requests 749 This profile allows the following extensions to appear in a PKCS#10 750 and CRMF Certificate Request: 752 BasicConstraints 753 If this is omitted then this field is assigned by the CA. 755 The Path Length Constraint is not supported in this Resource 756 Certificate Profile, and this field MUST be omitted in this 757 profile. 759 The CA MAY honour the SubjectType CA bit set to on. If this bit 760 is set, then it indicates that the Subject is allowed to issue 761 resource certificates within this overall framework. 763 The CA MAY honour the SubjectType CA bit set of off (End Entity 764 certificate request). 766 SubjectKeyIdentifier 767 This field is assigned by the CA and MUST be omitted in this 768 profile. 770 AuthorityKeyIdentifier 771 This field is assigned by the CA and MUST be omitted in this 772 profile. 774 KeyUsage 775 The CA MAY honor KeyUsage extensions of CertificateSigning and 776 CRLSigning if present, as long as this is consistent with the 777 BasicConstraints SubjectType subfield, when specified. 779 SubjectInformationAccess 780 This field MAY be honoured by the CA on the condition that the CA 781 issues a certificate with the BasicConstraints SubjectType CA bit 782 set and the KeyUsage set to CertificateSigning and CRLSigning. 784 If specified, this field contains a URI of the form of a single 785 RSYNC URI that references a single publication point that will be 786 used by the subject for all certificates that published by the 787 subject for subordinate certificates, and MUST be honoured by the 788 CA. 790 If this field is omitted and KeyUsage is set to CertificateSigning 791 then the CA MUST generate a URI value for the 792 SubjectInformationAccess field based on out-of-band information 793 that has been passed between the CA and the requester. 795 [Note not for publication - if this field is missing than it is 796 also an option for the Issuer to deny the request and not issue a 797 certificate if the issued certificate was to have the CA bit set.] 799 SubjectAlternateName 800 This field MAY be present, and the CA MAY use this as the 801 SubjectAltName in the issued Certificate. 802 CRLDistributionPoints 803 This field is assigned by the CA and MUST be omitted in this 804 profile. 806 AuthorityInformationAccess 807 This field is assigned by the CA and MUST be omitted in this 808 profile. 810 SubjectInformationAccess 811 This field MAY be honoured by the CA on the condition that the CA 812 issues a certificate with the BasicConstraints SubjectType CA bit 813 set and the KeyUsage set to CertificateSigning and CRLSigning. 815 If specified, this field contains a URI of the form of a single 816 rsync URL that references a single publication point that will be 817 used by the subject for all certificates that published by the 818 subject for subordinate certificates, and MUST be honoured by the 819 CA. 821 If this field is omitted and KeyUsage is set to CertificateSigning 822 then the CA MUST generate a SIA URL based on out-of-band 823 information that has been passed between the CA and the requester. 825 [Note not for publication - the same considerations with respect 826 to the CRL DistributionPoints apply to this field as well. i.e. if 827 this field is missing than it is also an option for the Issuer to 828 deny the request and not issue a certificate if the issued 829 certificate was to have the CA bit set.] 831 CertificatePolicies 832 This field is assigned by the CA and MUST be omitted in this 833 profile. 835 SubjectAlternateName 836 This field MAY be present, and the CA MAY use this as the 837 SubjectAltName in the issued Certificate. 839 IPResources 840 This field is assigned by the CA and MUST be omitted in this 841 profile. 843 ASResources 844 This field is assigned by the CA and MUST be omitted in this 845 profile. 847 With the exception of the publicKey field, the CA is permitted to 848 alter any requested field. 850 6. Resource Certificate Validation 852 This section describes the Resource Certificate validation procedure. 854 This refines the generic procedure described in [RFC3280]: 856 To meet this goal, the path validation process verifies, among other 857 things, that a prospective certification path (a sequence of n 858 certificates) satisfies the following conditions: 860 1. for all x in {1, ..., n-1}, the subject of certificate x is the 861 issuer of certificate x+1; 863 2. certificate 1 is issued by a trust anchor; 865 3. certificate n is the certificate to be validated; and 867 4. for all x in {1, ..., n}, the certificate was valid at the time 868 in question. 870 6.1. Trust Anchors for Resource Certificates 872 The trust model that may be used in the resource certificate 873 framework in the context of validation of assertions of public number 874 resources in public-use contexts is one that readily maps to a top- 875 down delegated CA model that mirrors the delegation of resources from 876 a registry distribution point to the entities that are the direct 877 recipients of these resources. Within this trust model these 878 recipient entities may, in turn, operate a registry and perform 879 further allocations or assignments. This is a strict hierarchy, in 880 that any number resource and a corresponding recipient entity has 881 only one 'parent' issuing registry for that number resource (i.e. 882 there is always a unique parent entity for any resource and 883 corresponding entity), and that the issuing registry is not a direct 884 or indirect subordinate recipient entity of the recipient entity in 885 question (i.e. no loops in the hierarchy). The only exception to the 886 "no loop" condition would be where a putative trust anchor may issue 887 a self-signed root certificate. 889 The more general consideration is that selection of a trust anchor is 890 a role undertaken by relying parties, and the structure of the 891 resource certificate profile admits the same variety of trust models 892 as the PKIX profile. There is only one additional caveat on the 893 general applicability of trust models and PKIX frameworks, namely 894 that in forming a validation path to a trust anchor, the sequence of 895 certificates MUST preserve the resource extension validation 896 property, as described in Section 6.2. 898 6.2. Resource Extension Validation 900 The IP resource extension definition [RFC3779] defines a critical 901 extensions for Internet number resources. These are ASN.1 encoded 902 representations of the IPv4 and IPv6 address range (either as a 903 prefix/length, or start-end pair) and the AS number set. 905 Valid Resource Certificates MUST have a valid IP address and/or AS 906 number resource extension. In order to validate a Resource 907 Certificate the resource extension must also be validated. This 908 validation process relies on definitions of comparison of resource 909 sets: 911 more specific Given two IP address or AS number contiguous ranges, A 912 and B, A is "more specific" than B if range B includes all IP 913 addresses or AS numbers described by range A, and if range B is 914 larger than range A. 916 equal Given two IP address or AS number contiguous ranges, A and B, 917 A is "equal" to B if range A describes precisely the same 918 collection of IP addresses or AS numbers as described by range B. 919 The definition of "inheritance" in [RFC3779]is equivalent to this 920 "equality" comparison. 921 encompass Given two IP address and AS number sets X and Y, X 922 "encompasses" Y if, for every contiguous range of IP addresses or 923 AS numbers elements in set Y, the range element is either more 924 specific than or equal to a contiguous range element within the 925 set X. 927 Validation of a certificate's resource extension in the context of an 928 ordered certificate sequence of {1,2, ... , n} where '1'is a trust 929 anchor and 'n' is the target certificate, and where the subject of 930 certificate 'x' is the issuer of certificate 'x' + 1, implies that 931 the resources described in certificate 'x', for 'x' is greater than 932 1, "encompass" the resources described in certificate 'x' + 1. 934 6.3. Resource Certificate Path Validation 936 Validation of signed resource data using a target resource 937 certificate consists of assembling an ordered sequence (or 938 'Certificate Path') of certificates ({1,2,...n} where '1' is a trust 939 anchor, and 'n' is the target certificate) verifying that all of the 940 following conditions hold: 942 1. The certificate can be verified using the Issuer's public key and 943 the signature algorithm 945 2. The current time lies within the certificate's Validity From and 946 To values. 948 3. The certificate contains all fields that MUST be present and 949 contains field values as specified in this profile for all field 950 values that MUST be present. 952 4. No field value that MUST NOT be present is present in the 953 certificate. 955 5. The Issuer has not revoked the certificate by placing the 956 certificate's serial number on the Issuer's current Certificate 957 Revocation List, and the CRL is itself valid. 959 6. That the resource extension data is "encompassed" by the resource 960 extension data contained in a valid certificate where this Issuer 961 is the Subject (the previous certificate in the ordered sequence) 963 7. The Certificate Path originates at a trust anchor, and there 964 exists a signing chain across the Certificate Path where the 965 Subject of Certificate x in the Certificate Path matches the 966 Issuer in Certificate x+1 in the Certificate Path. 968 A certificate validation algorithm may perform these tests in any 969 chosen order. 971 A Resource Certificate may have a number of potential parent 972 certificates, where a potential parent certificate is one where the 973 subject name matches the issuer name of the resource certificate. A 974 candidate parent certificate is any member of the parent certificate 975 set where the resource extension validity constraint of 976 "encompassing" is satisfied, and a valid candidate parent certificate 977 is any candidate parent certificate that also matches validity 978 conditions 1 through 6. A valid parent certificate is a valid 979 candidate parent certificate that also matches validity condition 7. 981 Certificates and CRLs used in this process may be found on a single 982 repository, maintained by a regular top-down walk from the Root Trust 983 Anchors via Issuer certificates and their SIA fields as forward 984 pointers, plus the CRLDP. Alternatively, validation may be performed 985 using a bottom-up process with on-line certificate access using the 986 AIA and CRLDP pointers to guide the certificate retrieval process. 988 There exists the possibility of encountering certificate paths that 989 are arbitrarily long, or attempting to generate paths with loops as 990 means of creating a potential DOS attack on a certificate validator. 991 Some further heuristics may be required to halt the validation 992 process in order to avoid some of the issues associated with attempts 993 to validate such structures. It is suggested that implementations of 994 Resource Certificate validation MAY halt with a validation failure if 995 the certificate path length exceeds a pre-determined configuration 996 parameter. 998 In the context of Resource Certificates that are generated in respect 999 of public resources and with the framework of the associated resource 1000 distribution process, it is suggested that this configuration 1001 parameter of maximum certificate path length be set to a value of 1002 100. 1004 [Note - not for publication: There is no particular reason for 1005 suggesting this value other than the observation that it appears to 1006 be comfortably longer than any real distribution chain for public 1007 number resources, without being too long so as to pose potential DOS 1008 concerns for relying parties performing a validation operation.] 1010 7. Security Considerations 1012 [to be completed] 1014 8. IANA Considerations 1016 [There are no IANA considerations stated in this version of the 1017 document.] 1019 9. Acknowledgements 1021 The authors would like to acknowledge the valued contributions from 1022 Stephen Kent, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo 1023 Patara and Rob Austein in the preparation and subsequent review of 1024 this document. 1026 10. Normative References 1028 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1029 September 1981. 1031 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and 1032 J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 1033 BCP 12, RFC 2050, November 1996. 1035 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1036 Classes and Attribute Types Version 2.0", RFC 2985, 1037 November 2000. 1039 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1040 Request Syntax Specification Version 1.7", RFC 2986, 1041 November 2000. 1043 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1044 X.509 Public Key Infrastructure Certificate and 1045 Certificate Revocation List (CRL) Profile", RFC 3280, 1046 April 2002. 1048 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1049 Addresses and AS Identifiers", RFC 3779, June 2004. 1051 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1052 Algorithms and Identifiers for RSA Cryptography for use in 1053 the Internet X.509 Public Key Infrastructure Certificate 1054 and Certificate Revocation List (CRL) Profile", RFC 4055, 1055 June 2005. 1057 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 1058 Nicholas, "Internet X.509 Public Key Infrastructure: 1059 Certification Path Building", RFC 4158, September 2005. 1061 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1062 Certificate Request Message Format (CRMF)", RFC 4211, 1063 September 2005. 1065 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1066 Architecture", RFC 4291, February 2006. 1068 [rsync] Tridgell, A., "rsync", April 2006, 1069 . 1071 Appendix A. Example Resource Certificate 1073 The following is an example Resource Certificate. 1075 Certificate Name: hu9fdDBq60mrk7cPRuX2DYuXSRQ-3.cer 1077 Data: 1078 Version: 3 1079 Serial: 3 1080 Signature Algorithm: Hash: SHA256, Encryption: RSA 1081 Issuer: CN=Demo Production APNIC CA - Not for real use, 1082 E=ca@apnic.net 1083 Validity: 1084 Not Before: Thu Jul 27 06:34:04 2006 GMT 1085 Not After: Fri Jul 27 06:34:04 2007 GMT 1086 Subject: CN=APNIC own-use network resources 1087 Subject Key Identifier: 1088 86:ef:5f:74:30:6a:eb:49:ab:93:b7:0f:46:e5:f6:0d: 1089 8b:97:49:14 1090 Subject Key Identifier g(SKI): 1091 hu9fdDBq60mrk7cPRuX2DYuXSRQ 1092 Subject Public Key Info: 1093 Public Key Algorithm: rsaEncryption 1094 RSA Public Key: Modulus: 1095 c1:25:a1:b0:db:89:83:a0:fc:f1:c0:e4:7b:93:76:c1: 1096 59:b7:0d:ac:25:25:ed:88:ce:00:03:ea:99:1a:9a:2a: 1097 0e:10:2e:5f:c0:45:87:47:81:7b:1d:4d:44:aa:65:a3: 1098 f8:07:84:32:ea:04:70:27:05:2b:79:26:e6:e6:3a:cb: 1099 b2:9a:65:6c:c1:4e:d7:35:fb:f6:41:1e:8b:1c:b8:e4: 1100 5a:3a:d6:d0:7b:82:9a:23:03:f8:05:4c:68:42:67:fe: 1101 e7:45:d9:2c:a6:d1:b3:da:cf:ad:77:c5:80:d2:e3:1e: 1102 4d:e8:bf:a2:f2:44:10:b2:2f:61:bc:f4:89:31:54:7c: 1103 56:47:d5:b1:c3:48:26:95:93:c9:6f:70:14:4d:ac:a5: 1104 c2:8e:3d:1f:6d:f8:d4:93:9d:14:c7:15:c7:34:8e:ba: 1105 dd:70:b3:c2:2b:08:78:59:97:dd:e4:34:c7:d8:de:5c: 1106 f7:94:6f:95:59:ba:29:65:f5:98:15:8f:8e:57:59:5d: 1107 92:1f:64:2f:b5:3d:69:2e:69:83:c2:10:c6:aa:8e:03: 1108 d5:69:11:bd:0d:b5:d8:27:6c:74:2f:60:47:dd:2e:87: 1109 24:c2:36:68:2b:3c:fd:bd:22:57:a9:4d:e8:86:3c:27: 1110 03:ce:f0:03:2e:59:ce:05:a7:41:3f:2f:64:50:dd:e7 1111 RSA Public Key: Exponent: 65537 1112 Basic Constraints: CA: TRUE 1113 Subject Info Access: 1114 caRepository - rsync://repository.apnic.net/APNIC/ 1115 pvpjvwUeQix2e54X8fGbhmdYMo0/ 1116 q66IrWSGuBE7jqx8PAUHAlHCqRw/ 1117 hu9fdDBq60mrk7cPRuX2DYuXSRQ 1118 Key Usage: keyCertSign, cRLSign 1119 CRL Distribution Points: 1120 rsync://repository.apnic.net/APNIC/ 1121 pvpjvwUeQix2e54X8fGbhmdYMo0/ 1122 q66IrWSGuBE7jqx8PAUHAlHCqRw/ 1123 q66IrWSGuBE7jqx8PAUHAlHCqRw.crl 1124 Authority Info Access: caIssuers - 1125 rsync://repository.apnic.net/APNIC/ 1126 pvpjvwUeQix2e54X8fGbhmdYMo0/ 1127 q66IrWSGuBE7jqx8PAUHAlHCqRw 1128 Authority Key Identifier: Key Identifier: 1129 ab:ae:88:ad:64:86:b8:11:3b:8e:ac:7c:3c:05:07:02: 1130 51:c2:a9:1c 1131 Authority Key Identifier: Key Identifier g(AKI): 1132 q66IrWSGuBE7jqx8PAUHAlHCqRw 1133 Certificate Policies: 1.3.6.1.5.5.7.14.2 1134 IPv4: 202.12.27.0-202.12.29.255, 202.12.31.0/24, 1135 203.119.0.0/24, 203.119.42.0/23 1136 IPv6: 2001:dc0::/32 1137 ASNum: 4608, 4777, 9545, 18366-18370 1138 Signature: 1139 c5:e7:b2:f3:62:cb:e3:bc:50:1e:6b:90:13:19:f4:5b: 1140 4a:1c:1c:ab:b5:de:b1:a4:22:e0:28:f5:3b:d0:8c:59: 1141 0f:85:f2:06:a6:ae:22:e6:d0:99:fe:cb:eb:1d:6a:e2: 1142 a3:f1:a2:25:95:ec:a7:7d:96:35:dc:16:a7:2f:f5:b7: 1143 11:ba:97:05:57:5f:5d:07:5a:c8:19:c8:27:d3:f7:a3: 1144 92:66:cb:98:2d:e1:7f:a8:25:96:ab:af:ed:87:02:28: 1145 f5:ae:b6:e3:0c:f7:18:82:70:82:f4:76:54:06:b9:9f: 1146 e1:a5:f7:ae:72:dd:ee:f0:d4:d2:78:bb:61:73:cf:51: 1147 26:9f:ea:e8:20:49:06:ba:0c:ac:1d:f6:07:b8:63:a0: 1148 4d:3d:8e:12:84:3a:d0:ec:94:7e:02:db:d4:85:cf:12: 1149 5c:7b:12:1a:52:ab:3c:ba:00:f2:71:e7:f0:fd:b3:f4: 1150 81:e8:a7:cb:07:ca:3a:a4:24:fe:dc:bb:51:16:6a:28: 1151 33:40:a4:64:60:75:0e:c8:06:c8:5f:e5:98:be:16:a3: 1152 bc:19:e7:b3:4f:00:0a:8e:81:33:dd:4c:a0:fb:f5:1c: 1153 1f:1d:3f:b5:90:8b:ec:98:67:76:95:56:8a:94:45:54: 1154 52:3d:1c:69:4c:6f:8a:9f:09:ec:ef:b0:a9:bc:cf:9d 1156 Appendix B. Example Certificate Revocation List 1158 The following is an example Certificate Revocation List. 1160 CRL Name: q66IrWSGuBE7jqx8PAUHAlHCqRw.crl 1162 Data: 1163 Version: 2 1164 Signature Algorithm: 1165 Hash: SHA256, Encryption: RSA 1166 Issuer: CN=Demo Production APNIC CA - Not for real use, 1167 E=ca@apnic.net 1168 This Update: Thu Jul 27 06:30:34 2006 GMT 1169 Next Update: Fri Jul 28 06:30:34 2006 GMT 1170 Authority Key Identifier: Key Identifier: 1171 ab:ae:88:ad:64:86:b8:11:3b:8e:ac:7c:3c:05: 1172 07:02:51:c2:a9:1c 1173 Authority Key Identifier: Key Identifier g(AKI): 1174 q66IrWSGuBE7jqx8PAUHAlHCqRw 1175 CRLNumber: 4 1176 Revoked Certificates: 1 1177 Serial Number: 1 1178 Revocation Date: Mon Jul 17 05:10:19 2006 GMT 1179 Serial Number: 2 1180 Revocation Date: Mon Jul 17 05:12:25 2006 GMT 1181 Serial Number: 4 1182 Revocation Date: Mon Jul 17 05:40:39 2006 GMT 1183 Signature: 1184 b2:5a:e8:7c:bd:a8:00:0f:03:1a:17:fd:40:2c:46: 1185 0e:d5:64:87:e7:e7:bc:10:7d:b6:3e:39:21:a9:12: 1186 f4:5a:d8:b8:d4:bd:57:1a:7d:2f:7c:0d:c6:4f:27: 1187 17:c8:0e:ae:8c:89:ff:00:f7:81:97:c3:a1:6a:0a: 1188 f7:d2:46:06:9a:d1:d5:4d:78:e1:b7:b0:58:4d:09: 1189 d6:7c:1e:a0:40:af:86:5d:8c:c9:48:f6:e6:20:2e: 1190 b9:b6:81:03:0b:51:ac:23:db:9f:c1:8e:d6:94:54: 1191 66:a5:68:52:ee:dd:0f:10:5d:21:b8:b8:19:ff:29: 1192 6f:51:2e:c8:74:5c:2a:d2:c5:fa:99:eb:c5:c2:a2: 1193 d0:96:fc:54:b3:ba:80:4b:92:7f:85:54:76:c9:12: 1194 cb:32:ea:1d:12:7b:f8:f9:a2:5c:a1:b1:06:8e:d8: 1195 c5:42:61:00:8c:f6:33:11:29:df:6e:b2:cc:c3:7c: 1196 d3:f3:0c:8d:5c:49:a5:fb:49:fd:e7:c4:73:68:0a: 1197 09:0e:6d:68:a9:06:52:3a:36:4f:19:47:83:59:da: 1198 02:5b:2a:d0:8a:7a:33:0a:d5:ce:be:b5:a2:7d:8d: 1199 59:a1:9d:ee:60:ce:77:3d:e1:86:9a:84:93:90:9f: 1200 34:a7:02:40:59:3a:a5:d1:18:fb:6f:fc:af:d4:02: 1201 d9 1203 Authors' Addresses 1205 Geoff Huston 1206 Asia Pacific Network Information Centre 1208 Email: gih@apnic.net 1209 URI: http://www.apnic.net 1211 George Michaelson 1212 Asia Pacific Network Information Centre 1214 Email: ggm@apnic.net 1215 URI: http://www.apnic.net 1217 Robert Loomans 1218 Asia Pacific Network Information Centre 1220 Email: robertl@apnic.net 1221 URI: http://www.apnic.net 1223 Full Copyright Statement 1225 Copyright (C) The Internet Society (2006). 1227 This document is subject to the rights, licenses and restrictions 1228 contained in BCP 78, and except as set forth therein, the authors 1229 retain all their rights. 1231 This document and the information contained herein are provided on an 1232 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1233 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1234 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1235 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1236 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1237 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1239 Intellectual Property 1241 The IETF takes no position regarding the validity or scope of any 1242 Intellectual Property Rights or other rights that might be claimed to 1243 pertain to the implementation or use of the technology described in 1244 this document or the extent to which any license under such rights 1245 might or might not be available; nor does it represent that it has 1246 made any independent effort to identify any such rights. Information 1247 on the procedures with respect to rights in RFC documents can be 1248 found in BCP 78 and BCP 79. 1250 Copies of IPR disclosures made to the IETF Secretariat and any 1251 assurances of licenses to be made available, or the result of an 1252 attempt made to obtain a general license or permission for the use of 1253 such proprietary rights by implementers or users of this 1254 specification can be obtained from the IETF on-line IPR repository at 1255 http://www.ietf.org/ipr. 1257 The IETF invites any interested party to bring to its attention any 1258 copyrights, patents or patent applications, or other proprietary 1259 rights that may cover technology that may be required to implement 1260 this standard. Please address the information to the IETF at 1261 ietf-ipr@ietf.org. 1263 Acknowledgment 1265 Funding for the RFC Editor function is provided by the IETF 1266 Administrative Support Activity (IASA).