draft-ietf-sidr-keyroll-02.txt   draft-ietf-sidr-keyroll-03.txt 
SIDR G. Huston SIDR G. Huston
Internet-Draft G. Michaelson Internet-Draft G. Michaelson
Intended status: BCP APNIC Intended status: BCP APNIC
Expires: April 10, 2011 S. Kent Expires: April 28, 2011 S. Kent
BBN BBN
October 7, 2010 October 25, 2010
CA Key Rollover in the RPKI CA Key Rollover in the RPKI
draft-ietf-sidr-keyroll-02.txt draft-ietf-sidr-keyroll-03.txt
Abstract Abstract
This document describes an algorithm to allow an entity who This document describes an algorithm to allow an entity who
undertakes the role of a Certification Authority in the Resource undertakes the role of a Certification Authority in the Resource
Public Key Infrastructure to perform a rollover of its key pair. Public Key Infrastructure to perform a rollover of its key pair.
This document also notes the requirements placed on Relying Parties This document also notes the requirements placed on Relying Parties
who maintain a local cache of the objects that have been published in who maintain a local cache of the objects that have been published in
the distributed Resource Public Key Infrastructure repository the distributed Resource Public Key Infrastructure repository
publication structure. publication structure.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 April 10, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Concepts . . . . . . . . . . . . . . . . . 3 1.1. Terminology and Concepts . . . . . . . . . . . . . . . . . 3
2. CA Key Rollover Procedure . . . . . . . . . . . . . . . . . . . 3 2. CA Key Rollover Procedure . . . . . . . . . . . . . . . . . . 3
3. Relying Party Requirements . . . . . . . . . . . . . . . . . . 7 3. Relying Party Requirements . . . . . . . . . . . . . . . . . . 7
4. Reissuing Certificates and RPKI Signed Objects . . . . . . . . 7 4. Re-issuing Certificates and RPKI Signed Objects . . . . . . . 7
4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . . 7 4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 7
4.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . . 8 4.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document describes an algorithm to by employed by a This document describes an algorithm to by employed by a
Certification Authority (CA) in the Resource Public Key Certification Authority (CA) in the Resource Public Key
Infrastructure (RPKI) [ID.ietf-sidr-arch] to perform a rollover of Infrastructure (RPKI) [ID.ietf-sidr-arch] to perform a rollover of
its key pair. its key pair.
This document defines a conservative procedure for such entities to This document defines a conservative procedure for such entities to
follow when performing a key rollover, so that Relying Parties are in follow when performing a key rollover, so that Relying Parties are in
skipping to change at page 3, line 33 skipping to change at page 3, line 33
Extensions for IP Addresses and AS Identifiers" [RFC3779], the Extensions for IP Addresses and AS Identifiers" [RFC3779], the
profile for RPKI Certificates [ID.ietf-sidr-res-certs], and the RPKI profile for RPKI Certificates [ID.ietf-sidr-res-certs], and the RPKI
repository structure [ID.ietf-sidr-repos-struct] . repository structure [ID.ietf-sidr-repos-struct] .
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 RFC 2119.
2. CA Key Rollover Procedure 2. CA Key Rollover Procedure
A certification Authority (CA) in the RPKI is an entity that issues A Certification Authority (CA) in the Resource Public Key
certificates and CRLs. Over time, there will be many instances of a Infrastructure (RPKI) is an entity that issues certificates and
CA. A CA instance is associated with a single key pair Certificate Revocation Lists (CRLs). A CA instance is associated
([ID.ietf-sidr-res-certs]). The implication in the context of key with a single key pair ([ID.ietf-sidr-res-certs]), implying that if
rollover is that, strictly speaking, a CA does not perform a key key rollover is a regularly scheduled event then, over time, there
will be many instances of a CA. The implication in the context of
key rollover is that, strictly speaking, a CA does not perform a key
rollover per se. In order to perform the equivalent of a key rollover per se. In order to perform the equivalent of a key
rollover, the CA creates a new instance of itself, with a new key rollover, the CA creates a "new" instance of itself, with a new key
pair, and then substitutes this new CA instance into the RPKI pair, and then effectively substitutes this "new" CA instance into
hierarchy in place of the old CA instance. the RPKI hierarchy in place of the old CA instance.
There are several considerations regarding this procedure that MUST There are several considerations regarding this procedure that MUST
be followed by a CA performing a key rollover operation. The be followed by a CA performing a key rollover operation. The
critical consideration is that the RPKI has potential application in critical consideration is that the RPKI has potential application in
the area of control of routing integrity [ID.ietf-sidr-arch], , and the area of control of routing integrity [ID.ietf-sidr-arch], and key
key rollover should not cause any transient hiatus where a Relying rollover should not cause any transient hiatus where a Relying Party
Party (RP) is led to incorrect conclusions regarding the authenticity (RP) is led to incorrect conclusions regarding the authenticity of
of attestations made in the context of the RPKI. A CA cannot assume attestations made in the context of the RPKI. A CA cannot assume
that all RPs will perform path validation and path discovery in the that all RPs will perform path validation and path discovery in the
same fashion, and therefore the key rollover procedure MUST preserve same fashion, and therefore the key rollover procedure MUST preserve
the integrity of the CRLDP, SIA and AIA pointers in RPKI the integrity of the CRL Distribution Points (CRLDP), Subject
certificates. Information Access (SIA) and Authority Information Access (AIA)
pointers in RPKI certificates.
In the procedure described here, the CA creates a new CA instance, In the procedure described here, the CA creates a "new" CA instance,
and has the associated new public key published in the form of a new and has the associated new public key published in the form of a
CA certificate. While the current and new CA instances share a "new" CA certificate. While the "current" and "new" CA instances
single repository publication point, each CA has its own CRL and its share a single repository publication point, each CA has its own CRL
own manifest. Initially, the new CA publishes an empty CRL and a and its own manifest. Initially, the "new" CA publishes an empty CRL
manifest that contains a single entry for the CRL. The "current" CA and a manifest that contains a single entry for the CRL. The
also maintains its published CRL and manifest at this Repository "current" CA also maintains its published CRL and manifest at this
publication point. Repository publication point.
The CA performing key rollover waits for a period of time to afford The CA performing key rollover waits for a period of time to afford
every RP an opportunity to discover and retrieve this new CA every RP an opportunity to discover and retrieve this "new" CA
certificate, and store it in its local RPKI Repository cache certificate, and store it in its local RPKI Repository cache
instance. This period of time is termed the "staging period". instance. This period of time is termed the "staging period".
During this period, the CA will have a new CA instance, with no During this period, the CA will have a "new" CA instance, with no
subordinate products, and a current CA instance that has issued all subordinate products, and a "current" CA instance that has issued all
subordinate products. At the expiration of the staging period the subordinate products. At the expiration of the staging period the
new CA instance MUST replace all (valid) subordinate products of the "new" CA instance MUST replace all (valid) subordinate products of
current CA instance, overwriting the current subordinate products in the "current" CA instance, overwriting the "current" subordinate
the CA's repository publication point. When this process is complete products in the CA's repository publication point. When this process
the current CA instance is retired, and the new CA instance becomes is complete the "current" CA instance is retired, and the "new" CA
the current CA. instance becomes the "current" CA.
During the transition of the current and new CA instances it is During the transition of the "current" and "new" CA instances it is
necessary for the new CA instance to re-issue all subordinate necessary for the "new" CA instance to re-issue all subordinate
products of the current CA. The procedure described here requires products of the "current" CA. The procedure described here requires
that, with the exception of manifests and CRLs, the re-issued that, with the exception of manifests and CRLs, the re-issued
subordinate products be published using the same repository subordinate products be published using the same repository
publication point object names, effectively overwriting the old publication point object names, effectively overwriting the old
objects with these re-issued objects. The intent of this overwriting objects with these re-issued objects. The intent of this overwriting
operation is to ensure that the AIA pointers of subordinate products operation is to ensure that the AIA pointers of subordinate products
at lower tiers in the RPKI hierarchy remain correct, and that CA key at lower tiers in the RPKI hierarchy remain correct, and that CA key
rollover does not require any associated actions by any subordinate rollover does not require any associated actions by any subordinate
CA. CA.
There are three CA states described here: There are three CA states described here:
skipping to change at page 5, line 34 skipping to change at page 5, line 34
1. Generate a new key pair for use by the NEW CA. Because the 1. Generate a new key pair for use by the NEW CA. Because the
goal of this algorithm is key rollover, the key pair generated goal of this algorithm is key rollover, the key pair generated
in this step MUST be different from the pair in use by the in this step MUST be different from the pair in use by the
CURRENT CA. CURRENT CA.
2. Generate a certificate request with this key pair and pass the 2. Generate a certificate request with this key pair and pass the
request to the CA that issued the CURRENT CA certificate. request to the CA that issued the CURRENT CA certificate.
This request MUST include the same SIA extension that is This request MUST include the same SIA extension that is
present in the CURRENT CA certificate. This request, when present in the CURRENT CA certificate. This request, when
satisfied, will result in the publication of the NEW CA satisfied, will result in the publication of the NEW CA
certificate. This (NEW) CA certificate will contain an certificate. This (NEW) CA certificate will contain a Subject
Subject Name selected by the issuer, which MUST be distinct Name selected by the issuer, which MUST be distinct from the
from the Subject Name used in the CURRENT CA certificate. The Subject Name used in the CURRENT CA certificate. The CPS for
CPS for the issuer of the NEW CA certificate will indicate the the issuer of the NEW CA certificate will indicate the time
time frame within which a certificate request is expected to frame within which a certificate request is expected to be
be processed. processed.
3. Publish the NEW CA's CRL and manifest. 3. Publish the NEW CA's CRL and manifest.
The steps involved here are: The steps involved here are:
- Wait for the issuer of the NEW CA to publish the NEW CA - Wait for the issuer of the NEW CA to publish the NEW CA
certificate. certificate.
- As quickly as possible following the publication of the - As quickly as possible following the publication of the
NEW CA certificate, use the key pair associated with the NEW CA certificate, use the key pair associated with the
skipping to change at page 6, line 29 skipping to change at page 6, line 29
- Destroy the private key associated with the manifest EE - Destroy the private key associated with the manifest EE
certificate. certificate.
4. The NEW CA enters a Staging Period. This duration of the 4. The NEW CA enters a Staging Period. This duration of the
Staging Period is determined by the CA, but it MUST be no less Staging Period is determined by the CA, but it MUST be no less
than 24 hours. The Staging Period is intended to afford an than 24 hours. The Staging Period is intended to afford an
opportunity for all RPs to download the NEW CA certificate, opportunity for all RPs to download the NEW CA certificate,
prior to publication of certificates, CRLs, and RPKI signed prior to publication of certificates, CRLs, and RPKI signed
objects under the NEW CA. During the Staging Period, the NEW objects under the NEW CA. During the Staging Period, the NEW
CA SHOULD reissue, but not publish, all of the products that CA SHOULD re-issue, but not publish, all of the products that
were issued under the CURRENT CA. This includes all CA were issued under the CURRENT CA. This includes all CA
certificates, EE certificates, and RPKI signed objects. certificates, EE certificates, and RPKI signed objects.
Section 4 describes how each reissued product relates to the Section 4 describes how each re-issued product relates to the
product that it replaces. During the Staging Period, the product that it replaces. During the Staging Period, the
CURRENT CA SHOULD continue to accept and process certificate CURRENT CA SHOULD continue to accept and process certificate
issuance requests and MUST continue to accept and process issuance requests and MUST continue to accept and process
certificate revocation requests. If any certificates are certificate revocation requests. If any certificates are
issued by the CURRENT CA during the staging period, they MUST issued by the CURRENT CA during the staging period, they MUST
be re-issued under the NEW CA during the period. Any be re-issued under the NEW CA during the period. Any
certificates that are revoked under the CURRENT CA MUST NOT be certificates that are revoked under the CURRENT CA MUST NOT be
re-issued under the NEW CA. re-issued under the NEW CA.
5. Upon expiration of the Staging Period, the NEW CA MUST publish 5. Upon expiration of the Staging Period, the NEW CA MUST publish
the signed products that have been re-issued under the NEW CA, the signed products that have been re-issued under the NEW CA,
replacing the corresponding products issued under the CURRENT replacing the corresponding products issued under the CURRENT
CA at the NEW CA's repository publication point. This CA at the NEW CA's repository publication point. This
replacement is implied by the file naming requirements imposed replacement is implied by the file naming requirements imposed
by [ID.ietf-sidr-repos-struct] for these signed products. The by [ID.ietf-sidr-repos-struct] for these signed products. The
trivial manifest for the NEW CA (which contained only one trivial manifest for the NEW CA (which contained only one
entry, for the NEW CA's CRL) is replaced by a manifest listing entry, for the NEW CA's CRL) is replaced by a manifest listing
all of these reissued, signed products. At this point the all of these re-issued, signed products. At this point the
CURENT CA becomes the OLD CA, and the NEW CA becomes the CURRENT CA becomes the OLD CA, and the NEW CA becomes the
CURRENT CA. Use the OLD CA to issue a manifest that lists CURRENT CA. Use the OLD CA to issue a manifest that lists
only the OLD CA's CRL. It is anticipated that this step is only the OLD CA's CRL. It is anticipated that this step is
very brief, perhaps a few minutes in duration, because the CA very brief, perhaps a few minutes in duration, because the CA
has reissued all of the signed products during the Staging has re-issued all of the signed products during the Staging
Period. Nonetheless, it is desirable that the activities Period. Nonetheless, it is desirable that the activities
performed in this step be viewed as atomic by RPs. performed in this step be viewed as atomic by RPs.
6. Generate a certificate revocation request for the OLD CA 6. Generate a certificate revocation request for the OLD CA
certificate and submit it to the issuer of that certificate. certificate and submit it to the issuer of that certificate.
When the OLD CA certificate is revoked, the CRL for the OLD CA When the OLD CA certificate is revoked, the CRL for the OLD CA
is removed from the repository, along with the manifest for is removed from the repository, along with the manifest for
the OLD CA. The private key for the OLD CA is destroyed. the OLD CA. The private key for the OLD CA is destroyed.
3. Relying Party Requirements 3. Relying Party Requirements
This procedure defines a Staging Period for CAs performing a key This procedure defines a Staging Period for CAs performing a key
rollover operation. This period is defined as a period no shorter rollover operation. This period is defined as a period no shorter
than 24 hours. than 24 hours.
RPs who maintain a local cache of the distributed RPKI repository RPs who maintain a local cache of the distributed RPKI repository
MUST perform a local cache synchronisation operation against the MUST perform a local cache synchronisation operation against the
distributed RPKI repository at regular intervals of no longer than 24 distributed RPKI repository at regular intervals of no longer than 24
hours. hours.
4. Reissuing Certificates and RPKI Signed Objects 4. Re-issuing Certificates and RPKI Signed Objects
This section provides rules a CA MUST use when it reissues This section provides rules a CA MUST use when it re-issues
certificates and RPKI signed objects as part of the key rollover subordinate certificates and RPKI signed objects
process. Note that CRLs and manifests are not reissued, per se. [ID.ietf-sidr-signed-object] as part of the key rollover process.
They are generated for each CA instance. A manifest catalogues the Note that CRLs and manifests are not re-issued, per se. They are
contents of a publication point relative to a CA instance. A CRL generated for each CA instance. A manifest catalogues the contents
lists revoked certificates, relative to a CA instance. Key rollover of a publication point relative to a CA instance. A CRL lists
revoked certificates, relative to a CA instance. Key rollover
processing for CRLs and manifests is described above, in Section 3. processing for CRLs and manifests is described above, in Section 3.
4.1. CA Certificates 4.1. CA Certificates
When a CA, as part of the key rollover process, reissues a CA When a CA, as part of the key rollover process, re-issues a CA
certificate, it copies all of the field and extension values from the certificate, it copies all of the field and extension values from the
old certificate into the new certificate. The only exceptions to old certificate into the new certificate. The only exceptions to
this rule are that the notBefore value MAY be set to the current date this rule are that the notBefore value MAY be set to the current date
and time, and the certificate serial number MAY change. Becuase the and time, and the certificate serial number MAY change. Because the
reissued CA certificate is issued by a different CA instance, it is re-issued CA certificate is issued by a different CA instance, it is
not a requirement that the certificate serial number change in the not a requirement that the certificate serial number change in the
reissued certificate. Nonetheless, the CA MUST ensure that each re-issued certificate. Nonetheless, the CA MUST ensure that each
certificate issued under a specific CA instance (a distinct name and certificate issued under a specific CA instance (a distinct name and
key) contains a unique serial number. key) contains a unique serial number.
4.2. RPKI Signed Objects 4.2. RPKI Signed Objects
An RPKI signed object is a CMS signed-data object, containing an EE An RPKI signed object is a CMS signed-data object, containing an EE
certificate and a payload (content). When a key rollover occurs, the certificate and a payload (content) [ID.ietf-sidr-signed-object].
EE certificate for the RPKI signed object MUST be reissued, under the When a key rollover occurs, the EE certificate for the RPKI signed
key of the NEW CA. A CA may choose to treat this EE certificate the object MUST be re-issued, under the key of the NEW CA. A CA MAY
same way that it deals with CA certificates, i.e., to copy over all choose to treat this EE certificate the same way that it deals with
fields and extensions, and MAY change only the notBefore date and the CA certificates, i.e., to copy over all fields and extensions, and
serial number. If the CA adopts this approach, then the new EE MAY change only the notBefore date and the serial number. If the CA
certificate is inserted into the CMS wrapper, but the signed context adopts this approach, then the new EE certificate is inserted into
remains the same. (If the signing time or binary signing time values the CMS wrapper, but the signed context remains the same. (If the
in the CMS wrapper are non-null, they MAY be updated to reflect the signing time or binary signing time values in the CMS wrapper are
current time.) Alternatively, the CA MAY elect to generate a new key non-null, they MAY be updated to reflect the current time.)
pair for this EE certificate. If it does so, the object content MUST Alternatively, the CA MAY elect to generate a new key pair for this
be resigned under the private key corresponding to the EE EE certificate. If it does so, the object content MUST be resigned
certificate. In this case the EE certificate MUST contain a new under the private key corresponding to the EE certificate. In this
public key and a new notBefore value, it MAY contain a new notAfter case the EE certificate MUST contain a new public key and a new
value, but all other field and extension values remain constant. If notBefore value, it MAY contain a new notAfter value, but all other
the signing time or binary signing time values in the CMS wrapper are field and extension values remain constant. If the signing time or
non-null, they MAY be updated to reflect the current time. binary signing time values in the CMS wrapper are non-null, they MAY
be updated to reflect the current time.
5. Security Considerations 5. Security Considerations
No key should be used forever. The longer a key is in use, the No key should be used forever. The longer a key is in use, the
greater the probability that it will have been compromised through greater the probability that it will have been compromised through
carelessness, accident, espionage, or cryptanalysis. Infrequent key carelessness, accident, espionage, or cryptanalysis. Infrequent key
rollover increases the risk that the rollover procedures will not be rollover increases the risk that the rollover procedures will not be
followed to the appropriate level of precision, increasing the risk followed to the appropriate level of precision, increasing the risk
of operational failure of some form in the key rollover process. of operational failure of some form in the key rollover process.
Regular scheduling of key rollover is generally considered to be a Regular scheduling of key rollover is generally considered to be a
skipping to change at page 8, line 49 skipping to change at page 9, line 4
These considerations imply that in setting local key lifetime as part These considerations imply that in setting local key lifetime as part
of a CA's local policy settings, the CA should endeavour to ensure of a CA's local policy settings, the CA should endeavour to ensure
that operational keys are rolled at regularly scheduled intervals that operational keys are rolled at regularly scheduled intervals
that are sufficiently long that the cumulative load generated by that are sufficiently long that the cumulative load generated by
local key rollover events across the entire RPKI does not impose an local key rollover events across the entire RPKI does not impose an
excessive burden upon the population of RPs in terms of their excessive burden upon the population of RPs in terms of their
endeavours to maintain an accurate local cache of the current state endeavours to maintain an accurate local cache of the current state
of the RPKI, but also sufficiently frequent that the risks of key of the RPKI, but also sufficiently frequent that the risks of key
compromise arising from the extended use of an individual key do not compromise arising from the extended use of an individual key do not
become excessive, and that there is local operational competence in become excessive, and that there is local operational competence in
terms of the operation of the local key rollover procesure. terms of the operation of the local key rollover procedure.
6. IANA Considerations 6. 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.]
7. Acknowledgements 7. Acknowledgements
The authors would like to acknowledge the review comments of Tim The authors would like to acknowledge the review comments of Tim
Bruijnzeels in preparing this document. Bruijnzeels and Sean Turner in preparing this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ID.ietf-sidr-repos-struct]
Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", Internet
Draft draft-ietf-sidr-repos-struct-04.txt, May 2010.
[ID.ietf-sidr-res-certs]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", Internet
Draft draft-ietf-sidr-res-certs-18.txt, May 2010.
[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.
[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.
8.2. Informative References 8.2. Informative References
[ID.ietf-sidr-arch] [ID.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-11 (work in Secure Internet Routing", draft-ietf-sidr-arch-11 (work in
progress), September 2010. progress), September 2010.
[ID.ietf-sidr-repos-struct] [ID.ietf-sidr-signed-object]
Huston, G., Loomans, R., and G. Michaleson, "A Profile for Lepinski, M., Chi, A., and S. Kent, "Signed Object
Resource Certificate Repository Structure", Internet Template for the Resource Public Key Infrastructure",
Draft draft-ietf-sidr-repos-struct-04.txt, May 2010. draft-ietf-sidr-signed-object-01.txt (work in progress),
October 2010.
[ID.ietf-sidr-res-certs]
Huston, G., Michaleson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", Internet
Draft draft-ietf-sidr-res-certs-18.txt, May 2010.
Authors' Addresses Authors' Addresses
Geoff Huston Geoff Huston
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
Email: gih@apnic.net Email: gih@apnic.net
URI: http://www.apnic.net URI: http://www.apnic.net
George Michaelson George Michaelson
 End of changes. 29 change blocks. 
101 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/