idnits 2.17.1 draft-ietf-sidr-res-certs-12.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, updated by RFC 4748 on line 1887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1898. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1905. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1911. 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (September 6, 2008) is 5709 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) -- Looks like a reference, but probably isn't: '0' on line 1694 -- Looks like a reference, but probably isn't: '1' on line 1681 == Missing Reference: 'TBD' is mentioned on line 1828, but not defined ** Obsolete normative reference: RFC 2050 (Obsoleted by RFC 7020) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rpki-manifests-00 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 10 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: March 10, 2009 APNIC 6 September 6, 2008 8 A Profile for X.509 PKIX Resource Certificates 9 draft-ietf-sidr-res-certs-12 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 March 10, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines a standard profile for X.509 certificates for 43 the purposes of supporting validation of assertions of "right-of-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 issued 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 13 73 3.9.9. IP Resources . . . . . . . . . . . . . . . . . . . . . 13 74 3.9.10. AS Resources . . . . . . . . . . . . . . . . . . . . . 13 75 4. Resource Certificate Revocation List Profile . . . . . . . . . 13 76 4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 4.2. Issuer Name . . . . . . . . . . . . . . . . . . . . . . . 14 78 4.3. This Update . . . . . . . . . . . . . . . . . . . . . . . 14 79 4.4. Next Update . . . . . . . . . . . . . . . . . . . . . . . 14 80 4.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 14 81 4.6. Revoked Certificate List . . . . . . . . . . . . . . . . . 15 82 4.6.1. Serial Number . . . . . . . . . . . . . . . . . . . . 15 83 4.6.2. Revocation Date . . . . . . . . . . . . . . . . . . . 15 84 4.7. CRL Extensions . . . . . . . . . . . . . . . . . . . . . . 15 85 4.7.1. Authority Key Identifier . . . . . . . . . . . . . . . 15 86 4.7.2. CRL Number . . . . . . . . . . . . . . . . . . . . . . 15 87 5. Resource Certificate Request Profile . . . . . . . . . . . . . 16 88 5.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 16 89 5.1.1. PKCS#10 Resource Certificate Request Template 90 Fields . . . . . . . . . . . . . . . . . . . . . . . . 16 91 5.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 17 92 5.2.1. CRMF Resource Certificate Request Template Fields . . 17 93 5.2.2. Resource Certificate Request Control Fields . . . . . 18 94 5.3. Certificate Extension Attributes in Certificate 95 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 6. Resource Certificate Validation . . . . . . . . . . . . . . . 21 97 6.1. Resource Extension Validation . . . . . . . . . . . . . . 21 98 6.2. Resource Certification Path Validation . . . . . . . . . . 22 99 6.3. Trust Anchors for Resource Certificates . . . . . . . . . 24 100 6.3.1. Distribution Format of Nominated Trust Anchor 101 Material . . . . . . . . . . . . . . . . . . . . . . . 25 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 104 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 105 10. Draft Review Notes . . . . . . . . . . . . . . . . . . . . . . 28 106 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 107 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 108 11.2. Informative References . . . . . . . . . . . . . . . . . . 31 109 Appendix A. Example Resource Certificate . . . . . . . . . . . . 32 110 Appendix B. Example Certificate Revocation List . . . . . . . . . 34 111 Appendix C. Cryptographic Message Syntax Profile for RPKI 112 Trust Anchor Material . . . . . . . . . . . . . . . . 35 113 C.1. Signed-Data ContentType . . . . . . . . . . . . . . . . . 35 114 C.1.1. encapContentInfo . . . . . . . . . . . . . . . . . . . 36 115 C.1.2. signerInfos . . . . . . . . . . . . . . . . . . . . . 37 116 C.2. RTA Validation . . . . . . . . . . . . . . . . . . . . . . 39 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 118 Intellectual Property and Copyright Statements . . . . . . . . . . 42 120 1. Introduction 122 This document defines a standard profile for X.509 certificates 123 [X.509] for use in the context of certification of IP Addresses and 124 AS Numbers. Such certificates are termed here "Resource 125 Certificates." Resource Certificates are X.509 certificates that 126 conform to the PKIX profile [RFC5280], and also conform to the 127 constraints specified in this profile. Resource Certificates attest 128 that the issuer has granted the subject a "right-of-use" for a listed 129 set of IP addresses and Autonomous System numbers. 131 A Resource Certificate describes an action by a certificate issuer 132 that binds a list of IP Address blocks and AS Numbers to the subject 133 of the issued certificate. The binding is identified by the 134 association of the subject's private key with the subject's public 135 key contained in the Resource Certificate, as signed by the private 136 key of the certificate's issuer. 138 In the context of the public Internet, and the use of public number 139 resources within this context, it is intended that Resource 140 Certificates are used in a manner that is explicitly aligned to the 141 public number resource distribution function. Specifically, when a 142 number resource is allocated or assigned by a number registry to an 143 entity, this allocation is described by an associated Resource 144 Certificate. This certificate is issued by the number registry, and 145 the subject's public key that is being certified by the issuer 146 corresponds to the public key part of a public / private key pair 147 that was generated by the same entity who is the recipient of the 148 number assignment or allocation. A critical extension to the 149 certificate enumerates the IP Resources that were allocated or 150 assigned by the issuer to the entity. In the context of the public 151 number distribution function, this corresponds to a hierarchical PKI 152 structure, where Resource Certificates are only issued in one 153 'direction' and there is a single unique path of certificates from a 154 certification authority operating at the apex of a resource 155 distribution hierarchy to a valid certificate. 157 Validation of a Resource Certificate in such a hierarchical PKI can 158 be undertaken by establishing a valid issuer-subject certificate 159 chain from a certificate issued by a trust anchor certification 160 authority to the certificate [RFC4158], with the additional 161 constraint of ensuring that each subject's listed resources are fully 162 encompassed by those of the issuer at each step in the issuer-subject 163 certificate chain. 165 Resource Certificates may be used in the context of the operation of 166 secure inter-domain routing protocols to convey a right-of-use of an 167 IP number resource that is being passed within the routing protocol, 168 allowing relying parties to verify legitimacy and correctness of 169 routing information. Related use contexts include validation of 170 Internet Routing Registry objects, validation of routing requests, 171 and detection of potential unauthorised use of IP addresses. 173 This profile defines those fields that are used in a Resource 174 Certificate that MUST be present for the certificate to be valid. 175 Relying Parties SHOULD check that a Resource Certificate conforms to 176 this profile as a requisite for validation of a Resource Certificate. 178 1.1. Terminology 180 It is assumed that the reader is familiar with the terms and concepts 181 described in "Internet X.509 Public Key Infrastructure Certificate 182 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 183 Extensions for IP Addresses and AS Identifiers" [RFC3779], "Internet 184 Protocol" [RFC0791], "Internet Protocol Version 6 (IPv6) Addressing 185 Architecture" [RFC4291], "Internet Registry IP Allocation Guidelines" 186 [RFC2050], and related regional Internet registry address management 187 policy documents. 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119. 193 2. Describing Resources in Certificates 195 The framework for describing an association between the subject of a 196 certificate and the resources currently under the subject's control 197 is described in [RFC3779]. 199 There are three aspects of this resource extension that are noted in 200 this profile: 202 1. RFC 3779 notes that a resource extension SHOULD be a CRITICAL 203 extension to the X.509 Certificate. This Resource Certificate 204 profile further specifies that the use of this certificate 205 extension MUST be used in all Resource Certificates and MUST be 206 marked as CRITICAL. 208 2. RFC 3779 defines a sorted canonical form of describing a resource 209 set, with maximal spanning ranges and maximal spanning prefix 210 masks as appropriate. All valid certificates in this profile 211 MUST use this sorted canonical form of resource description in 212 the resource extension field. 214 3. A test of the resource extension in the context of certificate 215 validity includes the condition that the resources described in 216 the immediate superior certificate in the PKI hierarchy (the 217 certificate where this certificate's issuer is the subject) has a 218 resource set (called here the "issuer's resource set") that must 219 encompass the resource set of the issued certificate. In this 220 context "encompass" allows for the issuer's resource set to be 221 the same as, or a strict superset of, any subject's resource set. 223 A test of certificate validity entails the identification of a 224 sequence of valid certificates in an issuer-subject chain (where the 225 subject field of one certificate appears as the issuer in the next 226 certificate in the sequence) from a trust anchor certification 227 authority to the certificate being validated, and that the resource 228 extensions in this certificate sequence from the trust anchor's 229 issued certificate to the certificate being validated form a sequence 230 of encompassing relationships in terms of the resources described in 231 the resource extension. 233 3. Resource Certificate Fields 235 A Resource Certificate is a valid X.509 v3 public key certificate, 236 consistent with the PKIX profile [RFC5280], containing the fields 237 listed in this section. Unless specifically noted as being OPTIONAL, 238 all the fields listed here MUST be present, and any other field MUST 239 NOT appear in a conforming Resource Certificate. Where a field value 240 is specified here this value MUST be used in conforming Resource 241 Certificates. 243 3.1. Version 245 Resource Certificates are X.509 Version 3 certificates. This field 246 MUST be present, and the Version MUST be 3 (i.e. the value of this 247 field is 2). 249 3.2. Serial number 251 The serial number value is a positive integer that is unique per 252 Issuer. 254 3.3. Signature Algorithm 256 This field describes the algorithm used to compute the signature on 257 this certificate. This profile specifies a minimum of SHA-256 with 258 RSA (sha256WithRSAEncryption), and allows for the use of SHA-384 or 259 SHA-512. Accordingly, the value for this field MUST be one of the 260 OID values { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 } [RFC4055]. 262 3.4. Issuer 264 This field identifies the entity that has signed and issued the 265 certificate. The value of this field is a valid X.501 name. 267 If the certificate is a subordinate certificate issued by virtue of 268 the "cA" bit set in the immediate superior certificate, then the 269 issuer name MUST correspond to the subject name as contained in the 270 immediate superior certificate. 272 This field MUST be non-empty. 274 3.5. Subject 276 This field identifies the entity to whom the resource has been 277 allocated / assigned. The value of this field is a valid X.501 name. 279 In this profile the subject name is determined by the issuer, and 280 each distinct entity certified by the issuer MUST be identified using 281 a subject name that is unique per issuer. 283 This field MUST be non-empty. 285 3.6. Valid From 287 The starting time at which point the certificate is valid. In this 288 profile the "Valid From" time SHOULD be no earlier than the time of 289 certificate generation. As per Section 4.1.2.5 of [RFC5280], 290 Certification Authorities (CAs) conforming to this profile MUST 291 always encode the certificate's "Valid From" date through the year 292 2049 as UTCTime, and dates in 2050 or later MUST be encoded as 293 GeneralizedTime. These two time formats are defined in [RFC5280]. 295 In this profile, it is valid for a certificate to have a value for 296 this field that pre-dates the same field value in any superior 297 certificate. However, it is not valid to infer from this information 298 that a certificate was, or will be, valid at any particular time 299 other than the current time. 301 3.7. Valid To 303 The Valid To time is the date and time at which point in time the 304 certificate's validity ends. It represents the anticipated lifetime 305 of the resource allocation / assignment arrangement between the 306 issuer and the subject. As per Section 4.1.2.5 of [RFC5280], CAs 307 conforming to this profile MUST always encode the certificate's 308 "Valid To" date through the year 2049 as UTCTime, and dates in 2050 309 or later MUST be encoded as GeneralizedTime. These two time formats 310 are defined in [RFC5280]. 312 In this profile, it is valid for a certificate to have a value for 313 this field that post-dates the same field value in any superior 314 certificate. However, it is not valid to infer from this information 315 that a certificate was, or will be, valid at any particular time 316 other than the current time. 318 CAs are typically advised against issuing a certificate with a 319 validity interval that exceeds the validity interval of the CA's 320 certificate that will be used to validate the issued certificate. 321 However, in the context of this profile, it is anticipated that a CA 322 may have valid grounds to issue a certificate with a validity 323 interval that exceeds the validity interval of the CA's certificate. 325 3.8. Subject Public Key Info 327 This field specifies the subject's public key and the algorithm with 328 which the key is used. The public key algorithm MUST be RSA, and, 329 accordingly, the OID for the public key algorithm is 330 1.2.840.113549.1.1.1. The key size MUST be a minimum size of 2048 331 bits. 333 It is noted that larger key sizes are computationally expensive for 334 both the CA and relying parties, indicating that care should be taken 335 when deciding to use larger than the minimum key size. 337 3.9. Resource Certificate Version 3 Extension Fields 339 As noted in Section 4.2 of [RFC5280], each extension in a certificate 340 is designated as either critical or non-critical. A certificate- 341 using system MUST reject the certificate if it encounters a critical 342 extension it does not recognise; however, a non-critical extension 343 MAY be ignored if it is not recognised [RFC5280]. 345 The following X.509 V3 extensions MUST be present in a conforming 346 Resource Certificate, except where explicitly noted otherwise. 348 3.9.1. Basic Constraints 350 The basic constraints extension identifies whether the subject of the 351 certificate is a CA and the maximum depth of valid certification 352 paths that include this certificate. 354 The issuer determines whether the "cA" boolean is set. If this bit 355 is set, then it indicates that the subject is allowed to issue 356 resources certificates within this overall framework (i.e. the 357 subject is permitted be a CA). 359 The Path Length Constraint is not specified in this profile and MUST 360 NOT be present. 362 The Basic Constraints extension field is a critical extension in the 363 Resource Certificate profile, and MUST be present when the subject is 364 a CA, and MUST NOT be present otherwise. 366 3.9.2. Subject Key Identifier 368 The subject key identifier extension provides a means of identifying 369 certificates that contain a particular public key. To facilitate 370 certification path construction, this extension MUST appear in all 371 Resource Certificates. This extension is non-critical. 373 The value of the subject key identifier MUST be the value placed in 374 the key identifier field of the Authority Key Identifier extension of 375 immediate subordinate certificates (all certificates issued by the 376 subject of this certificate). 378 The Key Identifier used here is the 160-bit SHA-1 hash of the value 379 of the DER-encoded ASN.1 bit string of the subject public key, as 380 described in Section 4.2.1.2 of [RFC5280]. 382 3.9.3. Authority Key Identifier 384 The authority key identifier extension provides a means of 385 identifying certificates that are signed by the issuer's private key, 386 by providing a hash value of the issuer's public key. To facilitate 387 path construction, this extension MUST appear in all Resource 388 Certificates. The keyIdentifier sub field MUST be present in all 389 Resource Certificates, with the exception of a CA who issues a "self- 390 signed" certificate. The authorityCertIssuer and 391 authorityCertSerialNumber sub fields MUST NOT be present. This 392 extension is non-critical. 394 The Key Identifier used here is the 160-bit SHA-1 hash of the value 395 of the DER-encoded ASN.1 bit string of the issuer's public key, as 396 described in Section 4.2.1.1 of [RFC5280]. 398 3.9.4. Key Usage 400 This describes the purpose of the certificate. This is a critical 401 extension, and it MUST be present. 403 In certificates issued to Certificate Authorities only the 404 keyCertSign and CRLSign bits are set to TRUE and MUST be the only 405 bits set to TRUE. 407 In end-entity certificates the digitalSignature bit MUST be set and 408 MUST be the only bit set to TRUE. 410 3.9.5. CRL Distribution Points 412 This field (CRLDP) identifies the location(s) of the CRL(s) 413 associated with certificates issued by this Issuer. This profile 414 uses the URI form of object identification. The preferred URI access 415 mechanism is a single RSYNC URI ("rsync://") [rsync] that references 416 a single inclusive CRL for each issuer. 418 In this profile the certificate issuer is also the CRL issuer, 419 implying at the CRLIssuer sub field MUST be omitted, and the 420 distributionPoint sub-field MUST be present. The Reasons sub-field 421 MUST be omitted. 423 The distributionPoint MUST contain general names, and MUST NOT 424 contain a nameRelativeToCRLIssuer. The type of the general name MUST 425 be of type URI. 427 In this profile, the scope of the CRL is specified to be all 428 certificates issued by this CA issuer using a given key pair. 430 The sequence of distributionPoint values MUST contain only a single 431 DistributionPointName set. The DistributionPointName set MAY contain 432 more than one URI value. An RSYNC URI MUST be present in the 433 DistributionPointName set, and reference the most recent instance of 434 this issuer's certificate revocation list. Other access form URIs 435 MAY be used in addition to the RSYNC URI. 437 This extension MUST be present and it is non-critical. There is one 438 exception, namely where a CA distributes its public key in the form 439 of a "self-signed" certificate, the CRLDP MUST be omitted. 441 3.9.6. Authority Information Access 443 This field (AIA) identifies the point of publication of the 444 certificate that is issued by the issuer's immediate superior CA, 445 where this certificate's issuer is the subject. In this profile a 446 single reference object to publication location of the immediate 447 superior certificate MUST be used, except in the case where a CA 448 distributes its public key in the form of a "self-signed" 449 certificate, in which case the AIA field SHOULD be omitted. 451 This profile uses a URI form of object identification. The preferred 452 URI access mechanisms is "rsync", and an RSYNC URI MUST be specified 453 with an accessMethod value of id-ad-caIssuers. The URI MUST 454 reference the point of publication of the certificate where this 455 issuer is the subject (the issuer's immediate superior certificate). 456 Other access method URIs referencing the same object MAY also be 457 included in the value sequence of this extension. 459 When an Issuer re-issues a CA certificate, the subordinate 460 certificates need to reference this new certificate via the AIA 461 field. In order to avoid the situation where a certificate re- 462 issuance necessarily implies a requirement to re-issue all 463 subordinate certificates, CA Certificate issuers SHOULD use a 464 persistent URL name scheme for issued certificates. This implies 465 that re-issued certificates overwrite previously issued certificates 466 to the same subject in the publication repository, and use the same 467 publication name as previously issued certificates. In this way 468 subordinate certificates can maintain a constant AIA field value and 469 need not be re-issued due solely to a re-issue of the superior 470 certificate. The issuers' policy with respect to the persistence of 471 name objects of issued certificates MUST be specified in the Issuer's 472 Certification Practice Statement. 474 This extension is non-critical. 476 3.9.7. Subject Information Access 478 This field (SIA) identifies the location of information and services 479 relating to the subject of the certificate in which the SIA extension 480 appears. Where the Subject is a CA in this profile, this information 481 and service collection will include all current valid certificates 482 that have been issued by this subject that are signed with the 483 subject's corresponding private key. 485 This profile uses a URI form of location identification. The 486 preferred URI access mechanism is "rsync", and an RSYNC URI MUST be 487 specified, with an access method value of id-ad-caRepository when the 488 subject of the certificate is a CA. The RSYNC URI must reference an 489 object collection rather than an individual object and MUST use a 490 trailing '/' in the URI. 492 Other access method URIs that reference the same location MAY also be 493 included in the value sequence of this extension. The ordering of 494 URIs in this sequence reflect the subject's relative preferences for 495 access methods, with the first method in the sequence being the most 496 preferred. 498 This field MUST be present when the subject is a CA, and is non- 499 critical. 501 For End Entity (EE) certificates, where the subject is not a CA, this 502 field MAY be present, and is non-critical. If present, it either 503 references the location where objects signed by the key pair 504 associated with the EE certificate can be accessed, or, in the case 505 of single-use EE certificates it references the location of the 506 single object that has been signed by the corresponding key pair. 508 When the subject is an End Entity, and it publishes objects signed 509 with the matching private key in a repository, the directory where 510 these signed objects is published is referenced the id-ad- 511 signedObjectRepository OID. 513 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 515 id-ad-signedObjectRepository OBJECT IDENTIFIER ::= { id-ad 9 } 517 When the subject is an End Entity, and it publishes a single object 518 signed with the matching private key, the location where this signed 519 object is published is referenced the id-ad-signedObject OID. 521 id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 } 523 This profile requires the use of repository publication manifests 524 [ID.SIDR-MANIFESTS] to list all signed objects that are deposited in 525 the repository publication point associated with a CA or an EE. The 526 publication point of the manifest for a CA or EE is placed in the SIA 527 extension of the CA or EE certificate. This profile uses a URI form 528 of manifest identification for the accessLocation. The preferred URI 529 access mechanisms is "rsync", and an RSYNC URI MUST be specified. 530 Other accessDescription fields may exist with this id-ad-Manifest 531 accessMethod, where the accessLocation value indicates alternate URI 532 access mechanisms for the same manifest object. 534 id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 } 536 CA certificates MUST include in the SIA an accessMethod OID of id-ad- 537 rpkiManifest, where the associated accessLocation refers to the 538 subject's published manifest object as an object URL. 540 When an EE certificate is intended for use in verifying multiple 541 objects, EE certificate MUST include in the SIA an access method OID 542 of id-ad-rpkiManifest, where the associated access location refers to 543 the publication point of the objects that are verified using this EE 544 certificate. 546 When an EE certificate is used to sign a single published object, the 547 EE certificate MUST include in the SIA an access method OID of id-ad- 548 signedObject, where the associated access location refers to the 549 publication point of the single object that is verified using this EE 550 certificate. In this case, the SIA MUST NOT include the access 551 method OID of id-ad-rpkiManifest. 553 3.9.8. Certificate Policies 555 This extension MUST reference the Resource Certificate Policy, using 556 the OID Policy Identifier value of "1.3.6.1.5.5.7.14.2". This field 557 MUST be present and MUST contain only this value for Resource 558 Certificates. 560 PolicyQualifiers MUST NOT be used in this profile. 562 This extension MUST be present and it is critical. 564 3.9.9. IP Resources 566 This field contains the list of IP address resources as per 567 [RFC3779]. The value may specify the "inherit" element for a 568 particular AFI value. In the context of resource certificates 569 describing public number resources for use in the public Internet, 570 the SAFI value MUST NOT be used. All Resource Certificates MUST 571 include an IP Resources extension, an AS Resources extension, or both 572 extensions. 574 This extension, if present, MUST be marked critical. 576 3.9.10. AS Resources 578 This field contains the list of AS number resources as per [RFC3779], 579 or may specify the "inherit" element. RDI values are NOT supported 580 in this profile and MUST NOT be used. All Resource Certificates MUST 581 include an IP Resources extension, an AS Resources extension, or both 582 extensions. 584 This extension, if present, MUST be marked critical. 586 4. Resource Certificate Revocation List Profile 588 Each CA MUST issue a version 2 Certificate Revocation List (CRL), 589 consistent with [RFC5280]. The CRL issuer is the CA, and no indirect 590 CRLs are supported in this profile. 592 An entry MUST NOT be removed from the CRL until it appears on one 593 regularly scheduled CRL issued beyond the revoked certificate's 594 validity period. 596 This profile does not allow issuance of Delta CRLs. 598 The scope of the CRL MUST be "all certificates issued by this CA 599 using a given key pair". The contents of the CRL are a list of all 600 non-expired certificates issued by the CA using a given key pair that 601 have been revoked by the CA. 603 The profile allows the issuance of multiple current CRLs with 604 different scope by a single CA, with the scope being defined by the 605 key pair used by the CA. 607 No CRL fields other than those listed here are permitted in CRLs 608 issued under this profile. Unless otherwise indicated, these fields 609 MUST be present in the CRL. Where two or more CRLs issued by a 610 single CA with the same scope, the CRL with the highest value of the 611 "CRL Number" field supersedes all other CRLs issued by this CA. 613 4.1. Version 615 Resource Certificate Revocation Lists are Version 2 certificates (the 616 integer value of this field is 1). 618 4.2. Issuer Name 620 The value of this field is the X.501 name of the issuing CA who is 621 also the signer of the CRL, and is identical to the Issuer name in 622 the Resource Certificates that are issued by this issuer. 624 4.3. This Update 626 This field contains the date and time that this CRL was issued. The 627 value of this field MUST be encoded as UTCTime for dates through the 628 year 2049, and MUST be encoded as GeneralizedTime for dates in the 629 year 2050 or later. 631 4.4. Next Update 633 This is the date and time by which the next CRL SHOULD be issued. 634 The value of this field MUST be encoded as UTCTime for dates through 635 the year 2049, and MUST be encoded as GeneralizedTime for dates in 636 the year 2050 or later. 638 4.5. Signature 640 This field contains the algorithm used to sign this CRL. This 641 profile specifies a minimum of SHA-256 with RSA 642 (sha256WithRSAEncryption), and allows for the use of SHA-384 or SHA- 643 512. This field MUST be present. 645 It is noted that larger key sizes are computationally expensive for 646 both the CRL Issuer and relying parties, indicating that care should 647 be taken when deciding to use larger than the minimum key size. 649 4.6. Revoked Certificate List 651 When there are no revoked certificates, then the revoked certificate 652 list MUST be absent. 654 For each revoked resource certificate only the following fields MUST 655 be present. No CRL entry extensions are supported in this profile, 656 and CRL entry extensions MUST NOT be present in a CRL. 658 4.6.1. Serial Number 660 The issuer's serial number of the revoked certificate. 662 4.6.2. Revocation Date 664 The time the certificate was revoked. This time MUST NOT be a future 665 date. The value of this field MUST be encoded as UTCTime for dates 666 through the year 2049, and MUST be encoded as GeneralizedTime for 667 dates in the year 2050 or later. 669 4.7. CRL Extensions 671 The X.509 v2 CRL format allows extensions to be placed in a CRL. The 672 following extensions are supported in this profile, and MUST be 673 present in a CRL. 675 4.7.1. Authority Key Identifier 677 The authority key identifier extension provides a means of 678 identifying the public key corresponding to the private key used to 679 sign a CRL. Conforming CRL issuers MUST use the key identifier 680 method. The syntax for this CRL extension is defined in section 681 4.2.1.1 of [RFC5280]. 683 This extension is non-critical. 685 4.7.2. CRL Number 687 The CRL Number extension conveys a monotonically increasing sequence 688 number of positive integers for a given CA and scope. This extension 689 allows users to easily determine when a particular CRL supersedes 690 another CRL. The highest CRL Number value supersedes all other CRLs 691 issued by the CA with the same scope. 693 This extension is non-critical. 695 5. Resource Certificate Request Profile 697 A resource certificate request MAY use either of PKCS#10 or 698 Certificate Request Message Format (CRMF). A CA Issuer MUST support 699 PKCS#10 and a CA Issuer may, with mutual consent of the subject, 700 support CRMF. 702 5.1. PCKS#10 Profile 704 This profile refines the specification in [RFC2986], as it relates to 705 Resource Certificates. A Certificate Request Message object, 706 formatted according to PKCS#10, is passed to a CA as the initial step 707 in issuing a certificate. 709 This request may be conveyed to the CA via a Registration Authority 710 (RA), acting under the direction of a Subject. 712 With the exception of the public key related fields, the CA is 713 permitted to alter any requested field when issuing a corresponding 714 certificate. 716 5.1.1. PKCS#10 Resource Certificate Request Template Fields 718 This profile applies the following additional constraints to fields 719 that may appear in a CertificationRequestInfo: 721 Version 722 This field is mandatory and MUST have the value 0. 724 Subject 725 This field is optional. If present, the value of this field 726 SHOULD be empty, in which case the issuer MUST generate a subject 727 name that is unique in the context of certificates issued by this 728 issuer. If the value of this field is non-empty, then the CA MAY 729 consider the value of this field as the subject's suggested 730 subject name, but the CA is NOT bound to honour this suggestion, 731 as the subject name MUST be unique per issuer in certificates 732 issued by this issuer. 734 SubjectPublicKeyInfo 735 This field specifies the subject's public key and the algorithm 736 with which the key is used. The public key algorithm MUST be RSA, 737 and the OID for the algorithm is 1.2.840.113549.1.1.1. This field 738 also includes a bit-string representation of the entity's public 739 key. For the RSA public-key algorithm the bit string contains the 740 DER encoding of a value of PKCS #1 type RSAPublicKey. 742 Attributes 743 [RFC2986] defines the attributes field as key-value pairs where 744 the key is an OID and the value's structure depends on the key. 746 The only attribute used in this profile is the ExtensionRequest 747 attribute as defined in [RFC2985]. This attribute contains X509v3 748 Certificate Extensions. The profile for extensions in certificate 749 requests is specified in Section 5.3. 751 This profile applies the following additional constraints to fields 752 that MAY appear in a CertificationRequest Object: 754 signatureAlgorithm 755 This profile specifies a minimum of SHA-256 with RSA 756 (sha256WithRSAEncryption), and allows for the use of SHA-384 or 757 SHA-512. Accordingly, the value for this field MUST be one of the 758 OID values { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 } 759 [RFC4055]. 760 It is noted that larger key sizes are computationally expensive 761 for both the CA and relying parties, indicating that care should 762 be taken when deciding to use larger than the minimum key size. 764 5.2. CRMF Profile 766 This profile refines the Certificate Request Message Format (CRMF) 767 specification in [RFC4211], as it relates to Resource Certificates. 768 A Certificate Request Message object, formatted according to the 769 CRMF, is passed to a CA as the initial step in issuing a certificate. 771 This request MAY be conveyed to the CA via a Registration Authority 772 (RA), acting under the direction of a subject. 774 With the exception of the public key related fields, the CA is 775 permitted to alter any requested field when issuing a corresponding 776 certificate. 778 5.2.1. CRMF Resource Certificate Request Template Fields 780 This profile applies the following additional constraints to fields 781 that may appear in a Certificate Request Template: 783 Version 784 This field MAY be absent, or MAY specify the request of a Version 785 3 Certificate. It SHOULD be omitted. 787 SerialNumber 788 As per [RFC4211], this field is assigned by the CA and MUST be 789 omitted in this profile. 791 SigningAlgorithm 792 As per [RFC4211], this field is assigned by the CA and MUST be 793 omitted in this profile. 795 Issuer 796 This field is assigned by the CA and MUST be omitted in this 797 profile. 799 Validity 800 This field MAY be omitted. If omitted, the CA will issue a 801 Certificate with Validity dates as determined by the CA. If 802 specified, then the CA MAY override the requested values with 803 dates as determined by the CA. 805 Subject 806 This field is optional. If present, the value of this field 807 SHOULD be empty, in which case the issuer MUST generate a subject 808 name that is unique in the context of certificates issued by this 809 issuer. If the value of this field is non-empty, then the CA MAY 810 consider the value of this field as the subject's suggested 811 subject name, but the CA is NOT bound to honour this suggestion, 812 as the subject name MUST be unique per issuer in certificates 813 issued by this issuer. 815 PublicKey 816 This field MUST be present. 818 extensions 819 This attribute contains X509v3 Certificate Extensions. The 820 profile for extensions in certificate requests is specified in 821 Section 5.3. 823 5.2.2. Resource Certificate Request Control Fields 825 The following control fields are supported in this profile: 827 Authenticator Control 828 It is noted that the intended model of authentication of the 829 subject is a long term one, and the advice as offered in [RFC4211] 830 is that the Authenticator Control field be used. 832 5.3. Certificate Extension Attributes in Certificate Requests 834 The following extensions MAY appear in a PKCS#10 or CRMF Certificate 835 Request. Any other extensions MUST NOT appear in a Certificate 836 Request. This profile places the following additional constraints on 837 these extensions.: 839 BasicConstraints 840 If this is omitted then the CA will issue an end entity 841 certificate with the BasicConstraints extension not present in the 842 issued certificate. 844 The Path Length Constraint is not supported in this Resource 845 Certificate Profile, and this field MUST be omitted in this 846 profile. 848 The CA MAY honour the SubjectType CA bit set to on. If this bit 849 is set, then it indicates that the Subject is allowed to issue 850 resource certificates within this overall framework. 852 The CA MUST honour the SubjectType CA bit set to off (End Entity 853 certificate request), in which case the corresponding end entity 854 certificate will not contain a BasicConstraints extension. 856 SubjectKeyIdentifier 857 This field is assigned by the CA and MUST be omitted in this 858 profile. 860 AuthorityKeyIdentifier 861 This field is assigned by the CA and MUST be omitted in this 862 profile. 864 KeyUsage 865 The CA MAY honor KeyUsage extensions of keyCertSign and cRLSign if 866 present, as long as this is consistent with the BasicConstraints 867 SubjectType sub field, when specified. 869 SubjectInformationAccess 870 This field MUST be present when the subject is a CA, and the field 871 value SHOULD be honoured by the CA. If the CA is not able to 872 honor the requested field value, then the CA MUST reject the 873 Certificate Request. 875 This field (SIA) identifies the location of information and 876 services relating to the subject of the certificate in which the 877 SIA extension appears. 879 Where the subject is a CA in this profile, this information and 880 service collection will include all current valid certificates 881 that have been issued by this subject that are signed with the 882 subject's corresponding private key. 884 This profile uses a URI form of location identification. An RSYNC 885 URI MUST be specified, with an access method value of id-ad- 886 caRepository when the subject of the certificate is a CA. The 887 RSYNC URI MUST reference an object collection rather than an 888 individual object and MUST use a trailing '/' in the URI. Other 889 access method URIs that reference the same location MAY also be 890 included in the value sequence of this extension. The ordering of 891 URIs in this sequence reflect the subject's relative preferences 892 for access methods, with the first method in the sequence being 893 the most preferred by the Subject. 895 A request for a CA certificate MUST include in the SIA of the 896 request the id-ad-caRepository access method, and also MUST 897 include in the SIA of the request the accessMethod OID of id-ad- 898 rpkiManifest, where the associated accessLocation refers to the 899 subject's published manifest object as an object URL. 901 This field MAY be present when the subject is a EE. If it is 902 present the field value SHOULD be honoured by the CA. If the CA 903 is not able to honor the requested field value, then the CA MUST 904 reject the Certificate Request. If it is not present the CA 905 SHOULD honor this request and omit the SIA from the issued 906 certificate. If the CA is not able to honor the request to omit 907 the SIA, then the CA MUST reject the Certificate Request. 909 When an EE certificate is intended for use in verifying multiple 910 objects, the certificate request for the EE certificate MUST 911 include in the SIA of the request an access method OID of id-ad- 912 signedObjectRepository, and also MUST include in the SIA of the 913 request an access method OID of id-ad-rpkiManifest, where the 914 associated access location refers to the publication point of the 915 objects that are verified using this EE certificate. 917 When an EE certificate is used to sign a single published object, 918 the certificate request for the EE certificate MUST include in the 919 SIA of the request an access method OID of id-ad-signedObject, 920 where the associated access location refers to the publication 921 point of the single object that is verified using this EE 922 certificate, and MUST NOT include an id-ad-rpkiManifest access 923 method OID in the SIA of the request. 925 In the case when the EE certificate is to be used exclusively to 926 sign one or more unpublished objects, such that the all signed 927 objects will not be published in any RPKI repository, then the SIA 928 SHOULD be omitted from the request. 930 CRLDistributionPoints 931 This field is assigned by the CA and MUST be omitted in this 932 profile. 934 AuthorityInformationAccess 935 This field is assigned by the CA and MUST be omitted in this 936 profile. 938 CertificatePolicies 939 This field is assigned by the CA and MUST be omitted in this 940 profile. 942 With the exceptions of the publicKey field and the 943 SubjectInformationAccess field, the CA is permitted to alter any 944 requested field. 946 6. Resource Certificate Validation 948 This section describes the Resource Certificate validation procedure. 949 This refines the generic procedure described in section 6 of 950 [RFC5280]: 952 To meet this goal, the path validation process verifies, among other 953 things, that a prospective certification path (a sequence of n 954 certificates) satisfies the following conditions: 956 1. for all x in {1, ..., n-1}, the subject of certificate x is the 957 issuer of certificate x+1; 959 2. certificate 1 is issued by a trust anchor; 961 3. certificate n is the certificate to be validated; and 963 4. for all x in {1, ..., n}, the certificate is valid. 965 6.1. Resource Extension Validation 967 The IP resource extension definition [RFC3779] defines a critical 968 extensions for Internet number resources. These are ASN.1 encoded 969 representations of the IPv4 and IPv6 address range (either as a 970 prefix/length, or start-end pair) and the AS number set. 972 Valid Resource Certificates MUST have a valid IP address and/or AS 973 number resource extension. In order to validate a Resource 974 Certificate the resource extension must also be validated. This 975 validation process relies on definitions of comparison of resource 976 sets: 978 more specific: Given two IP address or AS number contiguous ranges, 979 A and B, A is "more specific" than B if range B includes all IP 980 addresses or AS numbers described by range A, and if range B is 981 larger than range A. 983 equal: Given two IP address or AS number contiguous ranges, A and B, 984 A is "equal" to B if range A describes precisely the same 985 collection of IP addresses or AS numbers as described by range B. 986 The definition of "inheritance" in [RFC3779] is equivalent to this 987 "equality" comparison. 988 encompass: Given two IP address and AS number sets X and Y, X 989 "encompasses" Y if, for every contiguous range of IP addresses or 990 AS numbers elements in set Y, the range element is either more 991 specific than or equal to a contiguous range element within the 992 set X. 994 Validation of a certificate's resource extension in the context of an 995 ordered certificate sequence of {1,2, ... , n} where '1' is issued by 996 a trust anchor and 'n' is the target certificate, and where the 997 subject of certificate 'x' is the issuer of certificate 'x' + 1, 998 implies that the resources described in certificate 'x' "encompass" 999 the resources described in certificate 'x' + 1, and the resources 1000 described in the trust anchor information "encompass" the resources 1001 described in certificate 1. 1003 6.2. Resource Certification Path Validation 1005 Validation of signed resource data using a target resource 1006 certificate consists of assembling an ordered sequence (or 1007 'Certification Path') of certificates ({1,2,...n} where '1' is a 1008 certificate that has been issued by a trust anchor, and 'n' is the 1009 target certificate) verifying that all of the following conditions 1010 hold: 1012 1. The certificate can be verified using the Issuer's public key and 1013 the signature algorithm 1015 2. The current time lies within the certificate's Validity From and 1016 To values. 1018 3. The certificate contains all fields that MUST be present and 1019 contains field values as specified in this profile for all field 1020 values that MUST be present. 1022 4. No field value that MUST NOT be present in this profile is 1023 present in the certificate. 1025 5. The Issuer has not revoked the certificate by placing the 1026 certificate's serial number on the Issuer's current Certificate 1027 Revocation List, and the Certificate Revocation List is itself 1028 valid. 1030 6. That the resource extension data is "encompassed" by the resource 1031 extension data contained in a valid certificate where this Issuer 1032 is the Subject (the previous certificate in the ordered sequence) 1034 7. The Certification Path originates with a certificate issued by a 1035 trust anchor, and there exists a signing chain across the 1036 Certification Path where the Subject of Certificate x in the 1037 Certification Path matches the Issuer in Certificate x+1 in the 1038 Certification Path. 1040 A certificate validation algorithm may perform these tests in any 1041 chosen order. 1043 Certificates and CRLs used in this process may be found in a locally 1044 maintained cache, maintained by a regular top-down synchronization 1045 pass, seeded with the CAs who operate at the apex of the resource 1046 distribution hierarchy, via reference to issued certificates and 1047 their SIA fields as forward pointers, plus the CRLDP. Alternatively, 1048 validation may be performed using a bottom-up process with on-line 1049 certificate access using the certificate's AIA and CRLDP pointers to 1050 guide the certificate retrieval process for each certificate's 1051 immediate superior CA certificate. 1053 There exists the possibility of encountering certificate paths that 1054 are arbitrarily long, or attempting to generate paths with loops as 1055 means of creating a potential DOS attack on a certificate validator. 1056 Some further heuristics may be required to halt the certification 1057 path validation process in order to avoid some of the issues 1058 associated with attempts to validate such structures. It is 1059 suggested that implementations of Resource Certificate validation MAY 1060 halt with a validation failure if the certification path length 1061 exceeds a pre-determined configuration parameter. 1063 6.3. Trust Anchors for Resource Certificates 1065 The trust model that may be used in the resource certificate 1066 framework in the context of validation of assertions of public number 1067 resources in public-use contexts is one that readily maps to a top- 1068 down delegated CA model that mirrors the delegation of resources from 1069 a registry distribution point to the entities that are the direct 1070 recipients of these resources. Within this trust model these 1071 recipient entities may, in turn, operate a registry and perform 1072 further allocations or assignments. This is a strict hierarchy, in 1073 that any number resource and a corresponding recipient entity has 1074 only one 'parent' issuing registry for that number resource (i.e. 1075 there is always a unique parent entity for any resource and 1076 corresponding entity), and that the issuing registry is not a direct 1077 or indirect subordinate recipient entity of the recipient entity in 1078 question (i.e. no loops in the model). 1080 The more general consideration is that selection of one or more trust 1081 anchor CAs is a task undertaken by relying parties. The structure of 1082 the resource certificate profile admits potentially the same variety 1083 of trust models as the PKIX profile. There is only one additional 1084 caveat on the general applicability of trust models and PKIX 1085 frameworks, namely that in forming a validation path to a trust 1086 anchor CA, the sequence of certificates MUST preserve the resource 1087 extension validation property, as described in Section 6.1, and the 1088 validation of the first certificate in the validation path not only 1089 involves the verification that the certificate was issued by a trust 1090 anchor CA, but also that the resource set described in the 1091 certificate MUST be encompassed by the trust anchor CA's resource 1092 set, as described in Section 6.1. 1094 The trust anchor information, describing a CA that serves as a trust 1095 anchor, includes the following: 1097 1. the trusted issuer name, 1099 2. the trusted public key algorithm, 1101 3. the trusted public key, 1103 4. optionally, the trusted public key parameters associated with the 1104 public key, and 1106 5. a resource set, consisting of a set of IPv4 resources, IPv6 1107 resources and AS number resources. 1109 The trust anchor information may be provided to the path processing 1110 procedure in the form of a self-signed certificate. 1112 6.3.1. Distribution Format of Nominated Trust Anchor Material 1114 In the RPKI the hierarchical certificate framework corresponds to the 1115 hierarchies of the resource distribution function. In consideration 1116 of this, it is reasonable to nominate to relying parties a default 1117 set of trust anchors for the RPKI that correspond to the entities who 1118 operate at the upper levels of the associated resource allocation 1119 hierarchy. The corresponding nominated trust anchor CA(s) should 1120 therefore map, in some fashion, to apex point(s) of the hierarchical 1121 resource distribution structure. 1123 The characteristics of a trust anchor framework for the RPKI includes 1124 the following considerations: 1126 o The entity or entities that issue proposed trust anchor material 1127 for the RPKI should be as close as possible to the apex of the 1128 associated resource distribution hierarchy. 1130 o Such trust anchor material should be long-lived. As it can be 1131 reasonably anticipated that default nominated trust anchor 1132 material would be distributed with relying party validation 1133 software, the implication is that the distributed default 1134 nominated trust anchor material should remain constant for 1135 extended time intervals. 1137 o It is a poor trust model when any entity that issues putative 1138 trust anchor material is forced to be authoritative over 1139 information or actions of which the entity has no direct 1140 knowledge, nor is in possession of a current definitive record of 1141 such actions. Entities who propose themselves in a role of a 1142 trust anchor issuer should be able to point to corroborative 1143 material supporting the assertion that they are legitimate 1144 authorities for the information where they are representing 1145 themselves as a potential trust anchor for relying parties. 1147 An entity offering itself as a putative RPKI trust anchor for a part 1148 of the RPKI is required to regularly publish a RPKI CA certificate at 1149 a stable URL, and to publish a packaged form of this URL as 1150 distributed trust anchor material, as follows: 1152 o The entity issues a RPKI self-signed "root" CA certificate that is 1153 used as the apex of a RPKI certificate issuance hierarchy. This 1154 certificate MUST have the keyCertSign sign bit set in the key 1155 usage extension, and the CA flag set in the basic constraints 1156 extension, no AIA value and no CRLDP value. This certificate MUST 1157 be reissued at regular intervals prior to expiration of the 1158 current RPKI self-signed certificate, and MUST be reissued upon 1159 any change in the resource set that has been allocated to the 1160 entity who is operating this CA. The validity interval of this 1161 certificate should reflect the anticipated period of the regular 1162 RPKI certificate re-issuance. 1164 o The entity maintains a "trust anchor material" key pair. 1166 o The entity issues a PKI self-signed CA certificate [RFC5280] using 1167 the trust anchor material key pair, where the subject public key 1168 in the certificate is the public key of the trust anchor material 1169 key pair and the certificate is signed by the corresponding 1170 private key of trust anchor material key pair. This certificate 1171 MUST have the keyCertSign sign bit set in the key usage extension, 1172 and the CA flag set in the basic constraints extension, no AIA 1173 value and no CRLDP value. The validity period of this certificate 1174 shold be very long-lived, with the period to be defined by the 1175 entity. The SIA of this certificate references a publication 1176 point where the CRL and the subordinate product of this 1177 certificate are published. 1179 o The PKI CA issues a subordinate PKI EE certificate with a validity 1180 period identical to the validity period of the RPKI self-signed 1181 "root" CA certificate. This PKI EE certificate MUST have the 1182 digitalSignature bit set, and this MUST be the only bit set to 1183 TRUE. The CA flag set MUST be cleared in the basic constraints 1184 extension. The validity period of this certificate should be 1185 aligned to the validity period of the RPKI self-signed "root" CA 1186 certificate. 1188 o The PKI CA regularly issues a CRL. The CRL issuance cycle SHOULD 1189 be shorter than the validity period for the RPKI self-signed 1190 "root" certificate. 1192 o Each time the RPKI self-signed "root" certificate is re-issued, or 1193 prior to the expiration of the PKI EE certificate, the PKI CA 1194 generates a Cryptographic Message Syntax (CMS) [RFC3852] signed- 1195 data object, where the payload is the RPKI self-signed "root" 1196 certificate. The object is CMS-signed with the private key of the 1197 PKI EE certificate. The PKI EE certificate is included as a CMS 1198 signed attribute in the CMS object. The PKI self-signed CA 1199 certificate and the asociated CRL are not to be included in the 1200 CMS object. The format of the CMS object is specified in 1201 Appendix C. The CMS object is published at the location 1202 referenced in the SIA of the PKI self-signed CA certificate. 1204 o The entity publically distributes the PKI self-signed CA 1205 certificate as its proposed trust anchor material. 1207 o The entity publishes the modulus and exponent of the "trust anchor 1208 material" public key using a trusted form of publication that 1209 allows the entity's identity to be validated and the retrieval of 1210 the published information to be secured. 1212 Relying Parties can assemble the default trust anchor collection by 1213 using the distributed PKI self-signed CA certificate for each 1214 nominated trust anchor: 1216 o The public key in the self-signed CA PKI certificate can be 1217 validated using the modulus and exponent values as retrieved from 1218 the entity's publication point using a secured retrieval 1219 operation. 1221 o The PKI CA's CRL and CMS objects can be retrieved from the 1222 publication point referenced by the SIA in the PKI CA certificate. 1224 o The CRL can be verified against the PKI CA certificate. 1226 o The CMS signature can be verified using the included PKI EE 1227 certificate together with the retrieved CRL and the self-signed 1228 PKI CA certificate. 1230 o The relying party can then load the enclosed RPKI self-signed CA 1231 certificate as a trust anchor for RPKI validation for those 1232 resources described in the resource extension of this RPKI 1233 certificate. 1235 Relying Parties should perform this retrieval and validation 1236 operation at intervals no less frequent than the nextUpdate time of 1237 the published CRL, and should perform the retrieval operation prior 1238 to the expiration of the PKI EE certificate, or upon revocation of 1239 the PKI EE certificate that was used to sign the CMS object that held 1240 the relying party's current RPKI self-signed CA certificate. 1242 If a trust anchor CA wishes to perform an issuance of the RPKI self- 1243 signed CA certificate outside the established update cycle time, it 1244 can notify relying parties of this by revising the nextUpdate time of 1245 the PKI CA's CRL to a shorter interval, issuing a new PKI CA 1246 certificate and a new CMS object with the new RPKI self-signed CA 1247 certificate, and revoking the old PKI EE certificate at the 1248 nextUpdate time in the next issued CRL. This revocation will provide 1249 an indication to relying parties to perform the retrieval operation 1250 ofthe RPKI self-signed CA certificate at a time earlier than the 1251 normal update cycle time. 1253 7. Security Considerations 1255 The Security Considerations of [RFC5280] and [RFC3779]apply to 1256 Resource Certificates as defined by this profile, and their use. 1258 A Resource Certificate PKI cannot in and of itself resolve any forms 1259 of ambiguity relating to uniqueness of assertions of rights of use in 1260 the event that two or more valid certificates encompass the same 1261 resource. If the issuance of resource certificates is aligned to the 1262 status of resource allocations and assignments then the information 1263 conveyed in a certificate is no better than the information in the 1264 allocation and assignment databases. 1266 8. IANA Considerations 1268 [Note to IANA, to be removed prior to publication: there are no IANA 1269 considerations stated in this document.] 1271 9. Acknowledgements 1273 The authors would like to acknowledge the valued contributions from 1274 Stephen Kent, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo 1275 Patara and Rob Austein in the preparation and subsequent review of 1276 this document. The document also reflects review comments received 1277 from Sean Turner and David Cooper. 1279 10. Draft Review Notes 1281 The following review comments are unresolved at present: 1283 1. Use of additional non-critical extensions: 1285 Section 3: "Unless specifically noted as being OPTIONAL, all the 1286 fields listed here MUST be present, and any other field MUST NOT 1287 appear in a conforming Resource Certificate." 1289 The review comment was that certificate profile should permit 1290 the use of non-critical extensions. The scenario nominatedwas 1291 one in which a CA product added non-critical extensions to a 1292 certificate that would not affect a relying party's decision 1293 to accept the certificate, regardless of whether the relying 1294 party could process the extension. It was noted that it may 1295 be possible to configure these CA products so that they do not 1296 include these extensions in the certificates, but that is a 1297 question that would need to be answered by someone more 1298 familiar with particular CA products that add non-critical 1299 extensions that identify the CA product used to mint the 1300 certificate. 1302 The rationale for not permitting non-critical extensions is 1303 that it was not seen as being appropriate to be in the 1304 position of having certificates with extensions which relying 1305 parties may see as valid, but contain extensions that, were 1306 the relying party to understand the extension, would 1307 contradict or qualify in some way this original validity. The 1308 profile takes the position of minimialism over extensibility, 1309 taking the approach of nomination of a specific goal for the 1310 PKI, namely to construct a PKI that precisely matches the IP 1311 number resource allocation structure, and then defining a 1312 certificate profile that was precisely aligned to this 1313 objective. If there is some need or requirement to use the 1314 RFC3779 extensions in contexts other than assertions about 1315 right of use of resources by virtue of an allocation action, 1316 that make use of other extensions than are specified here, 1317 then the authors suggest that it would be more appropriate to 1318 define a distinct profile to fulfil this function. 1320 It is proposed to leave the text as is. 1322 2. CRL Scope: 1324 Section 3.9.5: In this profile, the scope of the CRL is specified 1325 to be all certificates issued by this CA issue using a given key 1326 pair. 1328 The review comment was that the scope of a CRL must be all 1329 certificates issued by the issuing CA unless the CRL includes 1330 an issuingDistributionPoint extension. So, if the scope of 1331 CRLs is to be limited to certificates signed with a given key 1332 pair, then the profile must either require inclusion of the 1333 issuingDistributionPoint extension in CRLs or forbid CAs from 1334 performing key rollover. The latter option may be implemented 1335 by having issuers change names whenever changing the key pair 1336 used to sign certificates. 1338 It is proposed to drop the scope restriction, and remove the 1339 text in Section 3.9.5. 1341 3. Name Uniqueness: 1343 Section 3.5 stipulates that subject names must simply be unique 1344 per issuer, while X.509 requires that names must be globally 1345 unique. 1347 The review comment was that the Security Considerations 1348 section in RFC5280 states: " While X.509 mandates that names 1349 be unambiguous, there is a risk that two unrelated authorities 1350 will issue certificates and/or CRLs under the same issuer 1351 name." X.501 states that a (directory) name shall be 1352 unambiguous, in that it denotes just one object, but need not 1353 be unique, in that it not be the only name that unambiguously 1354 denotes the object, and that for every name form used in the 1355 GeneralName type, there shall be a name registration system 1356 that ensures that any name used unambiguously identifies one 1357 entity to both certificate issuer and certificate users. The 1358 review comment is that problem with a less stringent 1359 requirement is that if two CAs issue certificates and CRLs 1360 under the same name, there is a risk that a relying party will 1361 use a CRL issued by one of these CAs to determine the status 1362 of a certificate issued by the other CA. 1364 The rationale for using a name this is unique per issuer is 1365 that the RPKI is strictly hierarchical, the repository 1366 publication structure is structured on a per-CA basis, the 1367 CRLDP is mandatory to include in all RPKI certificates (except 1368 apex self-signed certs) so that each certificate points 1369 directly to the associated CRL that can revoke it, the 1370 contextof the use of names is within a per issuer context, a 1371 single entity may hold resources from multiple sources and the 1372 RPKI name space is unconstrained such that it is neither 1373 coordinated nor restricted to be structured in any fashion, 1374 and the RPKI is not attesting a name or an identity but a 1375 right to use resources. Because the context of the use of 1376 names in the RPKI is one that positions names within a strict 1377 hierarchy, then the essential name attribute of unambiguity is 1378 achieved in the RPKI when names are specified to be unique per 1379 issuer. 1381 It is proposed not to alter the existing specification of 1382 uniqueness of names on a per-issuer basis. 1384 11. References 1386 11.1. Normative References 1388 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1389 September 1981. 1391 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and 1392 J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 1393 BCP 12, RFC 2050, November 1996. 1395 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1396 Addresses and AS Identifiers", RFC 3779, June 2004. 1398 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1399 RFC 3852, July 2004. 1401 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1402 Algorithms and Identifiers for RSA Cryptography for use in 1403 the Internet X.509 Public Key Infrastructure Certificate 1404 and Certificate Revocation List (CRL) Profile", RFC 4055, 1405 June 2005. 1407 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1408 Certificate Request Message Format (CRMF)", RFC 4211, 1409 September 2005. 1411 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1412 Architecture", RFC 4291, February 2006. 1414 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1415 Housley, R., and W. Polk, "Internet X.509 Public Key 1416 Infrastructure Certificate and Certificate Revocation List 1417 (CRL) Profile", RFC 5280, May 2008. 1419 [X.509] ITU-T, "Recommendation X.509: The Directory - 1420 Authentication Framework", 2000. 1422 11.2. Informative References 1424 [ID.SIDR-MANIFESTS] 1425 Austein, R., Huston, G., Kent, S., and M. Lepinski, 1426 "Manifests for the Resource Public Key Infrastructure", 1427 Work in progress: Internet 1428 Drafts draft-ietf-sidr-rpki-manifests-00.txt, 1429 January 2008. 1431 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1432 Classes and Attribute Types Version 2.0", RFC 2985, 1433 November 2000. 1435 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1436 Request Syntax Specification Version 1.7", RFC 2986, 1437 November 2000. 1439 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 1440 Nicholas, "Internet X.509 Public Key Infrastructure: 1442 Certification Path Building", RFC 4158, September 2005. 1444 [rsync] Tridgell, A., "rsync", April 2006, 1445 . 1447 Appendix A. Example Resource Certificate 1449 The following is an example Resource Certificate. 1451 Certificate Name: hu9fdDBq60mrk7cPRuX2DYuXSRQ-3.cer 1453 Data: 1454 Version: 3 1455 Serial: 3 1456 Signature Algorithm: Hash: SHA256, Encryption: RSA 1457 Issuer: CN=Demo Production APNIC CA - Not for real use, 1458 E=ca@apnic.net 1459 Validity: 1460 Not Before: Thu Jul 27 06:34:04 2006 GMT 1461 Not After: Fri Jul 27 06:34:04 2007 GMT 1462 Subject: CN=APNIC own-use network resources 1463 Subject Key Identifier: 1464 86:ef:5f:74:30:6a:eb:49:ab:93:b7:0f:46:e5:f6:0d: 1465 8b:97:49:14 1466 Subject Key Identifier g(SKI): 1467 hu9fdDBq60mrk7cPRuX2DYuXSRQ 1468 Subject Public Key Info: 1469 Public Key Algorithm: rsaEncryption 1470 RSA Public Key: Modulus: 1471 c1:25:a1:b0:db:89:83:a0:fc:f1:c0:e4:7b:93:76:c1: 1472 59:b7:0d:ac:25:25:ed:88:ce:00:03:ea:99:1a:9a:2a: 1473 0e:10:2e:5f:c0:45:87:47:81:7b:1d:4d:44:aa:65:a3: 1474 f8:07:84:32:ea:04:70:27:05:2b:79:26:e6:e6:3a:cb: 1475 b2:9a:65:6c:c1:4e:d7:35:fb:f6:41:1e:8b:1c:b8:e4: 1476 5a:3a:d6:d0:7b:82:9a:23:03:f8:05:4c:68:42:67:fe: 1477 e7:45:d9:2c:a6:d1:b3:da:cf:ad:77:c5:80:d2:e3:1e: 1478 4d:e8:bf:a2:f2:44:10:b2:2f:61:bc:f4:89:31:54:7c: 1479 56:47:d5:b1:c3:48:26:95:93:c9:6f:70:14:4d:ac:a5: 1480 c2:8e:3d:1f:6d:f8:d4:93:9d:14:c7:15:c7:34:8e:ba: 1481 dd:70:b3:c2:2b:08:78:59:97:dd:e4:34:c7:d8:de:5c: 1482 f7:94:6f:95:59:ba:29:65:f5:98:15:8f:8e:57:59:5d: 1483 92:1f:64:2f:b5:3d:69:2e:69:83:c2:10:c6:aa:8e:03: 1484 d5:69:11:bd:0d:b5:d8:27:6c:74:2f:60:47:dd:2e:87: 1485 24:c2:36:68:2b:3c:fd:bd:22:57:a9:4d:e8:86:3c:27: 1486 03:ce:f0:03:2e:59:ce:05:a7:41:3f:2f:64:50:dd:e7 1487 RSA Public Key: Exponent: 65537 1488 Basic Constraints: CA: TRUE 1489 Subject Info Access: 1490 caRepository - rsync://repository.apnic.net/APNIC/ 1491 pvpjvwUeQix2e54X8fGbhmdYMo0/ 1492 q66IrWSGuBE7jqx8PAUHAlHCqRw/ 1493 hu9fdDBq60mrk7cPRuX2DYuXSRQ/ 1494 Key Usage: keyCertSign, cRLSign 1495 CRL Distribution Points: 1496 rsync://repository.apnic.net/APNIC/ 1497 pvpjvwUeQix2e54X8fGbhmdYMo0/ 1498 q66IrWSGuBE7jqx8PAUHAlHCqRw/ 1499 q66IrWSGuBE7jqx8PAUHAlHCqRw.crl 1500 Authority Info Access: caIssuers - 1501 rsync://repository.apnic.net/APNIC/ 1502 pvpjvwUeQix2e54X8fGbhmdYMo0/ 1503 q66IrWSGuBE7jqx8PAUHAlHCqRw.cer 1504 Authority Key Identifier: Key Identifier: 1505 ab:ae:88:ad:64:86:b8:11:3b:8e:ac:7c:3c:05:07:02: 1506 51:c2:a9:1c 1507 Authority Key Identifier: Key Identifier g(AKI): 1508 q66IrWSGuBE7jqx8PAUHAlHCqRw 1509 Certificate Policies: 1.3.6.1.5.5.7.14.2 1510 IPv4: 192.0.2.0/24, 1511 IPv6: 2001:DB8::/32 1512 ASNum: 4608, 4777, 9545, 18366-18370 1513 Signature: 1514 c5:e7:b2:f3:62:cb:e3:bc:50:1e:6b:90:13:19:f4:5b: 1515 4a:1c:1c:ab:b5:de:b1:a4:22:e0:28:f5:3b:d0:8c:59: 1516 0f:85:f2:06:a6:ae:22:e6:d0:99:fe:cb:eb:1d:6a:e2: 1517 a3:f1:a2:25:95:ec:a7:7d:96:35:dc:16:a7:2f:f5:b7: 1518 11:ba:97:05:57:5f:5d:07:5a:c8:19:c8:27:d3:f7:a3: 1519 92:66:cb:98:2d:e1:7f:a8:25:96:ab:af:ed:87:02:28: 1520 f5:ae:b6:e3:0c:f7:18:82:70:82:f4:76:54:06:b9:9f: 1521 e1:a5:f7:ae:72:dd:ee:f0:d4:d2:78:bb:61:73:cf:51: 1522 26:9f:ea:e8:20:49:06:ba:0c:ac:1d:f6:07:b8:63:a0: 1523 4d:3d:8e:12:84:3a:d0:ec:94:7e:02:db:d4:85:cf:12: 1524 5c:7b:12:1a:52:ab:3c:ba:00:f2:71:e7:f0:fd:b3:f4: 1525 81:e8:a7:cb:07:ca:3a:a4:24:fe:dc:bb:51:16:6a:28: 1526 33:40:a4:64:60:75:0e:c8:06:c8:5f:e5:98:be:16:a3: 1527 bc:19:e7:b3:4f:00:0a:8e:81:33:dd:4c:a0:fb:f5:1c: 1528 1f:1d:3f:b5:90:8b:ec:98:67:76:95:56:8a:94:45:54: 1529 52:3d:1c:69:4c:6f:8a:9f:09:ec:ef:b0:a9:bc:cf:9d 1531 Appendix B. Example Certificate Revocation List 1533 The following is an example Certificate Revocation List. 1534 CRL Name: q66IrWSGuBE7jqx8PAUHAlHCqRw.crl 1536 Data: 1537 Version: 2 1538 Signature Algorithm: 1539 Hash: SHA256, Encryption: RSA 1540 Issuer: CN=Demo Production APNIC CA - Not for real use, 1541 E=ca@apnic.net 1542 This Update: Thu Jul 27 06:30:34 2006 GMT 1543 Next Update: Fri Jul 28 06:30:34 2006 GMT 1544 Authority Key Identifier: Key Identifier: 1545 ab:ae:88:ad:64:86:b8:11:3b:8e:ac:7c:3c:05: 1546 07:02:51:c2:a9:1c 1547 Authority Key Identifier: Key Identifier g(AKI): 1548 q66IrWSGuBE7jqx8PAUHAlHCqRw 1549 CRLNumber: 4 1550 Revoked Certificates: 1 1551 Serial Number: 1 1552 Revocation Date: Mon Jul 17 05:10:19 2006 GMT 1553 Serial Number: 2 1554 Revocation Date: Mon Jul 17 05:12:25 2006 GMT 1555 Serial Number: 4 1556 Revocation Date: Mon Jul 17 05:40:39 2006 GMT 1557 Signature: 1558 b2:5a:e8:7c:bd:a8:00:0f:03:1a:17:fd:40:2c:46: 1559 0e:d5:64:87:e7:e7:bc:10:7d:b6:3e:39:21:a9:12: 1560 f4:5a:d8:b8:d4:bd:57:1a:7d:2f:7c:0d:c6:4f:27: 1561 17:c8:0e:ae:8c:89:ff:00:f7:81:97:c3:a1:6a:0a: 1562 f7:d2:46:06:9a:d1:d5:4d:78:e1:b7:b0:58:4d:09: 1563 d6:7c:1e:a0:40:af:86:5d:8c:c9:48:f6:e6:20:2e: 1564 b9:b6:81:03:0b:51:ac:23:db:9f:c1:8e:d6:94:54: 1565 66:a5:68:52:ee:dd:0f:10:5d:21:b8:b8:19:ff:29: 1566 6f:51:2e:c8:74:5c:2a:d2:c5:fa:99:eb:c5:c2:a2: 1567 d0:96:fc:54:b3:ba:80:4b:92:7f:85:54:76:c9:12: 1568 cb:32:ea:1d:12:7b:f8:f9:a2:5c:a1:b1:06:8e:d8: 1569 c5:42:61:00:8c:f6:33:11:29:df:6e:b2:cc:c3:7c: 1570 d3:f3:0c:8d:5c:49:a5:fb:49:fd:e7:c4:73:68:0a: 1571 09:0e:6d:68:a9:06:52:3a:36:4f:19:47:83:59:da: 1572 02:5b:2a:d0:8a:7a:33:0a:d5:ce:be:b5:a2:7d:8d: 1573 59:a1:9d:ee:60:ce:77:3d:e1:86:9a:84:93:90:9f: 1574 34:a7:02:40:59:3a:a5:d1:18:fb:6f:fc:af:d4:02: 1575 d9 1577 Appendix C. Cryptographic Message Syntax Profile for RPKI Trust Anchor 1578 Material 1580 Using the Cryptographic Message Syntax (CMS) [RFC3852], a RPKI Trust 1581 Anchor Object (RTA) is a type of signed-data object. The general 1582 format of a CMS object is: 1584 ContentInfo ::= SEQUENCE { 1585 contentType ContentType, 1586 content [0] EXPLICIT ANY DEFINED BY contentType } 1588 ContentType ::= OBJECT IDENTIFIER 1590 As a RTA is a signed-data object, it uses the corresponding OID, 1591 1.2.840.113549.1.7.2. [RFC3852]. 1593 C.1. Signed-Data ContentType 1595 According to the CMS specification, the signed-data content type 1596 shall have ASN.1 type SignedData: 1598 SignedData ::= SEQUENCE { 1599 version CMSVersion, 1600 digestAlgorithms DigestAlgorithmIdentifiers, 1601 encapContentInfo EncapsulatedContentInfo, 1602 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1603 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 1604 signerInfos SignerInfos } 1606 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1608 SignerInfos ::= SET OF SignerInfo 1610 The elements of the signed-data content type are as follows: 1612 version 1613 The version is the syntax version number. It MUST be 3, 1614 corresponding to the signerInfo structure having version 1615 number 3. 1617 digestAlgorithms 1618 The digestAlgorithms set MUST include only SHA-256, the OID 1619 for which is 2.16.840.1.101.3.4.2.1. [RFC4055]. It MUST 1620 NOT contain any other algorithms. 1622 encapContentInfo 1623 This element is defined in Appendix C.1.1. 1625 certificates 1626 The certificates element MUST be included and MUST contain 1627 only the single PKI EE certificate needed to validate this 1628 CMS Object. The CertificateSet type is defined in section 1629 10 of [RFC3852] 1631 crls 1632 The crls element MUST be omitted. 1634 signerInfos 1635 This element is defined in Appendix C.1.2. 1637 C.1.1. encapContentInfo 1639 encapContentInfo is the signed content, consisting of a content type 1640 identifier and the content itself. 1642 EncapsulatedContentInfo ::= SEQUENCE { 1643 eContentType ContentType, 1644 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1646 ContentType ::= OBJECT IDENTIFIER 1648 The elements of this signed content type are as follows: 1650 eContentType 1651 The ContentType for an RTA is defined as id-ct- 1652 RPKITrustAnchor and has the numerical value of 1653 1.2.840.113549.1.9.16.1.33. 1655 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1656 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 1658 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 1660 id-ct-RPKITrustAnchor OBJECT IDENTIFIER ::= { id-ct 33 } 1662 eContent 1663 The content of an RTA is an RPKI self-signed CA certificate. 1664 It is formally defined as: 1666 id-ct-RPKITrustAnchor ::= Certificate 1668 The definition of Certificate is taken from [X.509]. 1670 C.1.2. signerInfos 1672 SignerInfo is defined under CMS as: 1674 SignerInfo ::= SEQUENCE { 1675 version CMSVersion, 1676 sid SignerIdentifier, 1677 digestAlgorithm DigestAlgorithmIdentifier, 1678 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1679 signatureAlgorithm SignatureAlgorithmIdentifier, 1680 signature SignatureValue, 1681 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1683 The content of the SignerInfo element are as follows: 1685 version 1686 The version number MUST be 3, corresponding with the choice 1687 of SubjectKeyIdentifier for the sid. 1689 sid 1690 The sid is defined as: 1692 SignerIdentifier ::= CHOICE { 1693 issuerAndSerialNumber IssuerAndSerialNumber, 1694 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1696 For a RTA, the sid MUST be a SubjectKeyIdentifier. 1698 digestAlgorithm 1699 The digestAlgorithm MUST be SHA-256, the OID for which is 1700 2.16.840.1.101.3.4.2.1. [RFC4055] 1702 signedAttrs 1703 The signedAttrs element is defined as: 1705 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1707 Attribute ::= SEQUENCE { 1708 attrType OBJECT IDENTIFIER, 1709 attrValues SET OF AttributeValue } 1711 AttributeValue ::= ANY 1713 The signedAttr element MUST be present and MUST include the 1714 content-type and message-digest attributes. The signer MAY 1715 also include the signing-time signed attribute, the binary- 1716 signing-time signed attribute, or both signed attributes. 1717 Other signed attributes that are deemed appropriate MAY also 1718 be included. The intent is to allow additional signed 1719 attributes to be included if a future need is identified. 1720 This does not cause an interoperability concern because 1721 unrecognized signed attributes are ignored by the relying 1722 party. 1724 The signedAttr MUST include only a single instance of any 1725 particular attribute. Additionally, even though the syntax 1726 allows for a SET OF AttributeValue, in a RTA the attrValues 1727 must consist of only a single AttributeValue. 1729 ContentType Attribute 1730 The ContentType attribute MUST be present. The 1731 attrType OID for the ContentType attribute is 1732 1.2.840.113549.1.9.3. 1734 The attrValues for the ContentType attribute in 1735 a RTA MUST be 1.2.840.113549.1.9.16.1.24 1736 (matching the eContentType in the 1737 EncapsulatedContentInfo). 1739 MessageDigest Attribute 1740 The MessageDigest attribute MUST be present. 1741 The attrType OID for the MessageDigest Attribute 1742 is 1.2.840.113549.1.9.4. 1744 The attrValues for the MessageDigest attribute 1745 contains the output of the digest algorithm 1746 applied to the content being signed, as 1747 specified in Section 11.1 of [RFC3852]. 1749 SigningTime Attribute 1750 The SigningTime attribute MAY be present. If it 1751 is present it MUST be ignored by the relying 1752 party. The presence of absence of the 1753 SigningTime attribute in no way affects the 1754 validation of the RTA. The attrType OID for the 1755 SigningTime attribute is 1.2.840.113549.1.9.5. 1757 The attrValues for the SigningTime attribute is 1758 defined as: 1760 SigningTime ::= Time 1762 Time ::= CHOICE { 1763 utcTime UTCTime, 1764 generalizedTime GeneralizedTime } 1766 The Time element specifies the time, based on 1767 the local system clock, at which the digital 1768 signature was applied to the content. 1770 BinarySigningTime Attribute 1771 The The BinarySigningTime attribute MAY be 1772 present. If it is present it MUST be ignored by 1773 the relying party. The presence of absence of 1774 the BinarySigningTime attribute in no way 1775 affects the validation of the RTA. The attrType 1776 OID for the SigningTime attribute is 1777 1.2.840.113549.1.9.16.2.46. 1779 The attrValues for the SigningTime attribute is 1780 defined as: 1782 BinarySigningTime ::= BinaryTime 1784 BinaryTime ::= INTEGER (0..MAX) 1786 The BinaryTime element specifies the time, based 1787 on the local system clock, at which the digital 1788 signature was applied to the content. 1790 signatureAlgorithm 1791 The signatureAlgorithm MUST be RSA (rsaEncryption), the OID 1792 for which is 1.2.840.113549.1.1.1.q 1794 signature 1795 The signature value is defined as: 1797 SignatureValue ::= OCTET STRING 1799 The signature characteristics are defined by the digest and 1800 signature algorithms. 1802 unsignedAttrs 1803 unsignedAttrs MUST be omitted. 1805 C.2. RTA Validation 1807 Before a relying party can use an RTA, the relying party must first 1808 validate the RTA by performing the following steps. 1810 1. Verify that the RTA syntax complies with this specification. In 1811 particular, verify the following: 1813 a. The contentType of the CMS object is SignedData (OID 1814 1.2.840.113549.1.7.2). 1816 b. The version of the SignedData object is 3. 1818 c. The digestAlgorithm in the SignedData object is SHA-256 (OID 1819 2.16.840.1.101.3.4.2.1). 1821 d. The certificates field in the SignedData object is present 1822 and contains an EE certificate whose Subject Key Identifier 1823 (SKI) matches the sid field of the SignerInfo object. 1825 e. The crls field in the SignedData object is omitted. 1827 f. The eContentType in the EncapsulatedContentInfo is id-ct- 1828 RPKITrustAnchor (OID 1.2.840.113549.1.9.16.1.[TBD]) 1830 g. The version of the SignerInfo is 3. 1832 h. The digestAlgorithm in the SignerInfo object is SHA-256 (OID 1833 2.16.840.1.101.3.4.2.1). 1835 i. The signatureAlgorithm in the SignerInfo object is RSA (OID 1836 1.2.840.113549.1.1.1). 1838 j. The signedAttrs field in the SignerInfo object is present and 1839 contains both the ContentType attribute (OID 1840 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 1841 1.2.840.113549.1.9.4). 1843 k. The unsignedAttrs field in the SignerInfo object is omitted. 1845 2. Use the public key in the EE certificate to verify the signature 1846 on the RTA. 1848 3. Verify that the EE certificate is a valid end-entity certificate 1849 in the Trust Anchor PKI by validating that the PKI CA certificate 1850 issued this EE certificate, and the PKI CA's CRL has not revoked 1851 the EE certificate, and that the PKI CA's CRL is valid. 1853 Authors' Addresses 1855 Geoff Huston 1856 Asia Pacific Network Information Centre 1858 Email: gih@apnic.net 1859 URI: http://www.apnic.net 1861 George Michaelson 1862 Asia Pacific Network Information Centre 1864 Email: ggm@apnic.net 1865 URI: http://www.apnic.net 1867 Robert Loomans 1868 Asia Pacific Network Information Centre 1870 Email: robertl@apnic.net 1871 URI: http://www.apnic.net 1873 Full Copyright Statement 1875 Copyright (C) The IETF Trust (2008). 1877 This document is subject to the rights, licenses and restrictions 1878 contained in BCP 78, and except as set forth therein, the authors 1879 retain all their rights. 1881 This document and the information contained herein are provided on an 1882 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1883 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1884 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1885 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1886 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1887 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1889 Intellectual Property 1891 The IETF takes no position regarding the validity or scope of any 1892 Intellectual Property Rights or other rights that might be claimed to 1893 pertain to the implementation or use of the technology described in 1894 this document or the extent to which any license under such rights 1895 might or might not be available; nor does it represent that it has 1896 made any independent effort to identify any such rights. Information 1897 on the procedures with respect to rights in RFC documents can be 1898 found in BCP 78 and BCP 79. 1900 Copies of IPR disclosures made to the IETF Secretariat and any 1901 assurances of licenses to be made available, or the result of an 1902 attempt made to obtain a general license or permission for the use of 1903 such proprietary rights by implementers or users of this 1904 specification can be obtained from the IETF on-line IPR repository at 1905 http://www.ietf.org/ipr. 1907 The IETF invites any interested party to bring to its attention any 1908 copyrights, patents or patent applications, or other proprietary 1909 rights that may cover technology that may be required to implement 1910 this standard. Please address the information to the IETF at 1911 ietf-ipr@ietf.org. 1913 Acknowledgment 1915 Funding for the RFC Editor function is provided by the IETF 1916 Administrative Support Activity (IASA).