| < draft-ietf-sidr-res-certs-21.txt | draft-ietf-sidr-res-certs-22.txt > | |||
|---|---|---|---|---|
| SIDR G. Huston | SIDR G. Huston | |||
| Internet-Draft G. Michaelson | Internet-Draft G. Michaelson | |||
| Intended status: Standards Track R. Loomans | Intended status: Standards Track R. Loomans | |||
| Expires: June 6, 2011 APNIC | Expires: November 7, 2011 APNIC | |||
| December 3, 2010 | May 6, 2011 | |||
| A Profile for X.509 PKIX Resource Certificates | A Profile for X.509 PKIX Resource Certificates | |||
| draft-ietf-sidr-res-certs-21 | draft-ietf-sidr-res-certs-22 | |||
| Abstract | Abstract | |||
| This document defines a standard profile for X.509 certificates for | This document defines a standard profile for X.509 certificates for | |||
| the purposes of supporting validation of assertions of "right-of-use" | the purposes of supporting validation of assertions of "right-of-use" | |||
| of Resources (INRs). The certificates issued under this profile are | of Internet Number Resources (INRs). The certificates issued under | |||
| used to convey the Issuer's authorisation of the Subject to be | this profile are used to convey the Issuer's authorisation of the | |||
| regarded as the current holder of a "right-of-use" of the INRs that | Subject to be regarded as the current holder of a "right-of-use" of | |||
| are described in the certificate. This document contains the | the INRs that are described in the certificate. This document | |||
| normative specification of Certificate and Certificate Revocation | contains the normative specification of Certificate and Certificate | |||
| List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). | Revocation List (CRL) syntax in the Resource Public Key | |||
| The document also specifies profiles for the format of certificate | Infrastructure (RPKI). The document also specifies profiles for the | |||
| requests. The document also specifies the Relying Party RPKI | format of certificate requests. The document also specifies the | |||
| certificate path validation procedure. | Relying Party RPKI certificate path validation procedure. | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on June 6, 2011. | This Internet-Draft will expire on November 7, 2011. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| skipping to change at page 2, line 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
| 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2. Describing Resources in Certificates . . . . . . . . . . . . . 5 | 2. Describing Resources in Certificates . . . . . . . . . . . . . 5 | |||
| 3. End-Entity (EE) Certificates and Signing Functions in the | 3. End-Entity (EE) Certificates and Signing Functions in the | |||
| RPKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | RPKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. Resource Certificates . . . . . . . . . . . . . . . . . . . . 6 | 4. Resource Certificates . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.2. Serial number . . . . . . . . . . . . . . . . . . . . . . 6 | 4.2. Serial number . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.3. Signature Algorithm . . . . . . . . . . . . . . . . . . . 6 | 4.3. Signature Algorithm . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.5. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4.5. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.6. Valid From . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4.6. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.7. Valid To . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4.6.1. notBefore . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4.8. Subject Public Key Info . . . . . . . . . . . . . . . . . 8 | 4.6.2. notAfter . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4.9. Resource Certificate Extensions . . . . . . . . . . . . . 8 | 4.7. Subject Public Key Info . . . . . . . . . . . . . . . . . 8 | |||
| 4.9.1. Basic Constraints . . . . . . . . . . . . . . . . . . 8 | 4.8. Resource Certificate Extensions . . . . . . . . . . . . . 8 | |||
| 4.9.2. Subject Key Identifier . . . . . . . . . . . . . . . . 8 | 4.8.1. Basic Constraints . . . . . . . . . . . . . . . . . . 8 | |||
| 4.9.3. Authority Key Identifier . . . . . . . . . . . . . . . 9 | 4.8.2. Subject Key Identifier . . . . . . . . . . . . . . . . 9 | |||
| 4.9.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 9 | 4.8.3. Authority Key Identifier . . . . . . . . . . . . . . . 9 | |||
| 4.9.5. Extended Key Usage . . . . . . . . . . . . . . . . . . 9 | 4.8.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 4.9.6. CRL Distribution Points . . . . . . . . . . . . . . . 9 | 4.8.5. Extended Key Usage . . . . . . . . . . . . . . . . . . 9 | |||
| 4.9.7. Authority Information Access . . . . . . . . . . . . . 10 | 4.8.6. CRL Distribution Points . . . . . . . . . . . . . . . 10 | |||
| 4.9.8. Subject Information Access . . . . . . . . . . . . . . 11 | 4.8.7. Authority Information Access . . . . . . . . . . . . . 10 | |||
| 4.9.9. Certificate Policies . . . . . . . . . . . . . . . . . 12 | 4.8.8. Subject Information Access . . . . . . . . . . . . . . 11 | |||
| 4.9.10. IP Resources . . . . . . . . . . . . . . . . . . . . . 12 | 4.8.9. Certificate Policies . . . . . . . . . . . . . . . . . 12 | |||
| 4.9.11. AS Resources . . . . . . . . . . . . . . . . . . . . . 12 | 4.8.10. IP Resources . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 4.8.11. AS Resources . . . . . . . . . . . . . . . . . . . . . 12 | ||||
| 5. Resource Certificate Revocation Lists . . . . . . . . . . . . 13 | 5. Resource Certificate Revocation Lists . . . . . . . . . . . . 13 | |||
| 6. Resource Certificate Requests . . . . . . . . . . . . . . . . 13 | 6. Resource Certificate Requests . . . . . . . . . . . . . . . . 13 | |||
| 6.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 13 | 6.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 6.1.1. PKCS#10 Resource Certificate Request Template | 6.1.1. PKCS#10 Resource Certificate Request Template | |||
| Fields . . . . . . . . . . . . . . . . . . . . . . . . 14 | Fields . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 6.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 14 | 6.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 6.2.1. CRMF Resource Certificate Request Template Fields . . 15 | 6.2.1. CRMF Resource Certificate Request Template Fields . . 15 | |||
| 6.2.2. Resource Certificate Request Control Fields . . . . . 16 | 6.2.2. Resource Certificate Request Control Fields . . . . . 16 | |||
| 6.3. Certificate Extension Attributes in Certificate | 6.3. Certificate Extension Attributes in Certificate | |||
| Requests . . . . . . . . . . . . . . . . . . . . . . . . . 16 | Requests . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 7. Resource Certificate Validation . . . . . . . . . . . . . . . 17 | 7. Resource Certificate Validation . . . . . . . . . . . . . . . 17 | |||
| 7.1. Resource Extension Validation . . . . . . . . . . . . . . 17 | 7.1. Resource Extension Validation . . . . . . . . . . . . . . 17 | |||
| 7.2. Resource Certification Path Validation . . . . . . . . . . 18 | 7.2. Resource Certification Path Validation . . . . . . . . . . 18 | |||
| 8. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 8. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 | 9. Operational Considerations for Profile Agility . . . . . . . . 22 | |||
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | |||
| 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 | |||
| Appendix A. Example Resource Certificate . . . . . . . . . . . . 24 | 13.2. Informative References . . . . . . . . . . . . . . . . . . 26 | |||
| Appendix B. Example Certificate Revocation List . . . . . . . . . 27 | Appendix A. Example Resource Certificate . . . . . . . . . . . . 27 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 | Appendix B. Example Certificate Revocation List . . . . . . . . . 30 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 | ||||
| 1. Introduction | 1. Introduction | |||
| This document defines a standard profile for X.509 certificates | This document defines a standard profile for X.509 certificates | |||
| [X.509] for use in the context of certification of Internet Number | [X.509] for use in the context of certification of Internet Number | |||
| Resources (INRs), i.e., IP Addresses and Autonomous System (AS) | Resources (INRs), i.e., IP Addresses and Autonomous System (AS) | |||
| Numbers. Such certificates are termed "Resource Certificates". A | Numbers. Such certificates are termed "Resource Certificates". A | |||
| Resource Certificate is a certificate that conforms to the PKIX | Resource Certificate is a certificate that conforms to the PKIX | |||
| profile [RFC5280], and that conforms to the constraints specified in | profile [RFC5280], and that conforms to the constraints specified in | |||
| this profile. A Resource Certificate attests that the Issuer has | this profile. A Resource Certificate attests that the Issuer has | |||
| skipping to change at page 4, line 42 ¶ | skipping to change at page 4, line 42 ¶ | |||
| certificate subject's key to the INRs enumerated in the certificate. | certificate subject's key to the INRs enumerated in the certificate. | |||
| One or two critical extensions, the IP Address Delegation or AS | One or two critical extensions, the IP Address Delegation or AS | |||
| Identifier Delegation Extensions [RFC3779], enumerate the INRs that | Identifier Delegation Extensions [RFC3779], enumerate the INRs that | |||
| were allocated or assigned by the Issuer to the Subject. | were allocated or assigned by the Issuer to the Subject. | |||
| RP validation of a Resource Certificate is performed in the manner | RP validation of a Resource Certificate is performed in the manner | |||
| specified in Section 7.1. This validation procedure differs from | specified in Section 7.1. This validation procedure differs from | |||
| that described in section 6 of [RFC5280], such that: | that described in section 6 of [RFC5280], such that: | |||
| o additional validation processing imposed by the INR extensions is | o additional validation processing imposed by the INR extensions is | |||
| required, | required, | |||
| o a conformation of a public key match between the CRL issuer and | o a confirmation of a public key match between the CRL issuer and | |||
| the Resource Certificate issuer is required, and | the Resource Certificate issuer is required, and | |||
| o the Resource Certificate is required to conform to this profile. | o the Resource Certificate is required to conform to this profile. | |||
| This profile defines those fields that are used in a Resource | This profile defines those fields that are used in a Resource | |||
| Certificate that MUST be present for the certificate to be valid. | Certificate that MUST be present for the certificate to be valid. | |||
| Any extensions not explicitly mentioned MUST be absent. The same | Any extensions not explicitly mentioned MUST be absent. The same | |||
| applies to the CRLs used in the RPKI, that are also profiled in this | applies to the CRLs used in the RPKI, that are also profiled in this | |||
| document. A CA conforming to the RPKI CP MUST issue certificates and | document. A CA conforming to the RPKI CP MUST issue certificates and | |||
| CRLs consistent with this profile. | CRLs consistent with this profile. | |||
| 1.1. Terminology | 1.1. Terminology | |||
| It is assumed that the reader is familiar with the terms and concepts | It is assumed that the reader is familiar with the terms and concepts | |||
| described in "Internet X.509 Public Key Infrastructure Certificate | described in "Internet X.509 Public Key Infrastructure Certificate | |||
| and Certificate Revocation List (CRL) Profile" [RFC5280], and "X.509 | and Certificate Revocation List (CRL) Profile" [RFC5280], and "X.509 | |||
| Extensions for IP Addresses and AS Identifiers" [RFC3779]. | Extensions for IP Addresses and AS Identifiers" [RFC3779]. | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119. | document are to be interpreted as described in [RFC2119]. | |||
| 2. Describing Resources in Certificates | 2. Describing Resources in Certificates | |||
| The framework for describing an association between the Subject of a | The framework for describing an association between the Subject of a | |||
| certificate and the INRs currently under the Subject's control is | certificate and the INRs currently under the Subject's control is | |||
| described in [RFC3779]. This profile further requires that: | described in [RFC3779]. This profile further requires that: | |||
| o Every Resource Certificate MUST contain either the IP Address | o Every Resource Certificate MUST contain either the IP Address | |||
| Delegation or the Autonomous System Identifier Delegation | Delegation or the Autonomous System Identifier Delegation | |||
| extension, or both. | extension, or both. | |||
| skipping to change at page 7, line 12 ¶ | skipping to change at page 7, line 12 ¶ | |||
| The algorithm used in this profile is specified in | The algorithm used in this profile is specified in | |||
| [ID.sidr-rpki-algs]. | [ID.sidr-rpki-algs]. | |||
| 4.4. Issuer | 4.4. Issuer | |||
| The value of this field is a valid X.501 distinguished name. | The value of this field is a valid X.501 distinguished name. | |||
| An Issuer name MUST contain one instance of the Common Name attribute | An Issuer name MUST contain one instance of the Common Name attribute | |||
| and MAY contain one instance of the Serial Number attribute. If both | and MAY contain one instance of the Serial Number attribute. If both | |||
| attributes are present, it is RECOMMENDED that they appear as a set. | attributes are present, it is RECOMMENDED that they appear as a set. | |||
| The Common Name attribute MUST be encoded as a printable string. | The Common Name attribute MUST be encoded using the ASN.1 type | |||
| Issuer names are not intended to be descriptive of the identity of | PrintableString [X.680]. Issuer names are not intended to be | |||
| Issuer. | descriptive of the identity of Issuer. | |||
| The RPKI does not rely on Issuer names being globally unique, for | The RPKI does not rely on Issuer names being globally unique, for | |||
| reasons of security. However, it is RECOMMENDED that Issuer names be | reasons of security. However, it is RECOMMENDED that Issuer names be | |||
| generated in a fashion that minimizes the likelihood of collisions. | generated in a fashion that minimizes the likelihood of collisions. | |||
| See Section 8 for (non-normative) suggested name generation | See Section 8 for (non-normative) suggested name generation | |||
| mechanisms that fulfill this recommendation. | mechanisms that fulfill this recommendation. | |||
| 4.5. Subject | 4.5. Subject | |||
| The value of this field is a valid X.501 distinguished name, and is | The value of this field is a valid X.501 distinguished name | |||
| subject to the same constraints as the Issuer name. | [RFC4514], and is subject to the same constraints as the Issuer name. | |||
| In the RPKI the Subject name is determined by the Issuer, not | In the RPKI the Subject name is determined by the Issuer, not | |||
| proposed by the subject [ID.sidr-repos-struct]. Each distinct | proposed by the subject [ID.sidr-repos-struct]. Each distinct | |||
| subordinate CA and EE certified by the Issuer MUST be identified | subordinate CA and EE certified by the Issuer MUST be identified | |||
| using a Subject name that is unique per Issuer. In this context | using a Subject name that is unique per Issuer. In this context | |||
| "distinct" is defined as an entity and a given public key. An Issuer | "distinct" is defined as an entity and a given public key. An Issuer | |||
| SHOULD use a different Subject name if the Subject's key pair has | SHOULD use a different Subject name if the Subject's key pair has | |||
| changed (i.e., when the CA issues a certificate as part of re-keying | changed (i.e., when the CA issues a certificate as part of re-keying | |||
| the Subject.) Subject names are not intended to be descriptive of | the Subject.) Subject names are not intended to be descriptive of | |||
| the identity of Subject. | the identity of Subject. | |||
| 4.6. Valid From | 4.6. Validity | |||
| The "Valid From" time SHOULD be no earlier than the time of | The certificate validity period is represented as a SEQUENCE of two | |||
| dates: the date on which the certificate validity period begins | ||||
| (notBefore) and the date on which the certificate validity period | ||||
| ends (notAfter). | ||||
| While a CA is typically advised against issuing a certificate with a | ||||
| validity period that spans a greater period of time than the validity | ||||
| period of the CA's certificate that will be used to validate the | ||||
| issued certificate, in the context of this profile, a CA MAY have | ||||
| valid grounds to issue a subordinate certificate with a validity | ||||
| period that exceeds the validity period of the CA's certificate. | ||||
| 4.6.1. notBefore | ||||
| The "notBefore" time SHOULD be no earlier than the time of | ||||
| certificate generation. | certificate generation. | |||
| In the RPKI it is valid for a certificate to have a value for this | In the RPKI it is valid for a certificate to have a value for this | |||
| field that pre-dates the same field value in any superior | field that pre-dates the same field value in any superior | |||
| certificate. Relying Parties SHOULD NOT attempt to infer from this | certificate. Relying Parties SHOULD NOT attempt to infer from this | |||
| time information that a certificate was valid at a time in the past, | time information that a certificate was valid at a time in the past, | |||
| or will be valid at a time in the future, as the scope of an RP's | or will be valid at a time in the future, as the scope of an RP's | |||
| test of validity of a certificate refers specifically to validity at | test of validity of a certificate refers specifically to validity at | |||
| the current time. | the current time. | |||
| 4.7. Valid To | 4.6.2. notAfter | |||
| The Valid To time represents the anticipated lifetime of the current | The "notAfter" time represents the anticipated lifetime of the | |||
| resource allocation or assignment arrangement between the Issuer and | current resource allocation or assignment arrangement between the | |||
| the Subject. | Issuer and the Subject. | |||
| It is valid for a certificate to have a value for this field that | It is valid for a certificate to have a value for this field that | |||
| post-dates the same field value in any superior certificate. The | post-dates the same field value in any superior certificate. The | |||
| same caveats apply to RP's assumptions relating to the certificate's | same caveats apply to RP's assumptions relating to the certificate's | |||
| validity at any time other than the current time. | validity at any time other than the current time. | |||
| While a CA is typically advised against issuing a certificate with a | 4.7. Subject Public Key Info | |||
| validity interval that exceeds the validity interval of the CA's | ||||
| certificate that will be used to validate the issued certificate, in | ||||
| the context of this profile, a CA MAY have valid grounds to issue a | ||||
| certificate with a validity interval that exceeds the validity | ||||
| interval of its certificate. | ||||
| 4.8. Subject Public Key Info | ||||
| The algorithm used in this profile is specified in | The algorithm used in this profile is specified in | |||
| [ID.sidr-rpki-algs]. | [ID.sidr-rpki-algs]. | |||
| 4.9. Resource Certificate Extensions | 4.8. Resource Certificate Extensions | |||
| The following X.509 V3 extensions MUST be present in a conforming | The following X.509 V3 extensions MUST be present in a conforming | |||
| Resource Certificate, except where explicitly noted otherwise. Each | Resource Certificate, except where explicitly noted otherwise. Each | |||
| extension in a resource certificate is designated as either critical | extension in a resource certificate is designated as either critical | |||
| or non-critical. A certificate-using system MUST reject the | or non-critical. A certificate-using system MUST reject the | |||
| certificate if it encounters a critical extension it does not | certificate if it encounters a critical extension it does not | |||
| recognise; however, a non-critical extension MAY be ignored if it is | recognise; however, a non-critical extension MAY be ignored if it is | |||
| not recognised [RFC5280]. | not recognised [RFC5280]. | |||
| 4.9.1. Basic Constraints | 4.8.1. Basic Constraints | |||
| The Basic Constraints extension field is a critical extension in the | The Basic Constraints extension field is a critical extension in the | |||
| Resource Certificate profile, and MUST be present when the Subject is | Resource Certificate profile, and MUST be present when the Subject is | |||
| a CA, and MUST NOT be present otherwise. | a CA, and MUST NOT be present otherwise. | |||
| The Issuer determines whether the "cA" boolean is set. | The Issuer determines whether the "cA" boolean is set. | |||
| The Path Length Constraint is not specified for RPKI certificates, | The Path Length Constraint is not specified for RPKI certificates, | |||
| and MUST NOT be present. | and MUST NOT be present. | |||
| 4.9.2. Subject Key Identifier | 4.8.2. Subject Key Identifier | |||
| This extension MUST appear in all Resource Certificates. This | This extension MUST appear in all Resource Certificates. This | |||
| extension is non-critical. | extension is non-critical. | |||
| The Key Identifier used for resource certificates is the 160-bit | The Key Identifier used for resource certificates is the 160-bit | |||
| SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the | SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the | |||
| Subject Public Key, as described in Section 4.2.1.2 of [RFC5280]. | Subject Public Key, as described in Section 4.2.1.2 of [RFC5280]. | |||
| 4.9.3. Authority Key Identifier | 4.8.3. Authority Key Identifier | |||
| This extension MUST appear in all Resource Certificates, with the | This extension MUST appear in all Resource Certificates, with the | |||
| exception of a CA who issues a "self-signed" certificate. In a self- | exception of a CA who issues a "self-signed" certificate. In a self- | |||
| signed certificate, a CA MAY include this extension, and set it equal | signed certificate, a CA MAY include this extension, and set it equal | |||
| to the Subject Key Identifier. The authorityCertIssuer and | to the Subject Key Identifier. The authorityCertIssuer and | |||
| authorityCertSerialNumber fields MUST NOT be present. This extension | authorityCertSerialNumber fields MUST NOT be present. This extension | |||
| is non-critical. | is non-critical. | |||
| The Key Identifier used for resource certificates is the 160-bit | The Key Identifier used for resource certificates is the 160-bit | |||
| SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the | SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the | |||
| Issuer's public key, as described in Section 4.2.1.1 of [RFC5280]. | Issuer's public key, as described in Section 4.2.1.1 of [RFC5280]. | |||
| 4.9.4. Key Usage | 4.8.4. Key Usage | |||
| This extension is a critical extension and MUST be present. | This extension is a critical extension and MUST be present. | |||
| In certificates issued to Certification Authorities only the | In certificates issued to Certification Authorities only the | |||
| keyCertSign and CRLSign bits are set to TRUE, and these MUST be the | keyCertSign and CRLSign bits are set to TRUE, and these MUST be the | |||
| only bits set to TRUE. | only bits set to TRUE. | |||
| In EE certificates the digitalSignature bit MUST be set to TRUE and | In EE certificates the digitalSignature bit MUST be set to TRUE and | |||
| MUST be the only bit set to TRUE. | MUST be the only bit set to TRUE. | |||
| 4.9.5. Extended Key Usage | 4.8.5. Extended Key Usage | |||
| The Extended Key Usage (EKU) extension MUST NOT appear in any CA | The Extended Key Usage (EKU) extension MUST NOT appear in any CA | |||
| certificate in the RPKI. This extension also MUST NOT appear in EE | certificate in the RPKI. This extension also MUST NOT appear in EE | |||
| certificates used to verify RPKI objects (e.g., ROAs or manifests. | certificates used to verify RPKI objects (e.g., ROAs or manifests. | |||
| The extension MUST NOT be marked critical. | The extension MUST NOT be marked critical. | |||
| The EKU extension MAY appear in EE certificates issued to routers or | The EKU extension MAY appear in EE certificates issued to routers or | |||
| other devices. Permitted values for the EKU OIDs will be specified | other devices. Permitted values for the EKU OIDs will be specified | |||
| in Standards Track RFCs issued by other IETF working groups that | in Standards Track RFCs issued by other IETF working groups that | |||
| adopt the RPKI profile and that identify application-specific | adopt the RPKI profile and that identify application-specific | |||
| requirements that motivate the use of such EKUs. | requirements that motivate the use of such EKUs. | |||
| 4.9.6. CRL Distribution Points | 4.8.6. CRL Distribution Points | |||
| This extension MUST be present, except in "self-signed" certificates, | This extension MUST be present, except in "self-signed" certificates, | |||
| and it is non-critical. In a self-signed certificate this extension | and it is non-critical. In a self-signed certificate this extension | |||
| MUST be omitted. | MUST be omitted. | |||
| In this profile, the scope of the CRL is specified to be all | In this profile, the scope of the CRL is specified to be all | |||
| certificates issued by this CA Issuer. | certificates issued by this CA Issuer. | |||
| The CRL Distribution Points (CRLDP) extension identifies the | The CRL Distribution Points (CRLDP) extension identifies the | |||
| location(s) of the CRL(s) associated with certificates issued by this | location(s) of the CRL(s) associated with certificates issued by this | |||
| skipping to change at page 10, line 28 ¶ | skipping to change at page 10, line 36 ¶ | |||
| contain a nameRelativeToCRLIssuer. The form of the generalName MUST | contain a nameRelativeToCRLIssuer. The form of the generalName MUST | |||
| be of type URI. | be of type URI. | |||
| The sequence of distributionPoint values MUST contain only a single | The sequence of distributionPoint values MUST contain only a single | |||
| DistributionPoint. The DistributionPoint MAY contain more than one | DistributionPoint. The DistributionPoint MAY contain more than one | |||
| URI value. An RSYNC URI [RFC5781] MUST be present in the | URI value. An RSYNC URI [RFC5781] MUST be present in the | |||
| DistributionPoint, and reference the most recent instance of this | DistributionPoint, and reference the most recent instance of this | |||
| Issuer's CRL. Other access form URIs MAY be used in addition to the | Issuer's CRL. Other access form URIs MAY be used in addition to the | |||
| RSYNC URI, representing alternate access mechanisms for this CRL. | RSYNC URI, representing alternate access mechanisms for this CRL. | |||
| 4.9.7. Authority Information Access | 4.8.7. Authority Information Access | |||
| In the context of the RPKI, this extension identifies the publication | In the context of the RPKI, this extension identifies the publication | |||
| point of the certificate of the issuer of the certificate in which | point of the certificate of the issuer of the certificate in which | |||
| the extension appears. In this profile a single reference to the | the extension appears. In this profile a single reference to the | |||
| publication point of the immediate superior certificate MUST be | publication point of the immediate superior certificate MUST be | |||
| present, except for a "self-signed" certificate, in which case the | present, except for a "self-signed" certificate, in which case the | |||
| extension MUST be omitted. This extension is non-critical. | extension MUST be omitted. This extension is non-critical. | |||
| This profile uses a URI form of object identification. The preferred | This profile uses a URI form of object identification. The preferred | |||
| URI access mechanisms is "rsync", and an RSYNC URI [RFC5781] MUST be | URI access mechanisms is "rsync", and an RSYNC URI [RFC5781] MUST be | |||
| skipping to change at page 11, line 5 ¶ | skipping to change at page 11, line 13 ¶ | |||
| included in the value sequence of this extension. | included in the value sequence of this extension. | |||
| A CA MUST use a persistent URL name scheme for CA certificates that | A CA MUST use a persistent URL name scheme for CA certificates that | |||
| it issues [ID.sidr-repos-struct]. This implies that a re-issued | it issues [ID.sidr-repos-struct]. This implies that a re-issued | |||
| certificate overwrites a previously issued certificate (to the same | certificate overwrites a previously issued certificate (to the same | |||
| Subject) in the publication repository. In this way certificates | Subject) in the publication repository. In this way certificates | |||
| subordinate to the re-issued (CA) certificate can maintain a constant | subordinate to the re-issued (CA) certificate can maintain a constant | |||
| Authority Information Access (AIA) extension pointer and thus need | Authority Information Access (AIA) extension pointer and thus need | |||
| not be re-issued when the parent certificate is re-issued. | not be re-issued when the parent certificate is re-issued. | |||
| 4.9.8. Subject Information Access | 4.8.8. Subject Information Access | |||
| In the context of the RPKI, this extension (SIA) identifies the | In the context of the RPKI, this extension (SIA) identifies the | |||
| publication point of products signed by the Subject of the | publication point of products signed by the Subject of the | |||
| certificate. | certificate. | |||
| 4.9.8.1. SIA for CA Certificates | 4.8.8.1. SIA for CA Certificates | |||
| This extension MUST be present, and is non-critical. | This extension MUST be present, and is non-critical. | |||
| This extension MUST have an instance of an accessMethod of id-ad- | This extension MUST have an instance of an accessMethod of id-ad- | |||
| caRepository, with an accessLocation form of a URI that MUST specify | caRepository, with an accessLocation form of a URI that MUST specify | |||
| an RSYNC URI [RFC5781]. This URI points to the directory containing | an RSYNC URI [RFC5781]. This URI points to the directory containing | |||
| all published material issued by this CA. i.e., all valid CA | all published material issued by this CA. i.e., all valid CA | |||
| certificates, published EE certificates, the current CRL, manifest | certificates, published EE certificates, the current CRL, manifest | |||
| and signed objects validated via EE certificates that have been | and signed objects validated via EE certificates that have been | |||
| issued by this CA [ID.sidr-repos-struct]. Other accessDescription | issued by this CA [ID.sidr-repos-struct]. Other accessDescription | |||
| elements with an accessMethod of id-ad-caRepository MAY be present. | elements with an accessMethod of id-ad-caRepository MAY be present. | |||
| In such cases, the accessLocation values describe alternate supported | In such cases, the accessLocation values describe alternate supported | |||
| URI access mechanisms for the same directory. The ordering of URIs | URI access mechanisms for the same directory. The ordering of URIs | |||
| in this accessDescription sequence reflect the CA's relative | in this accessDescription sequence reflect the CA's relative | |||
| preferences for access methods to be used by RPs, with he first | preferences for access methods to be used by RPs, with the first | |||
| element of the sequence being the most preferred by the CA. | element of the sequence being the most preferred by the CA. | |||
| This extension MUST have an instance of an AccessDescription with an | This extension MUST have an instance of an AccessDescription with an | |||
| accessMethod of id-ad-rpkiManifest, | accessMethod of id-ad-rpkiManifest, | |||
| id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } | id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } | |||
| id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 } | id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 } | |||
| with an RSYNC URI [RFC5781] form of accessLocation. The URI points | with an RSYNC URI [RFC5781] form of accessLocation. The URI points | |||
| to the CA's manifest of published objects [ID.sidr-rpki-manifests] as | to the CA's manifest of published objects [ID.sidr-rpki-manifests] as | |||
| an object URL. Other accessDescription elements MAY exist for the | an object URL. Other accessDescription elements MAY exist for the | |||
| id-ad-rpkiManifest accessMethod, where the accessLocation value | id-ad-rpkiManifest accessMethod, where the accessLocation value | |||
| indicates alternate access mechanisms for the same manifest object. | indicates alternate access mechanisms for the same manifest object. | |||
| 4.9.8.2. SIA for EE Certificates | 4.8.8.2. SIA for EE Certificates | |||
| This extension MUST be present, and is non-critical. | This extension MUST be present, and is non-critical. | |||
| This extension MUST have an instance of an accessMethod of id-ad- | This extension MUST have an instance of an accessMethod of id-ad- | |||
| signedObject, | signedObject, | |||
| id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 } | id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 } | |||
| with an accessLocation form of a URI that MUST include an RSYNC URI | with an accessLocation form of a URI that MUST include an RSYNC URI | |||
| [RFC5781]. This URI points to the signed object that is verified | [RFC5781]. This URI points to the signed object that is verified | |||
| using this EE certificate [ID.sidr-repos-struct]. Other | using this EE certificate [ID.sidr-repos-struct]. Other | |||
| accessDescription elements may exist for the id-ad-signedObject | accessDescription elements may exist for the id-ad-signedObject | |||
| accessMethod, where the accessLocation value indicates alternate URI | accessMethod, where the accessLocation value indicates alternate URI | |||
| access mechanisms for the same object, ordered in terms of the EE's | access mechanisms for the same object, ordered in terms of the EE's | |||
| relative preference for supported access mechanisms. | relative preference for supported access mechanisms. | |||
| Other AccessMethods MUST NOT be used for an EE certificates's SIA. | Other AccessMethods MUST NOT be used for an EE certificates's SIA. | |||
| 4.9.9. Certificate Policies | 4.8.9. Certificate Policies | |||
| This extension MUST be present, and MUST be marked critical. It MUST | This extension MUST be present, and MUST be marked critical. It MUST | |||
| include exactly one policy, as specified in the RPKI CP [ID.sidr-cp] | include exactly one policy, as specified in the RPKI CP [ID.sidr-cp] | |||
| 4.9.10. IP Resources | 4.8.10. IP Resources | |||
| Either the IP Resources extension, or the AS Resources extension, or | Either the IP Resources extension, or the AS Resources extension, or | |||
| both, MUST be present in all RPKI certificates, and if present, MUST | both, MUST be present in all RPKI certificates, and if present, MUST | |||
| be marked critical. | be marked critical. | |||
| This extension contains the list of IP address resources as per | This extension contains the list of IP address resources as per | |||
| [RFC3779]. The value may specify the "inherit" element for a | [RFC3779]. The value may specify the "inherit" element for a | |||
| particular AFI value. In the context of resource certificates | particular AFI value. In the context of resource certificates | |||
| describing public number resources for use in the public Internet, | describing public number resources for use in the public Internet, | |||
| the SAFI value MUST NOT be used. | the SAFI value MUST NOT be used. | |||
| This extension MUST either specify a non-empty set IP address | This extension MUST either specify a non-empty set IP address | |||
| records, or use the "inherit" setting to indicate that the IP address | records, or use the "inherit" setting to indicate that the IP address | |||
| resource set of this certificate is inherited from that of the | resource set of this certificate is inherited from that of the | |||
| certificate's issuer. | certificate's issuer. | |||
| 4.9.11. AS Resources | 4.8.11. AS Resources | |||
| Either the AS Resources extension, or the IP Resources extension, or | Either the AS Resources extension, or the IP Resources extension, or | |||
| both, MUST be present in all RPKI certificates, and if present, MUST | both, MUST be present in all RPKI certificates, and if present, MUST | |||
| be marked critical. | be marked critical. | |||
| This extension contains the list of AS number resources as per | This extension contains the list of AS number resources as per | |||
| [RFC3779], or may specify the "inherit" element. RDI values are NOT | [RFC3779], or may specify the "inherit" element. RDI values are NOT | |||
| supported in this profile and MUST NOT be used. | supported in this profile and MUST NOT be used. | |||
| This extension MUST either specify a non-empty set AS number records, | This extension MUST either specify a non-empty set AS number records, | |||
| or use the "inherit" setting to indicate that the AS number resource | or use the "inherit" setting to indicate that the AS number resource | |||
| set of this certificate is inherited from that of the certificate's | set of this certificate is inherited from that of the certificate's | |||
| issuer. | issuer. | |||
| 5. Resource Certificate Revocation Lists | 5. Resource Certificate Revocation Lists | |||
| skipping to change at page 15, line 4 ¶ | skipping to change at page 15, line 13 ¶ | |||
| that MAY appear in a CertificationRequest Object: | that MAY appear in a CertificationRequest Object: | |||
| signatureAlgorithm | signatureAlgorithm | |||
| The signatureAlgorithm value is specified in | The signatureAlgorithm value is specified in | |||
| [ID.sidr-rpki-algs]. | [ID.sidr-rpki-algs]. | |||
| 6.2. CRMF Profile | 6.2. CRMF Profile | |||
| This profile refines the Certificate Request Message Format (CRMF) | This profile refines the Certificate Request Message Format (CRMF) | |||
| specification in [RFC4211], as it relates to Resource Certificates. | specification in [RFC4211], as it relates to Resource Certificates. | |||
| A Certificate Request Message object, formatted according to the | A Certificate Request Message object, formatted according to the | |||
| CRMF, is passed to a CA as the initial step in certificate issuance. | CRMF, is passed to a CA as the initial step in certificate issuance. | |||
| With the exception of the SubjectPublicKeyinfo and the SIA extension | With the exception of the SubjectPublicKeyinfo and the SIA extension | |||
| request, the CA is permitted to alter any requested field when | request, the CA is permitted to alter any requested field when | |||
| issuing the certificate. | issuing the certificate. | |||
| 6.2.1. CRMF Resource Certificate Request Template Fields | 6.2.1. CRMF Resource Certificate Request Template Fields | |||
| This profile applies the following additional requirements to fields | This profile applies the following additional requirements to fields | |||
| that may appear in a Certificate Request Template: | that may appear in a Certificate Request Template: | |||
| version | version | |||
| This field SHOULD be omitted. If present, it MUST specify a | This field SHOULD be omitted. If present, it MUST specify a | |||
| request for a Version 3 Certificate. It | request for a Version 3 Certificate. | |||
| serialNumber | serialNumber | |||
| This field MUST be omitted. | This field MUST be omitted. | |||
| signingAlgorithm | signingAlgorithm | |||
| This field MUST be omitted. | This field MUST be omitted. | |||
| issuer | issuer | |||
| This MUST be omitted in this profile. | This MUST be omitted in this profile. | |||
| skipping to change at page 17, line 8 ¶ | skipping to change at page 17, line 13 ¶ | |||
| BasicConstraints SubjectType sub field, when specified. | BasicConstraints SubjectType sub field, when specified. | |||
| ExtendedKeyUsage | ExtendedKeyUsage | |||
| The CA MAY honour ExtendedKeyUsage extensions of keyCertSign | The CA MAY honour ExtendedKeyUsage extensions of keyCertSign | |||
| and cRLSign if present, as long as this is consistent with the | and cRLSign if present, as long as this is consistent with the | |||
| BasicConstraints SubjectType sub field, when specified. | BasicConstraints SubjectType sub field, when specified. | |||
| SubjectInformationAccess | SubjectInformationAccess | |||
| This field MUST be present, and the field value SHOULD be | This field MUST be present, and the field value SHOULD be | |||
| honoured by the CA if it conforms to the requirements set forth | honoured by the CA if it conforms to the requirements set forth | |||
| in Section 4.9.8. If the CA is unable to honour the requested | in Section 4.8.8. If the CA is unable to honour the requested | |||
| value for this field, then the CA MUST reject the Certificate | value for this field, then the CA MUST reject the Certificate | |||
| Request. | Request. | |||
| 7. Resource Certificate Validation | 7. Resource Certificate Validation | |||
| This section describes the Resource Certificate validation procedure. | This section describes the Resource Certificate validation procedure. | |||
| This refines the generic procedure described in section 6 of | This refines the generic procedure described in section 6 of | |||
| [RFC5280]. | [RFC5280]. | |||
| 7.1. Resource Extension Validation | 7.1. Resource Extension Validation | |||
| skipping to change at page 22, line 11 ¶ | skipping to change at page 22, line 19 ¶ | |||
| (The issuing CA may wish to be able to extract the | (The issuing CA may wish to be able to extract the | |||
| database key or subscriber ID from the commonName. Since | database key or subscriber ID from the commonName. Since | |||
| only the issuing CA would need to be able to parse the | only the issuing CA would need to be able to parse the | |||
| commonName, the database key and the source of entropy | commonName, the database key and the source of entropy | |||
| (e.g., a UUID) could be separated in any way that the CA | (e.g., a UUID) could be separated in any way that the CA | |||
| wanted, as long as it conformed to the rules for | wanted, as long as it conformed to the rules for | |||
| PrintableString. The separator could be a space | PrintableString. The separator could be a space | |||
| character, parenthesis, hyphen, slash, question mark, | character, parenthesis, hyphen, slash, question mark, | |||
| etc. | etc. | |||
| 9. Security Considerations | 9. Operational Considerations for Profile Agility | |||
| This profile requires that relying parties reject certificates or | ||||
| CRLs that do not conform to the profile. (Through the remainder of | ||||
| this section the term "certificate" is used to refer to both | ||||
| certificates and CRLs.) This includes certificates that contain | ||||
| extensions that are prohibited, but which are otherwise valid as per | ||||
| [RFC5280]. This means that any change in the profile (e.g., | ||||
| extensions, permitted attributes or optional fields, or field | ||||
| encodings) for certificates used in the RPKI will not be backward | ||||
| compatible. In a general PKI context this constraint probably would | ||||
| cause serious problems. In the RPKI, several factors minimize the | ||||
| difficulty of effecting changes of this sort. | ||||
| Note that the RPKI is unique in that every relying party (RP) | ||||
| requires access to every certificate and every CRL issued by the CAs | ||||
| in this system. An important update of the certificates and CRLs | ||||
| used in the RPKI must be supported by all CAs and RPs in the system, | ||||
| lest views of the RPKI data differ across RPs. Thus incremental | ||||
| changes require very careful coordination. It would not be | ||||
| appropriate to introduce a new extension, or authorize use of an | ||||
| extant, standard extension, for a security-relevant purpose on a | ||||
| piecemeal basis. | ||||
| One might imagine that the "critical" flag in X.509 certificate and | ||||
| CRL extensions could be used to ameliorate this problem. However, | ||||
| this solution is not comprehensive, and does not address the problem | ||||
| of adding a new, security-critical extension. (This is because such | ||||
| an extension needs to be supported universally, by all CAs and RPs.) | ||||
| Also, while some standard extensions can be marked either critical or | ||||
| non-critical, at the discretion of the issuer, not all have this | ||||
| property, i.e., some standard extensions are always non-critical. | ||||
| Moreover, there is no notion of criticality for attributes within a | ||||
| name or optional fields within a field or an extension. Thus the | ||||
| critical flag is not a solution to this problem. | ||||
| In typical PKI deployments there are few CAs and many RPs. However, | ||||
| in the RPKI, essentially every CA in the RPKI is also an RP. Thus | ||||
| the set of entities that will need to change in order to issue | ||||
| certificates under a new format is the same set of entities that will | ||||
| need to change to accept these new certificates. To the extent that | ||||
| this is literally true it says that CA/RP coordination for a change | ||||
| is tightly linked anyway. In reality there is an important exception | ||||
| to this general observation. Small ISPs and holders of provider- | ||||
| independent allocations are expected to use managed CA services, | ||||
| offered by Regional Internet Registries (RIRs) and potentially by | ||||
| wholesale Internet Service Providers (ISPs). This reduces the number | ||||
| of distinct CA implementations that are needed, and makes it easier | ||||
| to effect changes for certificate issuance. It seems very likely | ||||
| that these entities also will make use of RP software provided by | ||||
| their managed CA service provider, which reduces the number of | ||||
| distinct RP software implementations. Also note that many small ISPs | ||||
| (and holders of provider-independent allocations) employ default | ||||
| routes, and thus need not perform RP validation of RPKI data, | ||||
| eliminating these entities as RPs. | ||||
| Widely available PKI RP software does not cache large numbers of | ||||
| certificates and CRLs, an essential strategy for the RPKI. It does | ||||
| not process manifest or ROA data structures, essential elements of | ||||
| the RPKI repository system. Experience shows that such software | ||||
| deals poorly with revocation status data. Thus extant RP software is | ||||
| not adequate for the RPKI, although some open source tools (e.g., | ||||
| OpenSSL and cryptlib) can be used as building blocks for an RPKI RP | ||||
| implementation. Thus it is anticipated that RPs will make use of | ||||
| software designed specifically for the RPKI environment, and | ||||
| available from a limited number of open sources. Several RIRs and | ||||
| two companies are providing such software today. Thus it is feasible | ||||
| to coordinate change to this software among the small number of | ||||
| developers/maintainers. | ||||
| If the resource certificate profile is changed in the future, e.g., | ||||
| by adding a new extension or changing the allowed set of name | ||||
| attributes or encoding of these attributes, the following procedure | ||||
| will be employed to effect deployment in the RPKI. The model is | ||||
| analogous to that described in [ID.sidr-algorithm-agility], but is | ||||
| simpler. | ||||
| A new document will be issued as an update to this RFC. The CP for | ||||
| the RPKI [ID.sidr-cp] will be updated to reference the new | ||||
| certificate profile. The new CP will define a new policy OID for | ||||
| certificates issued under the new certificate profile. The updated | ||||
| CP also will define a timeline for transition to the new certificate | ||||
| (CRL) format. This timeline will define 3 phases and associated | ||||
| dates: | ||||
| 1. At the end of phase 1, all RPKI CAs MUST be capable of issuing | ||||
| certificates under the new profile, if requested by a subject. | ||||
| Any certificate issued under the new format will contain the | ||||
| new policy OID. | ||||
| 2. During phase 2 CAs MUST issue certificates under the new | ||||
| profile, and these certificates MUST co-exist with | ||||
| certificates issued under the old format. (CAs will continue | ||||
| to issue certificates under the old OID/format as well.) The | ||||
| old and new certificates MUST be identical, except for the | ||||
| policy OID and any new extensions, encodings, etc. The new | ||||
| certificates, and associated signed objects, will coexist in | ||||
| the RPKI repository system during this phase, analogous to | ||||
| what is required by an algorithm transition for the RPKI | ||||
| [ID.sidr-algorithm-agility]. Relying parties MAY make use of | ||||
| the old or the new certificate formats when processing signed | ||||
| objects retrieved from the RPKI repository system. During | ||||
| this phase, a relying party that elects to process both | ||||
| formats will acquire the same values for all certificate | ||||
| fields that overlap between the old and new formats. Thus if | ||||
| either certificate format is verifiable, the relying party | ||||
| accepts the data from that certificate. This allows CAs to | ||||
| issue certificates under the new format before all relying | ||||
| parties are prepared to process that format. | ||||
| 3. At the beginning of phase 3, all relying parties MUST be | ||||
| capable of processing certificates under the new format. | ||||
| During this phase CAs will issue new certificates ONLY under | ||||
| the new format. During this phase, certificates issued under | ||||
| the old OID will be replaced with certificates containing the | ||||
| new policy OID. The repository system will no longer require | ||||
| matching old and new certificates under the different formats. | ||||
| At the end of phase 3, all certificates under the old OID will have | ||||
| been replaced. The resource certificate profile RFC will be replaced | ||||
| to remove support for the old certificate format, and the CP will be | ||||
| replaced to remove reference to the old policy OID and to the old | ||||
| resource certificate profile RFC. The system will have returned to a | ||||
| new, steady state. | ||||
| 10. Security Considerations | ||||
| The Security Considerations of [RFC5280] and [RFC3779] apply to | The Security Considerations of [RFC5280] and [RFC3779] apply to | |||
| Resource Certificates. The Security Considerations of [RFC2986] and | Resource Certificates. The Security Considerations of [RFC2986] and | |||
| [RFC4211] apply to Resource Certificate certification requests. | [RFC4211] apply to Resource Certificate certification requests. | |||
| A Resource Certificate PKI cannot in and of itself resolve any forms | A Resource Certificate PKI cannot in and of itself resolve any forms | |||
| of ambiguity relating to uniqueness of assertions of rights of use in | of ambiguity relating to uniqueness of assertions of rights of use in | |||
| the event that two or more valid certificates encompass the same | the event that two or more valid certificates encompass the same | |||
| resource. If the issuance of resource certificates is aligned to the | resource. If the issuance of resource certificates is aligned to the | |||
| status of resource allocations and assignments then the information | status of resource allocations and assignments then the information | |||
| skipping to change at page 22, line 42 ¶ | skipping to change at page 25, line 32 ¶ | |||
| using separate validation paths for a certificate and the | using separate validation paths for a certificate and the | |||
| corresponding CRL. If there are subject name collisions in the RPKI | corresponding CRL. If there are subject name collisions in the RPKI | |||
| as a result of CAs not following the guidelines provided here | as a result of CAs not following the guidelines provided here | |||
| relating to ensuring sufficient entropy in constructing subject | relating to ensuring sufficient entropy in constructing subject | |||
| names, and this is combined with the situation that an RP uses an | names, and this is combined with the situation that an RP uses an | |||
| implementation of validation path construction that is not in | implementation of validation path construction that is not in | |||
| conformance with this RPKI profile, then it is possible that the | conformance with this RPKI profile, then it is possible that the | |||
| subject name collisions can cause an RP to conclude that an otherwise | subject name collisions can cause an RP to conclude that an otherwise | |||
| valid certificate has been revoked. | valid certificate has been revoked. | |||
| 10. IANA Considerations | 11. IANA Considerations | |||
| [Note to IANA, to be removed prior to publication: there are no IANA | [Note to IANA, to be removed prior to publication: there are no IANA | |||
| considerations stated in this document.] | considerations stated in this document.] | |||
| 11. Acknowledgements | 12. Acknowledgements | |||
| The authors would like to particularly acknowledge the valued | The authors would like to particularly acknowledge the valued | |||
| contribution from Stephen Kent in reviewing this document and | contribution from Stephen Kent in reviewing this document and | |||
| proposing numerous sections of text that have been incorporated into | proposing numerous sections of text that have been incorporated into | |||
| the text. The authors also acknowledge the contributions of Sandy | the text. The authors also acknowledge the contributions of Sandy | |||
| Murphy, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo Patara | Murphy, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo Patara | |||
| and Rob Austein in the preparation and subsequent review of this | and Rob Austein in the preparation and subsequent review of this | |||
| document. The document also reflects review comments received from | document. The document also reflects review comments received from | |||
| Roque Gagliano, Sean Turner and David Cooper. | Roque Gagliano, Sean Turner and David Cooper. | |||
| 12. References | 13. References | |||
| 13.1. Normative References | ||||
| 12.1. Normative References | ||||
| [ID.sidr-cp] | [ID.sidr-cp] | |||
| Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate | Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate | |||
| Policy (CP) for the Resource PKI (RPKI)", Work in | Policy (CP) for the Resource PKI (RPKI)", Work in | |||
| progress: Internet Drafts draft-ietf-sidr-c-13.txt, | progress: Internet Drafts draft-ietf-sidr-c-13.txt, | |||
| September 2010. | September 2010. | |||
| [ID.sidr-rpki-algs] | [ID.sidr-rpki-algs] | |||
| Huston, G., "A Profile for Algorithms and Key Sizes for | Huston, G., "A Profile for Algorithms and Key Sizes for | |||
| use in the Resource Public Key Infrastructure", Work in | use in the Resource Public Key Infrastructure", Work in | |||
| progress: Internet | progress: Internet | |||
| Drafts draft-ietf-sidr-rpki-algs-00.txt, August 2009. | Drafts draft-ietf-sidr-rpki-algs-00.txt, August 2009. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | ||||
| [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification | [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification | |||
| Request Syntax Specification Version 1.7", RFC 2986, | Request Syntax Specification Version 1.7", RFC 2986, | |||
| November 2000. | November 2000. | |||
| [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP | [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP | |||
| Addresses and AS Identifiers", RFC 3779, June 2004. | Addresses and AS Identifiers", RFC 3779, June 2004. | |||
| [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure | [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure | |||
| Certificate Request Message Format (CRMF)", RFC 4211, | Certificate Request Message Format (CRMF)", RFC 4211, | |||
| September 2005. | September 2005. | |||
| [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
| Housley, R., and W. Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, "Internet X.509 Public Key | |||
| Infrastructure Certificate and Certificate Revocation List | Infrastructure Certificate and Certificate Revocation List | |||
| (CRL) Profile", RFC 5280, May 2008. | (CRL) Profile", RFC 5280, May 2008. | |||
| [X.509] ITU-T, "Recommendation X.509: The Directory - | [X.509] ITU-T, "Recommendation X.509: The Directory - | |||
| Authentication Framework", 2000. | Authentication Framework", 2000. | |||
| 12.2. Informative References | [X.680] ITU-T, "Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, | |||
| Information technology - Abstract Syntax Notation One | ||||
| (ASN.1): Specification of basic notation", 2002. | ||||
| 13.2. Informative References | ||||
| [ID.sidr-algorithm-agility] | ||||
| Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility | ||||
| Procedure for RPKI", Work in progress: Internet | ||||
| Drafts draft-ietf-sidr-algorithm-agility-00.txt, | ||||
| February 2011. | ||||
| [ID.sidr-arch] | [ID.sidr-arch] | |||
| Lepinski, M. and S. Kent, "An Infrastructure to Support | Lepinski, M. and S. Kent, "An Infrastructure to Support | |||
| Secure Internet Routing", Work in progress: Internet | Secure Internet Routing", Work in progress: Internet | |||
| Drafts draft-ietf-sidr-arch-04.txt, November 2008. | Drafts draft-ietf-sidr-arch-04.txt, November 2008. | |||
| [ID.sidr-keyroll] | [ID.sidr-keyroll] | |||
| Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover | Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover | |||
| in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in | in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in | |||
| progress), October 2010. | progress), October 2010. | |||
| skipping to change at page 24, line 44 ¶ | skipping to change at page 27, line 42 ¶ | |||
| October 2010. | October 2010. | |||
| [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object | [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object | |||
| Classes and Attribute Types Version 2.0", RFC 2985, | Classes and Attribute Types Version 2.0", RFC 2985, | |||
| November 2000. | November 2000. | |||
| [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally | [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally | |||
| Unique IDentifier (UUID) URN Namespace", RFC 4122, | Unique IDentifier (UUID) URN Namespace", RFC 4122, | |||
| July 2005. | July 2005. | |||
| [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol | ||||
| (LDAP): String Representation of Distinguished Names", | ||||
| RFC 4514, June 2006. | ||||
| [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI | [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI | |||
| Scheme", RFC 5781, February 2010. | Scheme", RFC 5781, February 2010. | |||
| Appendix A. Example Resource Certificate | Appendix A. Example Resource Certificate | |||
| The following is an example Resource Certificate. | The following is an example Resource Certificate. | |||
| Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer | Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer | |||
| Data: | Data: | |||
| Version: 3 (0x2) | Version: 3 (0x2) | |||
| Serial: 1500 (0x5dc) | Serial: 1500 (0x5dc) | |||
| Signature Algorithm: SHA256WithRSAEncryption | Signature Algorithm: SHA256WithRSAEncryption | |||
| Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s | Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s | |||
| Validity | Validity | |||
| Not Before: Oct 25 12:50:00 2008 GMT | Not Before: Oct 25 12:50:00 2008 GMT | |||
| Not After : Jan 31 00:00:00 2010 GMT | Not After : Jan 31 00:00:00 2010 GMT | |||
| Subject: CN=A91872ED | Subject: CN=A91872ED | |||
| Subject Public Key Info: | Subject Public Key Info: | |||
| End of changes. 46 change blocks. | ||||
| 87 lines changed or deleted | 239 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||