draft-ietf-sidr-keyroll-01.txt   draft-ietf-sidr-keyroll-02.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 4, 2011 S. Kent Expires: April 10, 2011 S. Kent
BBN BBN
October 1, 2010 October 7, 2010
CA Key Rollover in the RPKI CA Key Rollover in the RPKI
draft-ietf-sidr-keyroll-01.txt draft-ietf-sidr-keyroll-02.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 4, 2011. This Internet-Draft will expire on April 10, 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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. Reissuing Certificates and RPKI Signed Objects . . . . . . . . 7
4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . . 7 4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . . 7
4.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . . 7 4.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
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.
skipping to change at page 7, line 42 skipping to change at page 7, line 42
They are generated for each CA instance. A manifest catalogues the They are generated for each CA instance. A manifest catalogues the
contents of a publication point relative to a CA instance. A CRL contents of a publication point relative to a CA instance. A CRL
lists revoked certificates, relative to a CA instance. Key rollover 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, reissues 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 is that the certificate serial number MUST change, and the this rule are that the notBefore value MAY be set to the current date
notBefore value MAY be set to the current date and time. and time, and the certificate serial number MAY change. Becuase the
reissued CA certificate is issued by a different CA instance, it is
not a requirement that the certificate serial number change in the
reissued certificate. Nonetheless, the CA MUST ensure that each
certificate issued under a specific CA instance (a distinct name and
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). When a key rollover occurs, the
EE certificate for the RPKI signed object MUST be reissued, under the EE certificate for the RPKI signed object MUST be reissued, under the
key of the NEW CA. A CA may choose to treat this EE certificate the key of the NEW CA. A CA may choose to treat this EE certificate the
same way that it deals with CA certificates, i.e., to copy over all same way that it deals with CA certificates, i.e., to copy over all
fields and extensions, and change only the serial number and the fields and extensions, and MAY change only the notBefore date and the
notBefore date. If the CA adopts this approach, then the new EE serial number. If the CA adopts this approach, then the new EE
certificate is inserted into the CMS wrapper, but the signed context certificate is inserted into the CMS wrapper, but the signed context
remains the same. (If the signing time or binary signing time values remains the same. (If the signing time or binary signing time values
in the CMS wrapper are non-null, they MAY be updated to reflect the in the CMS wrapper are non-null, they MAY be updated to reflect the
current time.) Alternatively, the CA MAY elect to generate a new key current time.) Alternatively, the CA MAY elect to generate a new key
pair for this EE certificate. If it does so, the object content MUST pair for this EE certificate. If it does so, the object content MUST
be resigned under the private key corresponding to the EE be resigned under the private key corresponding to the EE
certificate. In this case the EE certificate MUST contain a new certificate. In this case the EE certificate MUST contain a new
public key and a new notBefore value, it MAY contain a new notAfter public key and a new notBefore value, it MAY contain a new notAfter
value, but all other field and extension values remain constant. (If value, but all other field and extension values remain constant. If
the signing time or binary signing time values in the CMS wrapper are the signing time or binary signing time values in the CMS wrapper are
non-null, they MAY be updated to reflect the current time.) non-null, they MAY be updated to reflect the current time.
5. Security Considerations 5. Security Considerations
[To be added] No key should be used forever. The longer a key is in use, the
greater the probability that it will have been compromised through
carelessness, accident, espionage, or cryptanalysis. Infrequent key
rollover increases the risk that the rollover procedures will not be
followed to the appropriate level of precision, increasing the risk
of operational failure of some form in the key rollover process.
Regular scheduling of key rollover is generally considered to be a
part of a prudent key management practice. However, key rollover
does impose additional operational burdens on both the CA and upon
the population of RPs.
These considerations imply that in setting local key lifetime as part
of a CA's local policy settings, the CA should endeavour to ensure
that operational keys are rolled at regularly scheduled intervals
that are sufficiently long that the cumulative load generated by
local key rollover events across the entire RPKI does not impose an
excessive burden upon the population of RPs in terms of their
endeavours to maintain an accurate local cache of the current state
of the RPKI, but also sufficiently frequent that the risks of key
compromise arising from the extended use of an individual key do not
become excessive, and that there is local operational competence in
terms of the operation of the local key rollover procesure.
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 in preparing this document.
 End of changes. 11 change blocks. 
16 lines changed or deleted 42 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/