idnits 2.17.1 draft-ietf-sidr-res-certs-00.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 994. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1005. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1012. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1018. ** 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 2 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 137: '...Certificate that MUST be followed. Re...' RFC 2119 keyword, line 167: '...esource extension SHOULD be a CRITICAL...' RFC 2119 keyword, line 170: '... extension MUST be used and MUST...' RFC 2119 keyword, line 175: '... framework MUST use this canonic...' RFC 2119 keyword, line 200: '... OPTIONAL, all the fields listed her...' (95 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: notBefore This field will be mapped to the ValidityFrom certificate field. If this field is later than the CA's business rule for certificate issuance, then the request MAY NOT be honored. -- 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 (June 9, 2006) is 6529 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Huston 3 Internet-Draft R. Loomans 4 Intended status: Best Current G. Michaelson 5 Practice APNIC 6 Expires: December 11, 2006 June 9, 2006 8 A Profile for X.509 PKIX Resource Certificates 9 draft-ietf-sidr-res-certs-00.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 December 11, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document defines a profile for X.509 certificates for the 43 purposes of supporting validation of assertions of "right-to- use" of 44 an Internet Number Resource (IP Addresses and Autonomous System 45 Numbers). This profile is used to convey the authorization of the 46 subject to be regarded as the current unique controlled of the IP 47 addresses and AS numbers that are described in a Resource 48 Certificate. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.6. Valid From . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.7. Valid To . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.8. Subject Public Key Info . . . . . . . . . . . . . . . . . 7 64 3.9. Resource Certificate Version 3 Extension Fields . . . . . 7 65 3.9.1. Basic Constraints . . . . . . . . . . . . . . . . . . 7 66 3.9.2. Subject Key Identifier . . . . . . . . . . . . . . . . 8 67 3.9.3. Authority Key Identifier . . . . . . . . . . . . . . . 8 68 3.9.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 8 69 3.9.5. CRL Distribution Points . . . . . . . . . . . . . . . 8 70 3.9.6. Authority Information Access . . . . . . . . . . . . . 9 71 3.9.7. Subject Information Access . . . . . . . . . . . . . . 9 72 3.9.8. Certificate Policies . . . . . . . . . . . . . . . . . 9 73 3.9.9. Subject Alternate Name . . . . . . . . . . . . . . . . 9 74 3.9.10. IP Resources . . . . . . . . . . . . . . . . . . . . . 9 75 3.9.11. AS Resources . . . . . . . . . . . . . . . . . . . . . 10 76 4. Resource Certificate Revocation List Profile . . . . . . . . . 10 77 4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 4.2. Issuer Name . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.3. This Update . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.4. Next Update . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 11 82 4.6. Revoked Certificate List . . . . . . . . . . . . . . . . . 11 83 4.6.1. Serial Number . . . . . . . . . . . . . . . . . . . . 11 84 4.6.2. Revocation Date . . . . . . . . . . . . . . . . . . . 11 85 4.7. CRL Extensions . . . . . . . . . . . . . . . . . . . . . . 11 86 4.7.1. Authority Key Identifier . . . . . . . . . . . . . . . 11 87 4.7.2. CRL Number . . . . . . . . . . . . . . . . . . . . . . 12 88 5. Resource Certificate Request Profile . . . . . . . . . . . . . 12 89 5.1. Resource Certificate Request Template Fields . . . . . . . 12 90 5.2. Resource Certificate Request Control Fields . . . . . . . 15 91 6. Resource Certificate Validation . . . . . . . . . . . . . . . 16 92 6.1. Trust Anchors for Resource Certificates . . . . . . . . . 16 93 6.2. Resource Extension Validation . . . . . . . . . . . . . . 17 94 6.3. Resource Certificate Path Validation . . . . . . . . . . . 17 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 97 9. Normative References . . . . . . . . . . . . . . . . . . . . . 19 98 Appendix A. Example Resource Certificate . . . . . . . . . . . . 20 99 Appendix B. Example Certificate Revocation List . . . . . . . . . 21 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 101 Intellectual Property and Copyright Statements . . . . . . . . . . 23 103 1. Introduction 105 This document defines a profile for X.509 certificates for use in the 106 context of Resources Certificates. Resource Certificates are X.509 107 certificates that conform to this profile that convey the authority 108 of a subject to be the entity that has the "right-to-use" a listed 109 set of IP addresses and Autonomous Numbers. 111 A Resource Certificate describes an action by an Issuer that binds a 112 list of IP address blocks and AS numbers to the Subject of a 113 certificate, identified by the unique association of the Subject's 114 private key with the public key contained in the Resource 115 Certificate. 117 In the context of the public Internet it is intended that Resource 118 Certificates are used in a manner that is aligned to the public 119 number resource distribution function, such that when a number 120 resource is allocated or assigned by a Registry to a receiving 121 entity, then this allocation is described by a Resource Certificate 122 issued by the Registry with a subject corresponding to the entity 123 that is the recipient of this assignment or allocation. Validation 124 of a certificate can be undertaken by creating a valid issuer - 125 subject chain from the trust anchor allocation authorities to the 126 certificate. 128 Resource Certificates may be used in the context of secure inter- 129 domain routing protocols to convey a right-to-use of an IP number 130 resource that is being passed within the routing protocol, to verify 131 legitimacy and correctness of routing information. Related use 132 contexts include validation of access to Internet Routing Registries 133 for nominated routing objects, validation of routing requests, and 134 detection of potential unauthorized used of IP addresses. 136 This document defines the fields that are used in a valid Resource 137 Certificate that MUST be followed. Relying Parties SHOULD check that 138 a Resource Certificate conforms to this profile as a necessary 139 condition of validation of a Resource Certificate. 141 1.1. Terminology 143 It is assumed that the reader is familiar with the terms and concepts 144 described in "Internet X.509 Public Key Infrastructure Certificate 145 and Certificate Revocation List (CRL) Profile" [RFC3280], "X.509 146 Extensions for IP Addresses and AS Identifiers" [RFC3779], "Internet 147 Protocol" [RFC0791], "Internet Protocol Version 6 (IPv6) Addressing 148 Architecture" [RFC4291], "Internet Registry IP Allocation Guidelines" 149 [RFC2050], and related regional Internet registry address management 150 policy documents. 152 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119. 156 2. Describing Resources in Certificates 158 This framework for describing an association between the subject of a 159 certificate and the resources currently under the subject's current 160 control is described in [RFC3779]. It is noted that the RFC's 161 description of this extension as a "right to use" is consistent with 162 the assertion that the resources are "under the subject's current 163 control." 165 There are three aspects of this extension that are noted here: 167 1. RFC 3779 notes that this resource extension SHOULD be a CRITICAL 168 extension to the X.509 Certificate. This Resource Certificate 169 profile further defines that the use of this certificate 170 extension MUST be used and MUST be marked as CRITICAL. 172 2. RFC 3779 defines a canonical form of describing a resource set, 173 with maximal spanning ranges and maximal spanning prefix masks as 174 appropriate. All valid certificates in this certificate resource 175 framework MUST use this canonical form of resource description 177 3. A test of the resource extension in the context of certificate 178 unique value token within the context of certificates issued by 179 the validity includes the first condition that the resources 180 described in the Issuer's resource extension must encompass those 181 of the Subject's resource extension. In this context "encompass" 182 allows for the Issuer's resource set to be the same as, or a 183 strict superset of, any subject's resource set. Certificate 184 validity also includes a second condition that no two or more 185 certificates issued by a single Issuer to two or more different 186 Subjects have a non-null intersection of resources. In other 187 words an Issuer can certify at most one unique Subject as the 188 unique current controller of any particular resource. 190 This implies that a test of certificate validity implies that there 191 exists a set of valid certificates in an issuer-subject chain from 192 one, and only one, trust anchor to the certificate in question, and 193 that the resource extensions from the trust anchor to the certificate 194 form a sequence of encompassing relationships. 196 3. Resource Certificate Fields 198 A valid X.509 / PKIX Resource Certificate contains the fields listed 199 in the following sections. Unless specifically noted as being 200 OPTIONAL, all the fields listed here MUST be present, and any other 201 field MUST NOT appear in a conforming Resource Certificate. Where a 202 field value is specified here this value MUST be used in conforming 203 Resource Certificates. 205 3.1. Version 207 Resource Certificates are X.509 Version 3 certificates. This field 208 MUST be present, and the Version MUST be 3 (value is 2). 210 3.2. Serial number 212 The serial number value is a positive integer that is unique per 213 Issuer. This field MUST be present in Resource Certificates. 215 3.3. Signature Algorithm 217 This field describes the algorithm used to compute the signature on 218 this certificate. This profile uses SHA-256 with RSA. This field 219 MUST be present and MUST use this value. 221 3.4. Issuer 223 This field identifies the entity that has signed and issued the 224 certificate. The value of this field is an X.500 name. For a Root 225 Trust Anchor this name is a self-selected name using only the Common 226 Name (CN) X.500 name field. For a subordinate certificate this name 227 MUST be the same name as the Subject name field on the 'parent' 228 certificate. This field MUST be present. 230 3.5. Subject 232 This field identifies the entity to whom the resource has been 233 allocated / assigned. The value of this field is an X.500 name. 235 In this profile the subject name is defined by the Issuer. All 236 immediate subordinate certificates issued by this Subject MUST use an 237 Issuer name that is identical to this Subject name. 239 This field MUST be present. 241 3.6. Valid From 243 The starting time at which point the certificate is valid. In this 244 profile the "Valid From" time is no later than the time of 245 certificate generation. As per Section 4.1.2.5 of RFC 3280, CAs 246 conforming to this profile MUST always encode the certificate's 247 "Valid From" date through the year 2049 as UTCTime, and dates in 2050 248 or later MUST be encoded as GeneralizedTime. These two time formats 249 are defined in [RFC3280]. This field MUST be present. 251 3.7. Valid To 253 The Valid To time is the date and time at which point in time the 254 certificate's validity ends. It represents the anticipated lifetime 255 of the resource allocation / assignment arrangement between the 256 Issuer and the Subject. As per Section 4.1.2.5 of RFC 3280, CAs 257 conforming to this profile MUST always encode the certificate's 258 "Valid To" date through the year 2049 as UTCTime, and dates in 2050 259 or later MUST be encoded as GeneralizedTime. These two time formats 260 are defined in [RFC3280]. This field MUST be present. 262 3.8. Subject Public Key Info 264 This field specifies the subject's public key and the algorithm with 265 which the key is used. The public key algorithm MUST be RSA and the 266 Modulus must be no less than 1024 bits in length. This field MUST be 267 present. 269 3.9. Resource Certificate Version 3 Extension Fields 271 As noted in Section 4.2 of [RFC3280], each extension in a certificate 272 is designated as either critical or non-critical. A certificate 273 using system MUST reject the certificate if it encounters a critical 274 extension it does not recognize; however, a non-critical extension 275 MAY be ignored if it is not recognized [RFC3280]. 277 The following X.509 V3 extensions MUST be present in a conforming 278 Resource Certificate. 280 3.9.1. Basic Constraints 282 The basic constraints extension identifies whether the subject of the 283 certificate is a CA and the maximum depth of valid certification 284 paths that include this certificate. 286 The Issuer determines whether the SubjectType CA bit is set. If this 287 bit is set, then it indicates that the Subject is allowed to issue 288 resources certificates within this overall framework. 290 The Path Length Constraint is not specified in this profile and MUST 291 NOT be present. 293 The Basic Constraints extension field is a CRITICAL extension in the 294 Resource Certificate profile, and MUST be present. 296 3.9.2. Subject Key Identifier 298 The subject key identifier extension provides a means of identifying 299 certificates that contain a particular public key. To facilitate 300 certification path construction, this extension MUST appear in all 301 Resource Certificates. 303 The value of the subject key identifier MUST be the value placed in 304 the key identifier field of the Authority Key Identifier extension of 305 certificates issued by the subject of this certificate. 307 The Subject Key Identifier is composed of the 160-bit SHA-1 hash of 308 the value of the ASN.1 bit string of the subject public key (exponent 309 and modulus), excluding the tag, length, and number of unused bits). 311 3.9.3. Authority Key Identifier 313 This field contains a hash of the Issuer's public key. The hash 314 algorithm is SHA-1 (160) applied to the ASN.1 bit string of the 315 Issuer public key (exponent and modulus), excluding the tag, length 316 and number of unused bits) ([RFC3280], Section 4.2.1.2). This field 317 MUST be present. 319 3.9.4. Key Usage 321 This describes the purpose of the certificate. This is a CRITICAL 322 extension, and the field MUST be present. 324 The permissions permitted in this profile are Certificate signing and 325 CRL signing if the Issuer permits the Subject to issue subordinate 326 certificates. 328 3.9.5. CRL Distribution Points 330 This field (CRLDP) identifies the location(s) of the CRL(s) 331 associated with certificates issued by this Issuer. This profile 332 uses a URI form of object identification. The preferred URI access 333 mechanism is a single "rsync" URL that references a single inclusive 334 CRL for each issuer. 336 This field MUST be present. 338 3.9.6. Authority Information Access 340 This field (AIA) identifies the location of all certificates that are 341 issued by this Issuer. This profile uses a URI form of object 342 identification. The preferred URI access mechanisms is "rsync". 344 This field MUST be present. 346 3.9.7. Subject Information Access 348 This field (SIA) identifies the location of information and services 349 relating to the subject of the certificate in which the SIA extension 350 appears. Where the Subject is a CA for Resource Certificates this 351 information and service collection will include all current valid 352 certificates that have been issued by this subject. This profile 353 uses a URI form of location identification. The preferred URI access 354 mechanism is "rsync". 356 This field MUST be present. 358 3.9.8. Certificate Policies 360 This field MUST reference the Resource Certificate Policy, using the 361 OID Policy Identifier value of "1.3.6.1.5.5.7.14.2". This field MUST 362 be present and MUST contain only this value for Resource 363 Certificates. 365 The Resource Certificate Policy referenced by this OID MAY be 366 referenced by a CPS Pointer qualifier. 368 This field MUST be present. 370 3.9.9. Subject Alternate Name 372 This is an OPTIONAL field, and may contain a Common Name as supplied 373 by the subject in the Certificate Request. The Subject Alternative 374 Name Field has no significance in terms of use of the certificate to 375 validate assertions made by the Subject on in validation assertions 376 made by subordinate entities that rely on a trust chain that includes 377 the subject. 379 3.9.10. IP Resources 381 This field contains the list of IP address resources as per 382 [RFC3779]. Either IP Resources or AS Resources fields, or both, MUST 383 be present in all Resource Certificates. 385 This is a CRITICAL field. 387 3.9.11. AS Resources 389 This field contains the list of AS number resources as per [RFC3779]. 390 Either IP Resources or AS Resources fields, or both, MUST be present 391 in all Resource Certificates. 393 This is a CRITICAL field. 395 4. Resource Certificate Revocation List Profile 397 Resource Certificate Authorities (CA) MUST issue a Certificate 398 Revocation List (CRL). The CRL issuer is the CA, and no indirect 399 CRLs are supported in the scope of this profile. The scope of the 400 CRL in this profile MUST be "all certificates issued by this CA". 401 The contents of the CRL are a list of all unexpired certificates 402 issued by the CA that have been revoked by the CA. 404 This profile does not encompass the issuing of Delta CRLs, nor does 405 the profile encompass the issuance of multiple CRLs by a single CA. 407 The following fields are REQUIRED in a conforming CRL.No other CRL 408 fields are supported in this profile. Where two or more CRLs issued 409 by a single CA are present in a certificate repository the CRL with 410 the highest value of the "CRL Number" field supercedes all other 411 extant CRLs issued by this CA.. 413 4.1. Version 415 Resource Certificate Revocation Lists are Version 2 certificates (the 416 integer value of this field is 1). This field MUST be present. 418 4.2. Issuer Name 420 The value of this field is the X.500 name of the issuing CA who is 421 also the signer of the CRL, and is identical to the Issuer name in 422 the Resource Certificates. This field MUST be present. 424 4.3. This Update 426 This is the date and time that this CRL was issued. The value of 427 this field MUST be encoded as UTCTime for dates through the year 428 2049, and MUST be encoded as GeneralizedTime for dates in the year 429 2050 or later. This field MUST be present. 431 4.4. Next Update 433 This is the date and time by which the next CRL will be issued. The 434 value of this field MUST be encoded as UTCTime for dates through the 435 year 2049, and MUST be encoded as GeneralizedTime for dates in the 436 year 2050 or later. This field MUST be present. 438 4.5. Signature 440 This fields contains the algorithm used to sign this CRL. The 441 signature algorithm MUST be SHA-256 with RSA. This field MUST be 442 present. 444 4.6. Revoked Certificate List 446 When there are no revoked certificates, then the revoked certificate 447 list MUST be absent. 449 For each revoked resource certificate the following fields are used 450 in this profile. No CRL extensions are supported in this profile. 452 4.6.1. Serial Number 454 The Issuer's serial number of the revoked certificate. This field 455 MUST be present. 457 4.6.2. Revocation Date 459 The time the certificate was revoked. This time SHOULD NOT be a 460 future date. The value of this field MUST be encoded as UTCTime for 461 dates through the year 2049, and MUST be encoded as GeneralizedTime 462 for dates in the year 2050 or later. This field MUST be present. 464 4.7. CRL Extensions 466 The X.509 v2 CRL format allows extensions to be placed in a CRL. The 467 following extensions are supported in this profile. 469 4.7.1. Authority Key Identifier 471 The authority key identifier extension provides a means of 472 identifying the public key corresponding to the private key used to 473 sign a CRL. The syntax for this CRL extension is defined in section 474 4.2.1.1 of [RFC3280]. 476 Conforming CRL issuers MUST use the key identifier method (defined in 477 section 5.2.1 of [RFC3280], and MUST include this extension in all 478 CRLs issued. 480 4.7.2. CRL Number 482 The CRL number is a non-critical CRL extension which conveys a 483 monotonically increasing sequence number for a given CRL scope and 484 CRL issuer. This extension allows users to easily determine when a 485 particular CRL supersedes another CRL. The higher CRL Number value 486 supercedes all other CRLs issued by the CA within the scope of this 487 profile. CRL issuers conforming to this profile MUST include this 488 extension in all CRLs. 490 5. Resource Certificate Request Profile 492 This profile refines the specification in [RFC4211], as it relates to 493 Resource Certificates. A Certificate Request Message object, 494 formatted according to the Certificate Request Message Format (CRMF), 495 is passed to a Certificate Authority as the initial step in issuing a 496 certificate. 498 This request may be conveyed to the CA via a Registration Authority 499 (RA), acting under the direction of a Subject. 501 [There are no profile-based qualifications are noted regarding Proof- 502 of-Possession. This may be refined in subsequent iterations of this 503 draft.] 505 5.1. Resource Certificate Request Template Fields 507 This profile applies the following additional constraints to fields 508 that may appear in a Certificate Request Template: 510 Version 511 [RFC4211] indicates that this MUST be 2, if supplied. As Resource 512 Certificates are Version 3 certificates, this field MUST be 513 omitted in this profile. 515 SerialNumber 516 As per [RFC4211], this field is assigned by the CA and MUST be 517 omitted in this profile. 519 SigningAlgorithm 520 As per [RFC4211], this field is assigned by the CA and MUST be 521 omitted in this profile. 523 Issuer 524 This field is assigned by the CA and MUST be omitted in this 525 profile. 527 Validity 528 This field MAY be omitted. If omitted, the CA will assign a 529 ValidityFrom date based on the certificate issue date and a 530 ValidityTo date based on the CA's business rule. If this field is 531 not omitted then at least one of notBefore and notAfter MUST be 532 specified. 534 notBefore 535 This field will be mapped to the ValidityFrom certificate 536 field. If this field is later than the CA's business rule for 537 certificate issuance, then the request MAY NOT be honored. 539 notAfter 540 This field will be mapped to the ValidityTo certificate field. 541 Values of notAfter prior to the current time MUST be considered 542 as an invalid Certificate Request. If this field is later than 543 the CA's business rule for certificate issuance then issued 544 certificate MAY use a ValidityTo date as determined by the CA's 545 business rule for certificate issuance. 547 Subject 548 As the subject name is assigned by the CA, this field MAY be 549 omitted, in which case the subject name will be generated by the 550 CA. If specified, the CA SHOULD consider this as the subject's 551 suggestion, but the CA is NOT bound to honour this suggestion. 553 PublicKey 554 This field MUST be present. 556 This profile applies the following additional constraints to X509 v3 557 extension fields that may appear in a Certificate Request: 559 BasicConstraints 560 If this is omitted then this field is assigned by the CA. 562 The Path Length Constraint is not supported in this Resource 563 Certificate Profile, and this field MUST be omitted in this 564 profile. 566 The CA MAY honour the SubjectType CA bit set to on. If this bit 567 is set, then it indicates that the Subject is allowed to issue 568 resources certificates within this overall framework. 570 The CA MAY honour the SubjectType CA bit set of off (End Entity 571 certificate request). 573 SubjectKeyIdentifier 574 This field is assigned by the CA and MUST be omitted in this 575 profile. 577 AuthorityKeyIdentifier 578 This field is assigned by the CA and MUST be omitted in this 579 profile. 581 KeyUsage 582 The CA MAY honor KeyUsage extensions of CertificateSigning and 583 CRLSigning if present, as long as this is consistent with the 584 BasicConstraints SubjectType subfield, when specified. 586 CRLDistributionPoints 587 This field MAY be honoured by the CA on the condition that the CA 588 issues a certificate with the BasicConstraints SubjectType CA bit 589 set and the KeyUsage set to CertificateSigning and CRLSigning. 591 If specified, this field contains a URI of the form of a single 592 "rsync" URL that references a single inclusive CRL that will be 593 published by the subject for subordinate certificates, and MUST be 594 honoured by the CA. 596 If this field is omitted and KeyUsage is set to CertificateSigning 597 then the CA MUST generate a CRLDistributionPoint URL within the 598 repository hierarchy administered by the CA. 600 AuthorityInformationAccess 601 This field is assigned by the CA and MUST be omitted in this 602 profile. 604 SubjectInformationAccess 605 This field MAY be honoured by the CA on the condition that the CA 606 issues a certificate with the BasicConstraints SubjectType CA bit 607 set and the KeyUsage set to CertificateSigning and CRLSigning. 609 If specified, this field contains a URI of the form of a single 610 "rsync" URL that references a single publication point that will 611 be used by the subject for all certificates that published by the 612 subject for subordinate certificates, and MUST be honoured by the 613 CA. 615 If this field is omitted and KeyUsage is set to CertificateSigning 616 then the CA MUST generate an SIA URL within the repository 617 hierarchy administered by the CA. 619 Certificate Policies 620 This field is assigned by the CA and MUST be omitted in this 621 profile. 623 SubjectAlternateName 624 This field MAY be present, and the CA SHOULD use this as the 625 SubjectAltName in the issued Certificate. 627 IPResources 628 This field is assigned by the CA and MUST be omitted in this 629 profile. 631 ASResources 632 This field is assigned by the CA and MUST be omitted in this 633 profile. 635 With the exception of the publicKey field, the CA is permitted to 636 alter any requested field. 638 5.2. Resource Certificate Request Control Fields 640 The following control fields are supported in this profile: 642 Authenticator Control 643 It is noted that the intended model of authentication of the 644 subject in a long term one, and the advice as offered in [RFC4211] 645 is that the Authenticator Control field be used. 647 [The method of generation and authentication of this field is to 648 be specified. The desirable properties include the ability to 649 validate the subject and the authenticity of the provided public 650 key.] 652 Resource Class 653 The profile defines an additional control for Resource Certificate 654 Requests, namely a Resource Class control. 655 The Subject MUST specify a Resource Class value as specified by 656 the CA to which the request refers. The CA will issue a 657 certificate with the IPAddress andASNumber resources that match 658 the subject's right-of-use of these resources with the class of 659 resources specified by the Resource Class control value. 661 6. Resource Certificate Validation 663 This section describes the Resource Certificate validation model. 664 This refines the generic procedure described in [RFC3280]: 666 To meet this goal, the path validation process verifies, among other 667 things, that a prospective certification path (a sequence of n 668 certificates) satisfies the following conditions: 670 1. for all x in {1, ..., n-1}, the subject of certificate x is the 671 issuer of certificate x+1; 673 2. certificate 1 is issued by the trust anchor; 675 3. certificate n is the certificate to be validated; and 677 4. for all x in {1, ..., n}, the certificate was valid at the time 678 in question. 680 6.1. Trust Anchors for Resource Certificates 682 The trust model used in the resource certificate framework in the 683 context of validation of assertions of public number resources in 684 public-use contexts is a top-down delegated CA model that mirrors the 685 delegation of resources from a registry distribution point to the 686 entities that are the direct recipients of these resources. Within 687 the trust model these recipient entities may, in turn, operate a 688 registry and perform further allocations or assignments. This is a 689 strict hierarchy, in that any number resource and a corresponding 690 recipient entity has only one 'parent' issuing registry for that 691 number resource (i.e. there is always a unique parent entity for any 692 resource and corresponding entity), and that the issuing registry is 693 not a direct or indirect subordinate recipient entity of the 694 recipient entity in question (i.e. no loops in the hierarchy). The 695 only exception to the "no loop" condition are the nominated trust 696 anchors, where a self-signed certificate is issued. 698 At the time of preparing this draft there are proposed to be multiple 699 roots of this public number resource hierarchy, corresponding to 700 multiple trust anchors. These trust anchors are the self-signed 701 certificates that are issued by the Regional Internet Registries. 702 Each self-signed certificate issued by a RIR contains a resource set 703 that describes the resources where the RIR is administratively 704 responsible. There MUST NOT be overlap of resources in the IP 705 resource extensions across the collection of RIR self-signed 706 certificates. This implies that a validation path for a valid 707 certificate will terminate in a single trust anchor. 709 Cross-certification of these trust anchors, where one trust anchor 710 entity issues a certificate with a subject of another trust anchor is 711 not seen as providing any further substance to the integrity or ease 712 of validation in this trust model, so cross-certification is not used 713 in the trust anchor structure for this Resource Certificate 714 Framework. 716 The adoption of a single trust anchor as a unique distinguished root 717 of this certificate hierarchy is a potential future option here, and 718 within the proposed framework some care has been taken not to 719 preclude the potential for a single distinguished root for this 720 certificate framework that could issue a certificate to each RIR with 721 a resource extension that matches the resource sets that fall under 722 the administrative responsibility of each RIR. 724 6.2. Resource Extension Validation 726 The IP resource extension definition [RFC3779] defines a CRITICAL 727 extensions for Internet number resources. These are ASN.1 encoded 728 representations of the IPv4 and IPv6 address range (either as a 729 prefix/length, or start-end pair) and the AS number set. 731 Valid Resource Certificates MUST have a valid IP resource extension. 732 In order to validate a Resource Certificate the resource extension 733 must also be validated. This validation process relies on 734 definitions of comparison of resource sets: 736 more specific Given two IP address or AS number contiguous ranges, A 737 and B, A is "more specific" than B if range B includes all IP 738 addresses or AS numbers described by range A, and if range B is 739 larger than range A. 741 equal Given two IP address or AS number contiguous ranges, A and B, 742 A is "equal" to B if range A describes precisely the same 743 collection of IP addresses or AS numbers as described by range B. 745 Validation of a certificate's resource extension in the context of an 746 ordered certification path of {1, ..., n}, each of the contiguous 747 resource sets of IP addresses and AS Numbers described in certificate 748 x are more specific or equal to the resources described in 749 certificate x+1. 751 6.3. Resource Certificate Path Validation 753 Validation of signed resource data using a target resource 754 certificate consists of assembling an ordered sequence (or 755 'Certificate Path') of certificates ({1,2,...n} where '1' is a trust 756 anchor, and 'n' is the target certificate) verifying that all of the 757 following conditions hold: 759 1. The certificate can be verified using the Issuer's public key and 760 the signature algorithm 762 2. The current time lies within the certificate's Validity From and 763 TO values. 765 3. The certificate contains all fields that MUST be present and 766 contains field values as specified in this profile for all field 767 values that MUST be present. 769 4. No field value that MUST NOT be present is present in the 770 certificate. 772 5. The Issuer has not revoked the certificate by placing the 773 certificate's serial number on the Issuer's current Certificate 774 Revocation List, and the CRL is itself valid. 776 6. That the resource extension data is equal to or more specific 777 than the resource extension data contained in a valid certificate 778 where this Issuer is the Subject (the previous certificate in the 779 ordered sequence) 781 7. The Certificate Path originates at a trust anchor, and there 782 exists a signing chain across the Certificate Path where the 783 Subject of Certificate x in the Certificate Path matches the 784 Issuer in Certificate x+1 in the Certificate Path. 786 Validation of a certificate may perform these tests in any chosen 787 order. 789 A Resource Certificate may have a number of potential parent 790 certificates, where a potential parent certificate is one where the 791 subject name matches the issuer name of the resource certificate. A 792 candidate parent certificate is any member of the parent certificate 793 set where the resource extension validity constraint is satisfied, 794 and a valid candidate parent certificate is any candidate parent 795 certificate that also matches validity conditions 1 through 6. A 796 valid parent certificate is a valid candidate parent certificate that 797 also matches validity condition 7. 799 Certificates and CRLs used in this process may be found on a single 800 repository, maintained by a regular top-down walk from the Root Trust 801 Anchors via Issuer certificates and their SIA fields as forward 802 pointers, plus the CRLDP. Alternatively, validation may be performed 803 using a bottom-up process with on-line certificate access using the 804 AIA and CRLDP pointers to guide the certificate retrieval process. 806 There exists the possibility of encountering certificate paths that 807 are arbitrarily long, or attempting to generate paths with loops as 808 means of creating a potential DOS attack on a certificate validator. 809 Some further heuristics may be required to halt the validation 810 process in order to avoid some of the issues associated with attempts 811 to validate such structures. It is suggested that implementations of 812 Resource Certificate validation MAY halt with a validation failure if 813 the certificate path length exceeds a pre-determined configuration 814 parameter. 816 In the context of Resource Certificates that are generated in respect 817 of public resources and with the framework of the associated resource 818 distribution process, it is suggested that this configuration 819 parameter of maximum certificate path length be set to a value of 820 100. (There is no particular reason for suggesting this value other 821 than the observation that it appears to be comfortably longer than 822 any real distribution chain for public number resources, without 823 being too long so as to pose potential DOS concerns for relying 824 parties performing a validation operation.) 826 7. Security Considerations 828 [to be completed] 830 8. IANA Considerations 832 [An OID for a resource class option in a certificate request may need 833 to be defined.] 835 9. Normative References 837 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 838 September 1981. 840 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and 841 J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 842 BCP 12, RFC 2050, November 1996. 844 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 845 X.509 Public Key Infrastructure Certificate and 846 Certificate Revocation List (CRL) Profile", RFC 3280, 847 April 2002. 849 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 850 Addresses and AS Identifiers", RFC 3779, June 2004. 852 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 853 Certificate Request Message Format (CRMF)", RFC 4211, 854 September 2005. 856 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 857 Architecture", RFC 4291, February 2006. 859 Appendix A. Example Resource Certificate 861 The following is an example Resource Certificate. 863 Certificate Name: UDkyh1nUjIjk5_WpdkZMh3KuvYo-25f7.crt 865 Data: 866 Version: 3 867 Serial: 9719 (0x25f7) 868 Signature Algorithm: 869 Hash: SHA256, Encryption: RSA 870 Issuer: CN=APNIC-AP-IANA 871 Validity: 872 Not Before: Fri May 12 05:37:43 2006 GMT 873 Not After: Thu Aug 10 05:37:43 2006 GMT 874 Subject: CN=FC9B85ADDF5B 875 Subject Public Key Info: 876 Public Key Algorithm: rsaEncryption 877 RSA Public Key: (1024 bit) 878 Modulus (1024 bit): 879 00:f2:e5:63:d6:e3:89:45:47:02:13:90:b7:e5:39: 880 a3:f0:8c:3b:27:0d:d1:90:92:46:9b:45:d0:52:34: 881 f1:7c:c7:34:9f:be:d0:41:18:ab:35:43:62:89:2e: 882 3e:32:ab:01:e2:86:76:2a:44:83:49:4c:83:02:b4: 883 0c:2a:b0:b2:82:c6:35:24:7b:16:7a:35:42:36:15: 884 18:50:fe:8b:7f:c9:04:18:69:6b:ed:59:0d:61:ea: 885 20:ef:cd:19:30:9f:ce:b8:4a:f5:fb:ad:81:42:ab: 886 57:72:0c:47:b0:d8:30:c0:0c:5b:52:dc:aa:94:95: 887 3e:fe:44:ac:d5:b0:f4:d5:cb 888 Exponent: 65537 (0x10001) 889 X509v3 extensions: 890 Basic Constraints: 891 CA:TRUE 892 Subject Key Identifier: 893 keyid: 50:39:32:87:59:D4:8C:88:E4:E7:F5:A9: 894 76:46:4C:87:72:AE:BD:8A 895 Authority Key Identifier: 896 keyid: 19:54:CD:F2:81:C6:4E:31:09:6D:3A:15: 897 E6:88:39:30:21:A6:56:73 898 Key Usage: critical 899 Certificate Sign, CRL Sign 900 CRL Distribution Points: 901 URI:rsync://rsync.apnic.net/repository/ 902 pvpjvwUeQix2e54X8fGbhmdYMo0/ 903 GVTN8oHGTjEJbToV5og5MCGmVnM/ 904 GVTN8oHGTjEJbToV5og5MCGmVnM.crl 905 Authority Information Access: 906 CA Issuers - URI:rsync://rsync.apnic.net/repository/ 907 pvpjvwUeQix2e54X8fGbhmdYMo0/ 908 GVTN8oHGTjEJbToV5og5MCGmVnM 909 Subject Information Access: 910 CA Issuers - URI:rsync://rsync.apnic.net/repository/ 911 pvpjvwUeQix2e54X8fGbhmdYMo0/ 912 GVTN8oHGTjEJbToV5og5MCGmVnM/ 913 UDkyh1nUjIjk5_WpdkZMh3KuvYo 914 Certificate Policies: critical 915 Policy: 1.3.6.1.5.5.7.14.2 916 ipAddrBlock: critical 917 192.0.0.0/24 918 autonomousSysNum: critical 919 64512 920 Subject Alternative Name: 921 DirName:/CN= 923 Signature: 924 72:27:9c:bc:a8:7f:c0:f0:27:62:a1:1f:55:b3:c7:b1:31:c9:fc: 925 42:84:71:30:3b:0d:c0:d6:ad:79:b1:f6:1d:14:e8:f3:0f:f3:dd: 926 40:3d:ae:28:a6:33:96:b6:d3:7d:d2:f3:ac:d3:8e:d4:2e:ad:ab: 927 71:4d:05:74:20:ed:bc:e3:bd:85:7f:af:8b:70:3e:b8:90:b6:2d: 928 a5:e3:9d:2a:c8:a9:9b:73:3c:03:43:d2:b8:d2:4e:68:34:eb:db: 929 3c:44:eb:eb:1e:3b:03:d9:3b:e0:64:a6:31:90:9b:2c:4a:26:8e: 930 0e:36:4c:ee:c8:e9:29:6b:78:61:87:05:e2:f9 932 Appendix B. Example Certificate Revocation List 934 The following is an example Certificate Revocation List. 936 Certificate Name: GVTN8oHGTjEJbToV5og5MCGmVnM.crl 938 Data: 939 Version: 2 940 Issuer: CN=APNIC-AP-IANA 941 Effective Date: Fri May 12 05:37:43 2006 GMT 942 Next Update: Fri May 26 05:37:43 2006 GMT 943 Signature algorithn 944 Hash: SHA256, Encryption: RSA 945 CRL V2 Extensions: 946 Authority Key Identifier: 947 Keyid: 19:54:cd:f2:81:c6:4e:31:09:6d:3a:15: 948 e6:88:39:30:21:a6:56:73 949 Certificate Issuer: 950 CN=APNIC-AP-IANA 951 Certificate Serial Number: 1b 952 CRL Number: 1097 953 Revocation List: 954 Revoked Certificates 955 Serial Number: 0b 956 Revocation Date: Mon May 8 05:10:19 2006 GMT 957 Serial Number: 0c 958 Revocation Date: Mon May 8 05:10:19 2006 GMT 960 Authors' Addresses 962 Geoff Huston 963 Asia Pacific Network Information Centre 965 Email: gih@apnic.net 966 URI: http://www.apnic.net 968 Robert Loomans 969 Asia Pacific Network Information Centre 971 Email: robertl@apnic.net 972 URI: http://www.apnic.net 974 George Michaelson 975 Asia Pacific Network Information Centre 977 Email: ggm@apnic.net 978 URI: http://www.apnic.net 980 Full Copyright Statement 982 Copyright (C) The Internet Society (2006). 984 This document is subject to the rights, licenses and restrictions 985 contained in BCP 78, and except as set forth therein, the authors 986 retain all their rights. 988 This document and the information contained herein are provided on an 989 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 990 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 991 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 992 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 993 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 994 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 996 Intellectual Property 998 The IETF takes no position regarding the validity or scope of any 999 Intellectual Property Rights or other rights that might be claimed to 1000 pertain to the implementation or use of the technology described in 1001 this document or the extent to which any license under such rights 1002 might or might not be available; nor does it represent that it has 1003 made any independent effort to identify any such rights. Information 1004 on the procedures with respect to rights in RFC documents can be 1005 found in BCP 78 and BCP 79. 1007 Copies of IPR disclosures made to the IETF Secretariat and any 1008 assurances of licenses to be made available, or the result of an 1009 attempt made to obtain a general license or permission for the use of 1010 such proprietary rights by implementers or users of this 1011 specification can be obtained from the IETF on-line IPR repository at 1012 http://www.ietf.org/ipr. 1014 The IETF invites any interested party to bring to its attention any 1015 copyrights, patents or patent applications, or other proprietary 1016 rights that may cover technology that may be required to implement 1017 this standard. Please address the information to the IETF at 1018 ietf-ipr@ietf.org. 1020 Acknowledgment 1022 Funding for the RFC Editor function is provided by the IETF 1023 Administrative Support Activity (IASA).