< draft-ietf-sidr-cp-16.txt   draft-ietf-sidr-cp-17.txt >
Secure Inter-Domain Routing (sidr) Kent, S. Secure Inter-Domain Routing (sidr) Kent, S.
Internet Draft Kong, D. Internet Draft Kong, D.
Expires: June 2011 Seo, K. Expires: October 2011 Seo, K.
Intended Status: Best Current Practice Watro, R. Intended Status: Best Current Practice Watro, R.
BBN Technologies BBN Technologies
December 3, 2010 April 18, 2011
Certificate Policy (CP) Certificate Policy (CP)
for the Resource PKI (RPKI for the Resource PKI (RPKI
draft-ietf-sidr-cp-16.txt draft-ietf-sidr-cp-17.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 30, 2011. This Internet-Draft will expire on September 30, 2011.
Abstract Abstract
This document describes the certificate policy for a Public Key This document describes the certificate policy for a Public Key
Infrastructure (PKI) used to support attestations about Internet Infrastructure (PKI) used to support attestations about Internet
resource holdings. Each organization that distributes IP addresses Number Resource (INR) holdings. Each organization that distributes
or Autonomous System (AS) numbers to an organization will, in IP addresses or Autonomous System (AS) numbers to an organization
parallel, issue a certificate reflecting this distribution. These will, in parallel, issue a (public key) certificate reflecting this
certificates will enable verification that the resources indicated distribution. These certificates will enable verification that the
in the certificate have been distributed to the holder of the resources indicated in the certificate have been distributed to the
associated private key and that this organization is the current, holder of the associated private key and that this organization is
unique holder of these resources. the current, unique holder of these resources.
Table of Contents Table of Contents
1. Introduction...................................................7 1. Introduction...................................................7
1.1. Overview..................................................8 1.1. Overview..................................................8
1.2. Document name and identification..........................8 1.2. Document name and identification..........................8
1.3. PKI participants..........................................8 1.3. PKI participants..........................................8
1.3.1. Certification authorities............................9 1.3.1. Certification authorities............................9
1.3.2. Registration authorities.............................9 1.3.2. Registration authorities.............................9
1.3.3. Subscribers..........................................9 1.3.3. Subscribers..........................................9
skipping to change at page 6, line 30 skipping to change at page 6, line 30
10. Security Considerations......................................39 10. Security Considerations......................................39
11. IANA Considerations..........................................39 11. IANA Considerations..........................................39
12. Acknowledgments..............................................39 12. Acknowledgments..............................................39
13. References...................................................40 13. References...................................................40
13.1. Normative References....................................40 13.1. Normative References....................................40
13.2. Informative References..................................40 13.2. Informative References..................................40
Authors' Addresses:..............................................41 Authors' Addresses:..............................................42
Pre-5378 Material Disclaimer.....................................42 Pre-5378 Material Disclaimer...........Error! Bookmark not defined.
Copyright Statement..............................................42 Copyright Statement..............................................43
1. Introduction 1. Introduction
This document describes the certificate policy for a Public Key This document describes the certificate policy for a Public Key
Infrastructure (PKI) used to attest to Internet number resource Infrastructure (PKI) used to attest to Internet Number Resource
holdings (INRs) (IP addresses or Autonomous System (AS) numbers). An holdings (INRs) (IP addresses or Autonomous System (AS) numbers). An
organization that distributes INRs to another organization MAY, in organization that distributes INRs to another organization MAY, in
parallel, issue a certificate reflecting this distribution. These parallel, issue a (public key) certificate reflecting this
certificates will enable verification that the resources indicated distribution. These certificates will enable verification that the
in the certificate have been distributed to the holder of the resources indicated in the certificate have been distributed to the
associated private key and that this organization is the current holder of the associated private key and that this organization is
holder of these resources. the current holder of these resources.
The most important and distinguishing aspect of the PKI for which The most important and distinguishing aspect of the PKI for which
this policy was created is that it does not purport to identify an this policy was created is that it does not purport to identify an
INR holder via the subject name contained in the certificate issued INR holder via the subject name contained in the certificate issued
to that entity. Rather, each certificate issued under this policy is to that entity. Rather, each certificate issued under this policy is
intended to enable an entity to assert, in a verifiable fashion, intended to enable an entity to assert, in a verifiable fashion,
that it is the current holder of an INR based on the current records that it is the current holder of an INR based on the current records
of the entity responsible for the resources in question. of the entity responsible for the resources in question.
Verification of the assertion is based on two criteria: the ability Verification of the assertion is based on two criteria: the ability
of the entity to digitally sign data that is verifiable using the of the entity to digitally sign data that is verifiable using the
skipping to change at page 7, line 42 skipping to change at page 7, line 42
e.g., for integrity or access control of the repository system e.g., for integrity or access control of the repository system
described in section 2.4. Such transitive uses of certificates also described in section 2.4. Such transitive uses of certificates also
are permitted under this policy. Use of the certificates and are permitted under this policy. Use of the certificates and
certificate revocation lists (CRLs) managed under this PKI for any certificate revocation lists (CRLs) managed under this PKI for any
other purpose is a violation of this CP, and relying parties (RPs) other purpose is a violation of this CP, and relying parties (RPs)
SHOULD reject certificates presented for such uses. SHOULD reject certificates presented for such uses.
Note: This document is based on the template specified in the Note: This document is based on the template specified in the
Internet Engineering Task Force (IETF) standards document RFC 3647 Internet Engineering Task Force (IETF) standards document RFC 3647
[RFC3647]. In the interest of keeping the document as short as [RFC3647]. In the interest of keeping the document as short as
reasonable, a number of sections contained in the template are reasonable, a number of sections contained in the template have been
omitted from this policy because they did not apply to this PKI. omitted from this policy because they do not apply to this PKI.
However, we have retained the section numbering scheme employed in However, we have retained the section numbering scheme employed in
the RFC to facilitate comparison with the outline in Section 6 of RFC 3647 to facilitate comparison with the outline in Section 6 of
the RFC. Each of these omitted sections should be read as "No RFC 3647. Each of these omitted sections should be read as "No
stipulation" in CP/CPS parlance. stipulation" in CP/CPS parlance.
Conventions used in this document Conventions used in this document
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 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
1.1. Overview 1.1. Overview
This PKI is designed to support validation of claims by current This PKI is designed to support validation of claims by current
holders of INRs, in accordance with the records of the organizations holders of INRs, in accordance with the records of the organizations
that act as Certification Authorities (CAs) in this PKI. The ability that act as Certification Authorities (CAs) in this PKI. The ability
to verify such claims is essential to ensuring the unambiguous to verify such claims is essential to ensuring the unambiguous
distribution of these resources. distribution of these resources [ARCH].
The structure of the RPKI is congruent with the number resource The structure of the RPKI is congruent with the number resource
allocation framework of the Internet. The IANA allocates number allocation framework of the Internet. The IANA allocates number
resources for special purposes [RFC5736], to Regional Internet resources for special purposes [RFC5736], to Regional Internet
Registries (RIRs), and to others. The RIRs, in turn, manage the Registries (RIRs), and to others. The RIRs, in turn, manage the
allocation of number resources to end users, Internet Service allocation of number resources to end users, Internet Service
Providers, and others. Providers, and others.
This PKI encompasses several types of certificates (see IETF This PKI encompasses several types of certificates (see [CERTPROF]
document draft-ietf-sidr-arch-xx [ARCH] for more details): for more details):
. CA certificates for each organization distributing INRs, and for . CA certificates for each organization distributing INRs, and for
INR holder INR holders
. End-entity (EE) certificates for organizations to validate digital . End-entity (EE) certificates for organizations to validate digital
signatures on RPKI-signed objects signatures on RPKI-signed objects
1.2. Document name and identification 1.2. Document name and identification
The name of this document is "Certificate Policy (CP) for the The name of this document is "Certificate Policy (CP) for the
Resource PKI (RPKI)". Resource PKI (RPKI)".
This policy has been assigned the following OID: This policy has been assigned the following OID:
skipping to change at page 9, line 19 skipping to change at page 9, line 19
1.3.1. Certification authorities 1.3.1. Certification authorities
The organizations that distribute IP addresses and AS numbers (IANA, The organizations that distribute IP addresses and AS numbers (IANA,
RIRs, NIRs, ISPs) act as CAs in this PKI. RIRs, NIRs, ISPs) act as CAs in this PKI.
Organizations that do not distribute INRs, but hold such resources Organizations that do not distribute INRs, but hold such resources
also act as CAs when they create EE certificates. also act as CAs when they create EE certificates.
1.3.2. Registration authorities 1.3.2. Registration authorities
This PKI does not require establishment or use of a separate This PKI does not require establishment or use of a registration
registration authority (RA) in conjunction with the CA function. The authority (RA) function separate from the one provided inherently in
RA function MUST be provided by the same entity operating as a CA, conjunction with the CA function. The RA function MUST be provided
e.g., entities listed in Section 1.4.1. An entity acting as a CA in by the same entity operating as a CA, e.g., entities listed in
this PKI already has a formal relationship with each organization to Section 1.3.1. An entity acting as a CA in this PKI already has a
which it distributes INRs. These organizations already perform the formal relationship with each organization to which it distributes
RA function implicitly since they already assume responsibility for INRs. These organizations already perform the RA function implicitly
distributing INRs. since they already assume responsibility for distributing INRs.
1.3.3. Subscribers 1.3.3. Subscribers
These are the organizations receiving distributions of INRs - RIRs, These are the organizations receiving distributions of INRs - RIRs,
NIRs, ISPs, and other organizations. NIRs, ISPs, and other organizations.
Note that any of these organizations may have received distributions Note that any of these organizations may have received distributions
from more than one source, over time. This is true even for RIRs, from more than one source, over time. This is true even for RIRs,
which participate in inter-registry exchanges of address space. This which participate in inter-registry exchanges of address space. This
PKI accommodates such relationships. PKI accommodates such relationships.
1.3.4. Relying parties 1.3.4. Relying parties
Entities or individuals that act in reliance on certificates or Entities or individuals that act in reliance on certificates or
RPKI-signed objects issued under this PKI are relying parties. RPKI-signed objects issued under this PKI are relying parties.
Relying parties may or may not be subscribers within this PKI. (See Relying parties may or may not be subscribers within this PKI. (See
section 1.7 for the definition of an RPKI-signed object.) section 1.6 for the definition of an RPKI-signed object.)
1.3.5. Other participants 1.3.5. Other participants
Every organization that undertakes a role as a CA in this PKI is Every organization that undertakes a role as a CA in this PKI is
responsible for populating the RPKI distributed repository system responsible for populating the RPKI distributed repository system
with the certificates, CRLs, and RPKI-signed objects that it issues. with the certificates, CRLs, and RPKI-signed objects that it issues.
The organization MAY operate its own publication point or it MAY The organization MAY operate its own publication point or it MAY
outsource this function (See sections 2.1 and 2.2.) outsource this function (See sections 2.1 and 2.2.)
1.4. Certificate usage 1.4. Certificate usage
skipping to change at page 10, line 18 skipping to change at page 10, line 18
The certificates issued under this hierarchy are for authorization The certificates issued under this hierarchy are for authorization
in support of validation of claims of current holdings of INRs. in support of validation of claims of current holdings of INRs.
Additional uses of the certificates, consistent with the basic goal Additional uses of the certificates, consistent with the basic goal
cited above, also are permitted under this policy. For example, cited above, also are permitted under this policy. For example,
certificates may be issued in support of integrity and access certificates may be issued in support of integrity and access
control for the repository system described in 2.4. Such transitive control for the repository system described in 2.4. Such transitive
uses are permitted under this policy. uses are permitted under this policy.
Some of the certificates that may be issued under this PKI could be
used to support operation of this infrastructure, e.g., access
control for the repository system as described in 2.4. Such uses
also are permitted under this policy.
1.4.2. Prohibited certificate uses 1.4.2. Prohibited certificate uses
Any uses other than those described in Section 1.4.1 are prohibited Any uses other than those described in Section 1.4.1 are prohibited
under this policy. under this policy.
1.5. Policy administration 1.5. Policy administration
1.5.1. Organization administering the document 1.5.1. Organization administering the document
This CP is administered by This CP is administered by
skipping to change at page 10, line 50 skipping to change at page 10, line 45
1.5.2. Contact person 1.5.2. Contact person
The contact information is The contact information is
iesg@ietf.org iesg@ietf.org
+1-703-439-2120 (Internet Society) +1-703-439-2120 (Internet Society)
1.5.4. CP approval procedures 1.5.4. CP approval procedures
The IESG MUST approve a replacement BCP that either updates or If a replacement BCP is needed that updates or obsoletes the current
obsoletes this BCP, following the procedures of the IETF Standards BCP, then the replacement BCP MUST be approved by the IESG following
Process as defined in RFC 2026 [RFC2026]. the procedures of the IETF Standards Process as defined in RFC 2026
[RFC2026].
1.6. Definitions and acronyms 1.6. Definitions and acronyms
CPS - Certification Practice Statement. A CPS is a document that CPS - Certification Practice Statement. A CPS is a document that
specifies the practices that a Certification Authority employs specifies the practices that a Certification Authority employs
in issuing certificates in this PKI. in issuing certificates in this PKI.
Distribution of INRs - A process of distribution of the INRs along the Distribution of INRs - A process of distribution of the INRs along the
respective number hierarchy. IANA distributes blocks of IP respective number hierarchy. IANA distributes blocks of IP
addresses and AS Numbers to the five Regional Internet addresses and AS Numbers to the five Regional Internet
skipping to change at page 11, line 34 skipping to change at page 11, line 34
protocol parameter sets, namely: protocol parameter sets, namely:
. IP Version 4 addresses, . IP Version 4 addresses,
. IP version 6 addresses, and . IP version 6 addresses, and
. Identifiers used in Internet inter-domain routing, currently . Identifiers used in Internet inter-domain routing, currently
Border Gateway Protocol-4 AS numbers. Border Gateway Protocol-4 AS numbers.
ISP - Internet Service Provider. This is an organization managing and ISP - Internet Service Provider. This is an organization managing and
selling Internet services to other organizations. providing Internet services to other organizations.
LIR - In some regions, the term Local Internet Registry (LIR) is used LIR - In some regions, the term Local Internet Registry (LIR) is used
to refer to what is called an ISP in other regions. to refer to what is called an ISP in other regions.
NIR - National Internet Registry. This is an organization that manages NIR - National Internet Registry. This is an organization that manages
the distribution of INRs for a portion of the geopolitical area the distribution of INRs for a portion of the geopolitical area
covered by a Regional Registry. NIRs form an optional second covered by a Regional Registry. NIRs form an optional second
tier in the tree scheme used to manage INRs. tier in the tree scheme used to manage INRs.
RIR - Regional Internet Registry. This is an organization that RIR - Regional Internet Registry. This is an organization that
manages the distribution of INRs for a geopolitical area. manages the distribution of INRs for a geopolitical area.
RPKI-signed object - An RPKI-signed object is a digitally signed data RPKI-signed object - An RPKI-signed object is a digitally signed data
object (other than a certificate or CRL) declared to be such by object (other than a certificate or CRL) that is declared to be
a standards track RFC, and that can be validated using such by a standards track RFC, and that can be validated using
certificates issued under this PKI. The content and format of certificates issued under this PKI. The content and format of
these data constructs depend on the context in which validation these data constructs depend on the context in which validation
of claims of current holdings of INRs takes place. Examples of of claims of current holdings of INRs takes place. Examples of
these objects are repository manifests and CRLs. these objects are repository manifests and ROAs.
2. Publication And Repository Responsibilities 2. Publication And Repository Responsibilities
2.1. Repositories 2.1. Repositories
Certificates, CRLs, and RPKI-signed objects (intended for public Certificates, CRLs, and RPKI-signed objects (intended for public
consumption) MUST be made available for downloading by all relying consumption) MUST be made available for downloading by all relying
parties, to enable them to validate this data. This motivates use of parties, to enable them to validate this data. This motivates use of
a robust, distributed repository system. Each CA MUST maintain a a robust, distributed repository system. Each CA MUST maintain a
publicly accessible online repository and publish all RPKI-signed publicly accessible online repository and publish all RPKI-signed
objects (intended for public consumption) via this repository in a objects (intended for public consumption) via this repository in a
manner that conforms with RFCwwww [RFCwwww] (This function MAY be manner that conforms with "A Profile for Resource Certificate
outsourced, as noted in Section 2.2 below.) The collection of Repository Structure" [REPOS]. (This function MAY be outsourced, as
repositories forms the RPKI distributed repository system. noted in Section 2.2 below.) The collection of repositories forms
the RPKI distributed repository system.
2.2. Publication of certification information 2.2. Publication of certification information
Each CA MUST publish the certificates (intended for public Each CA MUST publish the certificates (intended for public
consumption) that it issues via the repository system. consumption) that it issues via the repository system.
Each CA MUST publish the CRLs (intended for public consumption) that Each CA MUST publish the CRLs (intended for public consumption) that
it issues via the repository system. it issues via the repository system.
Each CA MUST publish its RPKI-signed objects (intended for public Each CA MUST publish its RPKI-signed objects (intended for public
skipping to change at page 14, line 17 skipping to change at page 14, line 20
Also, please note that each CA MUST publish its CRL prior to the Also, please note that each CA MUST publish its CRL prior to the
nextUpdate value in the scheduled CRL previously issued by the CA. nextUpdate value in the scheduled CRL previously issued by the CA.
2.4. Access controls on repositories 2.4. Access controls on repositories
Each CA or repository operator MUST implement access controls to Each CA or repository operator MUST implement access controls to
prevent unauthorized persons from adding, modifying or deleting prevent unauthorized persons from adding, modifying or deleting
repository entries. A CA or repository operator MUST NOT repository entries. A CA or repository operator MUST NOT
intentionally use technical means of limiting read access to its intentionally use technical means of limiting read access to its
CPS, certificates, CRLs or RPKI-signed objects. This data is CPS, certificates, CRLs or RPKI-signed objects. This data is
supposed to be accessible to the public. intended to be accessible to the public.
3. Identification and Authentication 3. Identification and Authentication
3.1. Naming 3.1. Naming
3.1.1. Types of names 3.1.1. Types of names
The distinguished name for every CA and end-entity consists of a The distinguished name for every CA and end-entity consists of a
single Common Name (CN) attribute with a value generated by the single Common Name (CN) attribute with a value generated by the
issuer of the certificate. Optionally, the serialNumber attribute issuer of the certificate. Optionally, the serialNumber attribute
MAY be included along with the common name (to form a terminal MAY be included along with the common name (to form a terminal
relative distinguished name set), to distinguish among successive relative distinguished name set), to distinguish among successive
instances of certificates associated with the same entity. instances of certificates associated with the same entity.
3.1.2. Need for names to be meaningful 3.1.2. Need for names to be meaningful
The Subject name in each certificate SHOULD NOT be "meaningful", The Subject name in each certificate SHOULD NOT be "meaningful",
i.e., the name is NOT intended to convey the identity of the Subject i.e., the name is not intended to convey the identity of the Subject
to relying parties. The rationale here is that certificates issued to relying parties. The rationale here is that certificates issued
under this PKI are used for authorization in support of applications under this PKI are used for authorization in support of applications
that make use of attestations of INR holdings. They are not used to that make use of attestations of INR holdings. They are not used to
identify Subjects. identify Subjects.
3.1.3. Anonymity or pseudonymity of subscribers 3.1.3. Anonymity or pseudonymity of subscribers
Although Subject (and Issuer) names need not be meaningful, and may Although Subject (and Issuer) names need not be meaningful, and may
appear "random," anonymity is not a function of this PKI, and thus appear "random," anonymity is not a function of this PKI, and thus
no explicit support for this feature is provided. no explicit support for this feature is provided.
3.1.4. Rules for interpreting various name forms 3.1.4. Rules for interpreting various name forms
None None
3.1.5. Uniqueness of names 3.1.5. Uniqueness of names
There is no guarantee that subject names are globally unique in this There is no guarantee that subject names are globally unique in this
PKI. Each CA certifies Subject names that MUST be unique among the PKI. Each CA certifies subject names that MUST be unique among the
certificates that it issues. Although it is desirable that these certificates that it issues. Although it is desirable that these
Subject names be unique throughout the PKI, name uniqueness within subject names be unique throughout the PKI, name uniqueness within
the RPKI cannot be guaranteed. the RPKI cannot be guaranteed.
However, Subject names in certificates SHOULD be constructed in a However, subject names in certificates SHOULD be constructed in a
way that minimizes the chances that two entities in the RPKI will be way that minimizes the chances that two entities in the RPKI will be
assigned the same name. The RPKI certificate profile [RFCwwww] assigned the same name. The RPKI certificate profile [CERTPROF]
provides an example of how to generate (meaningless) subject names provides an example of how to generate (meaningless) subject names
in a way that minimizes the likelihood of collisions. in a way that minimizes the likelihood of collisions.
3.2. Initial identity validation 3.2. Initial identity validation
3.2.1. Method to prove possession of private key 3.2.1. Method to prove possession of private key
Each CA operating within the context of this PKI MUST require each Each CA operating within the context of this PKI MUST require each
Subject to demonstrate proof-of-possession (PoP) of the private key Subject to demonstrate proof-of-possession (PoP) of the private key
corresponding to the public key in the certificate, prior to issuing corresponding to the public key in the certificate, prior to issuing
skipping to change at page 16, line 43 skipping to change at page 16, line 43
of each organization that is an INR holder. The specific means by of each organization that is an INR holder. The specific means by
which each CA authenticates individuals as representatives for an which each CA authenticates individuals as representatives for an
organization MUST be described by the CPS for each CA. Relying organization MUST be described by the CPS for each CA. Relying
parties can expect each CA to employ procedures commensurate with parties can expect each CA to employ procedures commensurate with
those it already employs as a registry or ISP, in authenticating those it already employs as a registry or ISP, in authenticating
individuals as representatives for INR holders. individuals as representatives for INR holders.
3.2.4. Non-verified subscriber information 3.2.4. Non-verified subscriber information
A CA MUST NOT include any non-verified subscriber data in A CA MUST NOT include any non-verified subscriber data in
certificates issued under this certificate policy except for SIA certificates issued under this certificate policy except for Subject
extensions. Information Access (SIA) extensions.
3.2.5. Validation of authority 3.2.5. Validation of authority
Each CA operating within the context of this PKI MUST employ Each CA operating within the context of this PKI MUST employ
procedures to verify that an individual claiming to represent an procedures to verify that an individual claiming to represent an
organization to which a certificate is issued, is authorized to organization to which a certificate is issued, is authorized to
represent that organization in this context. The procedures MUST be represent that organization in this context. The procedures MUST be
described by the CPS for the CA. Relying parties can expect each CA described by the CPS for the CA. Relying parties can expect each CA
to employ procedures commensurate with those it already employs as a to employ procedures commensurate with those it already employs as a
registry or ISP, in authenticating individuals as representatives registry or ISP, in authenticating individuals as representatives
skipping to change at page 19, line 31 skipping to change at page 19, line 31
4.1.2. Enrollment process and responsibilities 4.1.2. Enrollment process and responsibilities
The enrollment process and procedures MUST be described by the CPS The enrollment process and procedures MUST be described by the CPS
for each CA. An entity that desires one or more certificates should for each CA. An entity that desires one or more certificates should
contact the organization from which it receives its INRs. contact the organization from which it receives its INRs.
4.2. Certificate application processing 4.2. Certificate application processing
CAs SHOULD make use of existing standards for certificate CAs SHOULD make use of existing standards for certificate
application processing. Section 6 of the resource certificate application processing. Section 6 of the resource certificate
profile [RFCyyyy] defines the standard certificate request formats profile [CERTPROF] defines the standard certificate request formats
that MUST be supported that MUST be supported
Each CA MUST define the certificate request/response standards that Each CA MUST define the certificate request/response standards that
it employs, via its CPS. it employs, via its CPS.
4.2.1. Performing identification and authentication functions 4.2.1. Performing identification and authentication functions
Existing practices employed by registries and ISPs to identify and Existing practices employed by registries and ISPs to identify and
authenticate organizations that receive INRs form the basis for authenticate organizations that receive INRs form the basis for
issuance of certificates to these subscribers. It is important to issuance of certificates to these subscribers. It is important to
note that the Resource PKI SHOULD never be used to authenticate the note that the Resource PKI SHOULD NOT be used to authenticate the
identity of an organization, but rather to bind subscribers to the identity of an organization, but rather to bind subscribers to the
INRs they hold. Because identity is not being vouched for by this INRs they hold. Because identity is not being vouched for by this
PKI, certificate application procedures need not verify legal PKI, certificate application procedures need not verify legal
organization names, etc. organization names, etc.
4.2.2. Approval or rejection of certificate applications 4.2.2. Approval or rejection of certificate applications
Certificate applications MUST be approved based on the normal Certificate applications MUST be approved based on the normal
business practices of the entity operating the CA, based on the CA's business practices of the entity operating the CA, based on the CA's
records of INR holders. Each CA MUST follow the procedures specified records of INR holders. Each CA MUST follow the procedures specified
skipping to change at page 20, line 28 skipping to change at page 20, line 28
4.3.1. CA actions during certificate issuance 4.3.1. CA actions during certificate issuance
If a CA determines that the request is acceptable, it MUST issue the If a CA determines that the request is acceptable, it MUST issue the
corresponding certificate and publish it in the RPKI distributed corresponding certificate and publish it in the RPKI distributed
repository system via publication of the certificate at the CA's repository system via publication of the certificate at the CA's
repository publication point. repository publication point.
4.3.2. Notification to subscriber by the CA of issuance of certificate 4.3.2. Notification to subscriber by the CA of issuance of certificate
The CA MUST notify the subscriber when the certificate is published. The CA MUST notify the subscriber when the certificate is published.
The means by which a subscriber is notified is defined by each CA in The means by which a subscriber is notified MUST be defined by each
its CPS. CA in its CPS.
4.4. Certificate acceptance 4.4. Certificate acceptance
4.4.1. Conduct constituting certificate acceptance 4.4.1. Conduct constituting certificate acceptance
Within the timeframe specified in its CPS, the CA MUST place the Within the timeframe specified in its CPS, the CA MUST place the
certificate in the repository and notify the subscriber. This MAY certificate in the repository and notify the subscriber. This MAY
be done without subscriber review and acceptance. Each CA MUST state be done without subscriber review and acceptance. Each CA MUST state
in its CPS the procedures it follows for publishing of the in its CPS the procedures it follows for publishing of the
certificate and notification to the subscriber. certificate and notification to the subscriber.
skipping to change at page 21, line 26 skipping to change at page 21, line 26
4.5.2. Relying party public key and certificate usage 4.5.2. Relying party public key and certificate usage
Reliance on a certificate must be reasonable under the Reliance on a certificate must be reasonable under the
circumstances. If the circumstances indicate a need for additional circumstances. If the circumstances indicate a need for additional
assurances, the relying party must obtain such assurances in order assurances, the relying party must obtain such assurances in order
for such reliance to be deemed reasonable. for such reliance to be deemed reasonable.
Before any act of reliance, relying parties MUST independently (1) Before any act of reliance, relying parties MUST independently (1)
verify that the certificate will be used for an appropriate purpose verify that the certificate will be used for an appropriate purpose
that is not prohibited or otherwise restricted by this CP (see that is not prohibited or otherwise restricted by this CP (see
section 1.5), and (2) assess the status of the certificate and all section 1.4), and (2) assess the status of the certificate and all
the CAs in the chain (terminating at a TA accepted by the RP) that the certificates in the chain (terminating at a Trust Anchor (TA)
issued the certificates relevant to the certificate in question. If accepted by the RP) that issued the certificates relevant to the
any of the certificates in the certificate chain have been revoked, certificate in question. If any of the certificates in the
the relying party is solely responsible to determine whether certificate chain have been revoked or have expired, the relying
reliance on a digital signature to be verified by the certificate in party is solely responsible to determine whether reliance on a
question is acceptable. Any such reliance is made solely at the risk digital signature to be verified by the certificate in question is
of the relying party. acceptable. Any such reliance is made solely at the risk of the
relying party.
If a relying party determines that use of the certificate is If a relying party determines that use of the certificate is
appropriate, the relying party must utilize appropriate software appropriate, the relying party must utilize appropriate software
and/or hardware to perform digital signature verification as a and/or hardware to perform digital signature verification as a
condition of relying on the certificate. Moreover the relying party condition of relying on the certificate. Moreover the relying party
MUST validate the certificate in a manner consistent with the RPKI MUST validate the certificate in a manner consistent with the RPKI
certificate profile [RFCyyyy], which specifies the extended certificate profile [CERTPROF], which specifies the extended
validation algorithm for RPKI certificates. validation algorithm for RPKI certificates.
4.6. Certificate renewal 4.6. Certificate renewal
This section describes the procedures for certificate renewal. This section describes the procedures for certificate renewal.
Certificate renewal is the issuance of a new certificate to replace Certificate renewal is the issuance of a new certificate to replace
an old one prior to its expiration. Only the validity dates and the an old one prior to its expiration. Only the validity dates and the
serial number are changed. The public key and all other information serial number (the field in the certificate not the DN attribute)
remain the same. are changed. The public key and all other information remain the
same.
4.6.1. Circumstance for certificate renewal 4.6.1. Circumstance for certificate renewal
A certificate MUST be processed for renewal based on its expiration A certificate MUST be processed for renewal based on its expiration
date or a renewal request from the subscriber. Prior to the date or a renewal request from the subscriber. Prior to the
expiration of an existing subscriber's certificate, it is the expiration of an existing subscriber's certificate, it is the
responsibility of the subscriber to renew the certificate to responsibility of the subscriber to renew the certificate to
maintain continuity of certificate usage. If the issuing CA maintain continuity of certificate usage. If the issuing CA
initiates the renewal process based on the certificate expiration initiates the renewal process based on the certificate expiration
date, then that CA MUST notify the holder in advance of the renewal date, then that CA MUST notify the holder in advance of the renewal
skipping to change at page 23, line 11 skipping to change at page 23, line 11
4.6.5. Conduct constituting acceptance of a renewal certificate 4.6.5. Conduct constituting acceptance of a renewal certificate
No additional stipulations beyond those of section 4.4.1. No additional stipulations beyond those of section 4.4.1.
4.6.6. Publication of the renewal certificate by the CA 4.6.6. Publication of the renewal certificate by the CA
No additional stipulations beyond those of section 4.4.2. No additional stipulations beyond those of section 4.4.2.
4.6.7. Notification of certificate issuance by the CA to other entities 4.6.7. Notification of certificate issuance by the CA to other entities
No additional stipulations beyond those of section 4.3.3. No additional stipulations beyond those of section 4.4.3.
4.7. Certificate re-key 4.7. Certificate re-key
This section describes the procedures for certificate re-key. This section describes the procedures for certificate re-key.
Certificate re-key is the issuance of a new certificate to replace Certificate re-key is the issuance of a new certificate to replace
an old one because the key needs to be replaced. Unlike with an old one because the key needs to be replaced. Unlike with
certificate renewal, the public key is changed. certificate renewal, the public key is changed.
4.7.1. Circumstance for certificate re-key 4.7.1. Circumstance for certificate re-key
skipping to change at page 23, line 36 skipping to change at page 23, line 36
private key, or private key, or
2. the expiration of the cryptographic lifetime of the associated 2. the expiration of the cryptographic lifetime of the associated
key pair key pair
A CA re-key operation has dramatic consequences, requiring the re- A CA re-key operation has dramatic consequences, requiring the re-
issuance of all certificates issued by the re-keyed entity. So it issuance of all certificates issued by the re-keyed entity. So it
should be performed only when necessary and in a way that preserves should be performed only when necessary and in a way that preserves
the ability of relying parties to validate certificates whose the ability of relying parties to validate certificates whose
validation path includes the re-keyed entity. CA key rollover MUST validation path includes the re-keyed entity. CA key rollover MUST
follow the procedures defined in RFCxxxx [RFCxxxx]. follow the procedures defined in "CA Key Rollover in the RPKI"
[KEYROLL].
Note that if a certificate is revoked to replace the RFC 3779 Note that if a certificate is revoked to replace the RFC 3779
extensions, the replacement certificate MUST incorporate the same extensions, the replacement certificate MUST incorporate the same
public key rather than a new key. This applies to when one is public key rather than a new key. This applies to when one is
adding INRs (revocation not required) and to when one is removing adding INRs (revocation not required) and to when one is removing
INRs (revocation required (see Section 4.8.1). INRs (revocation required (see Section 4.8.1)).
If the re-key is based on a suspected compromise, then the previous If the re-key is based on a suspected compromise, then the previous
certificate MUST be revoked. certificate MUST be revoked.
4.7.2. Who may request certification of a new public key 4.7.2. Who may request certification of a new public key
The holder of the certificate may request a re-key. In addition, The holder of the certificate may request a re-key. In addition,
the CA that issued the certificate MAY chose to initiate a rekey the CA that issued the certificate MAY chose to initiate a rekey
based on a verified compromise report. based on a verified compromise report.
skipping to change at page 24, line 24 skipping to change at page 24, line 24
4.7.5. Conduct constituting acceptance of a re-keyed certificate 4.7.5. Conduct constituting acceptance of a re-keyed certificate
No additional stipulations beyond those of section 4.4.1. No additional stipulations beyond those of section 4.4.1.
4.7.6. Publication of the re-keyed certificate by the CA 4.7.6. Publication of the re-keyed certificate by the CA
No additional stipulations beyond those of section 4.4.2. No additional stipulations beyond those of section 4.4.2.
4.7.7. Notification of certificate issuance by the CA to other entities 4.7.7. Notification of certificate issuance by the CA to other entities
No additional stipulations beyond those of section 4.3.3. No additional stipulations beyond those of section 4.4.3.
4.8. Certificate modification 4.8. Certificate modification
4.8.1. Circumstance for certificate modification 4.8.1. Circumstance for certificate modification
Modification of a certificate occurs to implement changes to Modification of a certificate occurs to implement changes to
selected attribute values in a certificate. In the context of the selected attribute values in a certificate. In the context of the
RPKI, the only changes that are accommodated by certificate RPKI, the only changes that are accommodated by certificate
modification are changes to the INR holdings described by the RFC modification are changes to the INR holdings described by the RFC
3779 extension and changes to the SIA extension. 3779 extension and changes to the SIA extension.
skipping to change at page 25, line 25 skipping to change at page 25, line 25
4.8.5. Conduct constituting acceptance of modified certificate 4.8.5. Conduct constituting acceptance of modified certificate
No additional stipulations beyond those of section 4.4.1. No additional stipulations beyond those of section 4.4.1.
4.8.6. Publication of the modified certificate by the CA 4.8.6. Publication of the modified certificate by the CA
No additional stipulations beyond those of section 4.4.2. No additional stipulations beyond those of section 4.4.2.
4.8.7. Notification of certificate issuance by the CA to other entities 4.8.7. Notification of certificate issuance by the CA to other entities
No additional stipulations beyond those of section 4.3.3. No additional stipulations beyond those of section 4.4.3.
4.9. Certificate revocation and suspension 4.9. Certificate revocation and suspension
4.9.1. Circumstances for revocation 4.9.1. Circumstances for revocation
A certificate MUST be revoked (and published on a CRL) if there is A certificate MUST be revoked (and published on a CRL) if there is
reason to believe that there has been a compromise of a subscriber's reason to believe that there has been a compromise of a subscriber's
private key. A certificate also MAY be revoked to invalidate a data private key. A certificate also MAY be revoked to invalidate a data
object signed by the private key associated with that certificate. object signed by the private key associated with that certificate.
Other circumstances that justify revocation of a certificate MAY be Other circumstances that justify revocation of a certificate MAY be
skipping to change at page 26, line 46 skipping to change at page 26, line 46
nextUpdate value when it issues a CRL, to signal when the next nextUpdate value when it issues a CRL, to signal when the next
scheduled CRL will be issued. scheduled CRL will be issued.
4.9.8. Maximum latency for CRLs 4.9.8. Maximum latency for CRLs
The CPS for each CA MUST specify the maximum latency associated with The CPS for each CA MUST specify the maximum latency associated with
posting its CRL to the repository system. posting its CRL to the repository system.
4.10. Certificate status services 4.10. Certificate status services
This PKI does not make provision for use of OCSP or SCVP, because it This PKI does not make provision for use of the Online Certificate
is anticipated that the primary RPs (ISPs) will acquire and validate Status Protocol (OCSP) [RFC2560] or Server-Based Certificate
Validation Protocol (SCVP) [RFC5055]. This is because it is
anticipated that the primary RPs (ISPs) will acquire and validate
certificates for all participating resource holders. These protocols certificates for all participating resource holders. These protocols
are not designed for such large-scale, bulk certificate status are not designed for such large-scale, bulk certificate status
checking. RPs MUST check for new CRLs at least daily. It is checking. RPs MUST check for new CRLs at least daily. It is
RECOMMENDED that RPs perform this check several times per day, but RECOMMENDED that RPs perform this check several times per day, but
no more than 8-12 times per day (to avoid excessive repository no more than 8-12 times per day (to avoid excessive repository
accesses). accesses).
5. Facility, Management, And Operational Controls 5. Facility, Management, And Operational Controls
5.1. Physical controls 5.1. Physical controls
skipping to change at page 30, line 28 skipping to change at page 30, line 28
5.4.8. Vulnerability assessments 5.4.8. Vulnerability assessments
The RPKI subsystems of a registry or ISP SHOULD participate in any The RPKI subsystems of a registry or ISP SHOULD participate in any
vulnerability assessments that these organizations run as part of vulnerability assessments that these organizations run as part of
their normal business practice. their normal business practice.
5.6. Key changeover 5.6. Key changeover
When a CA wishes to change keys, it MUST acquire a new certificate When a CA wishes to change keys, it MUST acquire a new certificate
containing its new public key. See [RFCxxxx] for a description of containing its new public key. See [KEYROLL] for a description of
how key changeover is effected in the RPKI. how key changeover is effected in the RPKI.
5.8. CA or RA termination 5.8. CA or RA termination
In the RPKI, each subscriber acts as a CA authoritative for the In the RPKI, each subscriber acts as a CA authoritative for the
specified INRs that were distributed to that entity. Procedures specified INRs that were distributed to that entity. Procedures
associated with the termination of a CA MUST be described in the CPS associated with the termination of a CA MUST be described in the CPS
for that CA. These procedures MUST include a provision to notify for that CA. These procedures MUST include a provision to notify
each entity that issued a certificate to the organization that is each entity that issued a certificate to the organization that is
operating the CA that is terminating. operating the CA that is terminating.
Since the RA function MUST be provided by the same entity operating Since the RA function MUST be provided by the same entity operating
as the CA (see Section 1.4.2), there are no separate stipulations as the CA (see Section 1.3.2), there are no separate stipulations
for RAs. for RAs.
6. Technical Security Controls 6. Technical Security Controls
The organizations that distribute INRs to network subscribers are The organizations that distribute INRs to network subscribers are
authoritative for these distributions. This PKI is designed to authoritative for these distributions. This PKI is designed to
enable ISPs and network subscribers to demonstrate that they are the enable ISPs and network subscribers to demonstrate that they are the
holders of the INRs that have been distributed to them. Accordingly, holders of the INRs that have been distributed to them. Accordingly,
the security controls used by CAs and subscribers for this PKI need the security controls used by CAs and subscribers for this PKI need
only to be as secure as those that apply to the procedures for only to be as secure as those that apply to the procedures for
skipping to change at page 31, line 27 skipping to change at page 31, line 27
6.1. Key pair generation and installation 6.1. Key pair generation and installation
6.1.1. Key pair generation 6.1.1. Key pair generation
In most instances, public-key pairs will be generated by the In most instances, public-key pairs will be generated by the
subject, i.e., the organization receiving the distribution of INRs. subject, i.e., the organization receiving the distribution of INRs.
However, some CAs MAY offer to generate key pairs on behalf of their However, some CAs MAY offer to generate key pairs on behalf of their
subjects at the request of the subjects, e.g., to accommodate subjects at the request of the subjects, e.g., to accommodate
subscribers who do not have the ability to perform key generation in subscribers who do not have the ability to perform key generation in
a secure fashion. (The CA has to check the quality of the keys only a secure fashion. (The CA has to check the quality of the keys only
if it generates them (see 6.1.6)). Since the keys used in this PKI if it generates them (see Section 6.1.6)). Since the keys used in
are not for non-repudiation purposes, generation of key pairs by CAs this PKI are not for non-repudiation purposes, generation of key
does not inherently undermine the security of the PKI. Each CA MUST pairs by CAs does not inherently undermine the security of the PKI.
describe its key pair generation procedures in its CPS. Each CA MUST describe its key pair generation procedures in its CPS.
6.1.2. Private key delivery to subscriber 6.1.2. Private key delivery to subscriber
If a CA provides key pair generation services for subscribers, its If a CA provides key pair generation services for subscribers, its
CPS MUST describe the means by which private keys are delivered to CPS MUST describe the means by which private keys are delivered to
subscribers in a secure fashion. subscribers in a secure fashion.
6.1.3. Public key delivery to certificate issuer 6.1.3. Public key delivery to certificate issuer
When a public key is transferred to the issuing CA to be certified, When a public key is transferred to the issuing CA to be certified,
skipping to change at page 32, line 9 skipping to change at page 32, line 9
CA public keys for all entities (other than trust anchors) are CA public keys for all entities (other than trust anchors) are
contained in certificates issued by other CAs. These certificates contained in certificates issued by other CAs. These certificates
MUST be published in the RPKI distributed repository system. Relying MUST be published in the RPKI distributed repository system. Relying
parties download these certificates from the repositories. Public parties download these certificates from the repositories. Public
key values and associated data for (putative) trust anchors are key values and associated data for (putative) trust anchors are
distributed out of band and accepted by relying parties on the basis distributed out of band and accepted by relying parties on the basis
of locally-defined criteria. of locally-defined criteria.
6.1.5. Key sizes 6.1.5. Key sizes
The algorithms and key sizes used in the RPKI are specified in RFC The algorithms and key sizes used in the RPKI are specified in "A
ZZZZ [RFCzzzz]. Profile for Algorithms and Key Sizes for use in the Resource Public
Key Infrastructure [ALGKEY].
6.1.6. Public key parameters generation and quality checking 6.1.6. Public key parameters generation and quality checking
The public key parameters used in the RPKI are specified in RFC ZZZZ The public key parameters used in the RPKI are specified in
[RFCzzzz]. Each subscriber is responsible for performing checks on [ALGKEY]. Each subscriber is responsible for performing checks on
the quality of its key pair. A CA is not responsible for performing the quality of its key pair. A CA is not responsible for performing
such checks for subscribers except in the case where the CA such checks for subscribers except in the case where the CA
generates the key pair on behalf of the subscriber. generates the key pair on behalf of the subscriber.
6.1.7. Key usage purposes (as per X.509 v3 key usage field) 6.1.7. Key usage purposes (as per X.509 v3 key usage field)
The Key usage extension bit values used in the RPKI are specified in The Key usage extension bit values used in the RPKI are specified in
RFC YYYY [RFCyyyy]. RPKI certificate profile [CERTPROF].
6.2. Private Key Protection and Cryptographic Module Engineering 6.2. Private Key Protection and Cryptographic Module Engineering
Controls Controls
6.2.1. Cryptographic module standards and controls 6.2.1. Cryptographic module standards and controls
The cryptographic module standards and controls employed by each CA The cryptographic module standards and controls employed by each CA
MUST be described in the CPS issued by that CA. MUST be described in the CPS issued by that CA.
6.2.2. Private key (n out of m) multi-person control 6.2.2. Private key (n out of m) multi-person control
skipping to change at page 36, line 7 skipping to change at page 36, line 7
employed for CA operation. These MUST be commensurate with the employed for CA operation. These MUST be commensurate with the
protection it employs for the computers used for managing protection it employs for the computers used for managing
distribution of INRs. distribution of INRs.
6.8. Time-stamping 6.8. Time-stamping
The RPKI does not make use of time stamping. The RPKI does not make use of time stamping.
7. Certificate and CRL Profiles 7. Certificate and CRL Profiles
Please refer to the RPKI Certificate and CRL Profile [RFCyyyy]. Please refer to the RPKI Certificate and CRL Profile [CERTPROF].
8. Compliance Audit And Other Assessments 8. Compliance Audit And Other Assessments
The Certificate Policy for a typical PKI defines the criteria The Certificate Policy for a typical PKI defines the criteria
against which prospective CAs are evaluated and establishes against which prospective CAs are evaluated and establishes
requirements that they must meet. In this PKI, the CAs are already requirements that they must meet. In this PKI, the CAs are already
authoritative for the management of INRs, and the PKI simply authoritative for the management of INRs, and the PKI simply
supports verification of the distribution of these resources to supports verification of the distribution of these resources to
network subscribers. Accordingly, whatever audit and other network subscribers. Accordingly, whatever audit and other
assessments are already used to ensure the security of the assessments are already used to ensure the security of the
skipping to change at page 38, line 41 skipping to change at page 38, line 41
Successive versions of the CP will be published with the statement Successive versions of the CP will be published with the statement
"This CP takes effect on MM/DD/YYYY." MM/DD/YYYY MUST be a minimum "This CP takes effect on MM/DD/YYYY." MM/DD/YYYY MUST be a minimum
of 6 months from the date of publication. of 6 months from the date of publication.
9.12.3. Circumstances under which OID must be changed 9.12.3. Circumstances under which OID must be changed
If the IESG judges that changes to the CP do not materially reduce If the IESG judges that changes to the CP do not materially reduce
the acceptability of certificates issued for RPKI purposes, there the acceptability of certificates issued for RPKI purposes, there
will be no change to the CP OID. If the IESG judges that changes to will be no change to the CP OID. If the IESG judges that changes to
the CP do materially change the acceptability of certificates for the CP do materially change the acceptability of certificates for
RPKI purposes, then there will be a new CP OID. RPKI purposes, then there MUST be a new CP OID.
10. Security Considerations 10. Security Considerations
According to X.509, a certificate policy (CP) is "a named set of According to X.509, a certificate policy (CP) is "a named set of
rules that indicates the applicability of a certificate to a rules that indicates the applicability of a certificate to a
particular community and/or class of applications with common particular community and/or class of applications with common
security requirements." A CP may be used by a relying party to help security requirements." A CP may be used by a relying party to help
in deciding whether a certificate, and the binding therein, are in deciding whether a certificate, and the binding therein, are
sufficiently trustworthy and otherwise appropriate for a particular sufficiently trustworthy and otherwise appropriate for a particular
application. This document describes the CP for the Resource Public application. This document describes the CP for the Resource Public
skipping to change at page 39, line 31 skipping to change at page 39, line 31
and technical security controls, including the scope of the and technical security controls, including the scope of the
subscriber's responsibilities (for example, in protecting the subscriber's responsibilities (for example, in protecting the
private key), and the stated responsibilities and liability terms private key), and the stated responsibilities and liability terms
and conditions of the CA (for example, warranties, disclaimers of and conditions of the CA (for example, warranties, disclaimers of
warranties, and limitations of liability). warranties, and limitations of liability).
Since name uniqueness within the RPKI cannot be guaranteed, there is Since name uniqueness within the RPKI cannot be guaranteed, there is
a risk that two or more CAs in the RPKI will issue certificates and a risk that two or more CAs in the RPKI will issue certificates and
CRLs under the same Issuer name. Path validation implementations CRLs under the same Issuer name. Path validation implementations
that conform to the resource certification path validation algorithm that conform to the resource certification path validation algorithm
[see RFCyyyy] verify that the same key was used to sign both the (see [CERTPROF]) verify that the same key was used to sign both the
target (the resource certificate) and the corresponding CRL. So a target (the resource certificate) and the corresponding CRL. So a
name collision will not change the result. Use of the basic X.509 name collision will not change the result. Use of the basic X.509
path validation algorithm, which assumes name uniqueness, could path validation algorithm, which assumes name uniqueness, could
result in a revoked certificate being accepted as valid or a valid result in a revoked certificate being accepted as valid or a valid
certificate being rejected as revoked. Relying parties must ensure certificate being rejected as revoked. Relying parties must ensure
that the software they use to validate certificates issued under that the software they use to validate certificates issued under
this policy verifies that the same key was used to sign both the this policy verifies that the same key was used to sign both the
certificate and the corresponding CRL, as specified in [RFCyyyy]. certificate and the corresponding CRL, as specified in [CERTPROF].
11. IANA Considerations 11. IANA Considerations
None. None.
12. Acknowledgments 12. Acknowledgments
The authors would like to thank Geoff Huston, Randy Bush, Andrei The authors would like to thank Geoff Huston, Randy Bush, Andrei
Robachevsky and other members of the RPKI community for reviewing Robachevsky and other members of the RPKI community for reviewing
this document and Matt Lepinski for his help with the formatting. this document and Matt Lepinski for his help with the formatting.
13. References 13. References
13.1. Normative References 13.1. Normative References
[ARCH] Lepinski M., Kent S., "An Infrastructure to Support Secure
Internet Routing," work in progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2026] Bradner, S., "The Internet Standards Process - Revision 3," [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[RFC3779] Lynn, C., Kent, S., Seo, K., "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., Seo, K., "X.509 Extensions for IP
Addresses and AS Identifiers," RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[RFCwwww] Huston, G., Loomans, R., and Michaelson, G., "A Profile for [REPOS] Huston, G., Loomans, R., and Michaelson, G., "A Profile for
Resource Certificate Repository Structure," work in progress. Resource Certificate Repository Structure", draft-ietf-sidr-
repos-struct-07.txt, work in progress.
[RFCxxxx] Huston, G., Michaelson, G., Kent, S., "CA Key Rollover in [KEYROLL] Huston, G., Michaelson, G., Kent, S., "CA Key Rollover in
the RPKI," work in progress. the RPKI", draft-ietf-sidr-keyroll-06.txt, work in progress.
[RFCyyyy] Huston, G., Michaelson, G., Loomans, R., "A Profile for [CERTPROF] Huston, G., Michaelson, G., Loomans, R., "A Profile for
X.509 PKIX Resource Certificates," work in progress. X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs-
21.txt, work in progress.
[RFCzzzz] Huston, G., "A Profile for Algorithms and Key Sizes for use [ALGKEY] Huston, G., "A Profile for Algorithms and Key Sizes for use in
in the Resource Public Key Infrastructure," work in progress. the Resource Public Key Infrastructure", draft-ietf-sidr-rpki-
algs-05.txt, work in progress.
13.2. Informative References 13.2. Informative References
[ARCH] Lepinski M., Kent S., "An Infrastructure to Support Secure
Internet Routing", draft-ietf-sidr-arch-12.txt, work in
progress.
[PROV] Huston, G., Loomans, R., Ellacott, B., Austein, R., "A Protocol [PROV] Huston, G., Loomans, R., Ellacott, B., Austein, R., "A Protocol
for Provisioning Resource Certificates," work in progress. for Provisioning Resource Certificates", draft-ietf-sidr-
rescerts-provisioning-09.txt, work in progress.
[RFC2560] Myers, M., Ankney, R., Maplani, A., Galperin, S., Adams,
C., "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., Wu, S., [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., Wu, S.,
"Internet X.509 Public Key Infrastructure Certificate Policy and "Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework," RFC 3647, November 2003. Certification Practices Framework", RFC 3647, November 2003.
[RFC5055] Freeman T,, Housley, R., Malpani, A., Cooper, D., Polk, W.,
"Server-Based Certificate Validation Protocol (SCVP)", RFC5055,
December 2007.
[RFC5736] Huston G., Cotton, M., Vegoda, L., "IANA IPv4 Special
Purpose Address Registry", RFC5736, January 2010.
Authors' Addresses: Authors' Addresses:
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge MA 02138 Cambridge MA 02138
USA USA
Phone: +1 (617) 873-3988 Phone: +1 617 873 3988
Email: skent@bbn.com Email: skent@bbn.com
Derrick Kong Derrick Kong
BBN Technologies BBN Technologies
Moulton Street Moulton Street
Cambridge MA 02138 Cambridge MA 02138
USA USA
Phone: +1 (617) 873-1951 Phone: +1 617 873 1951
Email: dkong@bbn.com Email: dkong@bbn.com
Karen Seo Karen Seo
BBN Technologies BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge MA 02138 Cambridge MA 02138
USA USA
Phone: +1 (617) 873-3152 Phone: +1 617 873 3152
Email: kseo@bbn.com Email: kseo@bbn.com
Ronald Watro Ronald Watro
BBN Technologies BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge MA 02138 Cambridge MA 02138
USA USA
Phone: +1 (617) 873-2551 Phone: +1 617 873 2551
Email: rwatro@bbn.com Email: rwatro@bbn.com
Pre-5378 Material Disclaimer
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Copyright Statement Copyright Statement
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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
 End of changes. 69 change blocks. 
132 lines changed or deleted 137 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/