draft-ietf-sidr-keyroll-03.txt   draft-ietf-sidr-keyroll-04.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 28, 2011 S. Kent Expires: May 13, 2011 S. Kent
BBN BBN
October 25, 2010 November 9, 2010
CA Key Rollover in the RPKI CA Key Rollover in the RPKI
draft-ietf-sidr-keyroll-03.txt draft-ietf-sidr-keyroll-04.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 28, 2011. This Internet-Draft will expire on May 13, 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 3, line 34 skipping to change at page 3, line 34
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 Resource Public Key A Certification Authority (CA) in the Resource Public Key
Infrastructure (RPKI) is an entity that issues certificates and Infrastructure (RPKI) is an entity that issues CA and End Entity (EE)
Certificate Revocation Lists (CRLs). A CA instance is associated certificates and Certificate Revocation Lists (CRLs). A CA instance
with a single key pair ([ID.ietf-sidr-res-certs]), implying that if is associated with a single key pair ([ID.ietf-sidr-res-certs]),
key rollover is a regularly scheduled event then, over time, there implying that if key rollover is a regularly scheduled event then,
will be many instances of a CA. The implication in the context of over time, there will be many instances of a CA. The implication in
key rollover is that, strictly speaking, a CA does not perform a key the context of key rollover is that, strictly speaking, a CA does not
rollover per se. In order to perform the equivalent of a key perform a key rollover per se. In order to perform the equivalent of
rollover, the CA creates a "new" instance of itself, with a new key a key rollover, the CA creates a "new" instance of itself, with a new
pair, and then effectively substitutes this "new" CA instance into key pair, and then effectively substitutes this "new" CA instance
the RPKI hierarchy in place of the old CA instance. into 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 key the area of control of routing integrity [ID.ietf-sidr-arch], and key
rollover should not cause any transient hiatus where a Relying Party rollover should not cause any transient hiatus where a Relying Party
(RP) is led to incorrect conclusions regarding the authenticity of (RP) is led to incorrect conclusions regarding the authenticity 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
skipping to change at page 8, line 41 skipping to change at page 8, line 41
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
part of a prudent key management practice. However, key rollover part of a prudent key management practice. However, key rollover
does impose additional operational burdens on both the CA and upon does impose additional operational burdens on both the CA and upon
the population of RPs. the population of RPs.
These considerations imply that in setting local key lifetime as part These considerations imply that in choosing lifetimes for the keys it
of a CA's local policy settings, the CA should endeavour to ensure manages, a CA should balance security and operational impact (on
that operational keys are rolled at regularly scheduled intervals RPs). A CA should perform key rollover at regularly scheduled
that are sufficiently long that the cumulative load generated by intervals. These intervals should be frequent enough to minimize the
local key rollover events across the entire RPKI does not impose an risks associated with key compromise (noted above) and to maintain
excessive burden upon the population of RPs in terms of their local operational proficiency with respect to the key rollover
endeavours to maintain an accurate local cache of the current state process. However, key lifetimes should be sufficiently long so that
of the RPKI, but also sufficiently frequent that the risks of key the (system-wide) load associated with key rollover events (across
compromise arising from the extended use of an individual key do not the entire RPKI) does not impose an excessive burden upon the
become excessive, and that there is local operational competence in population of RPs. RPs are encouraged to maintain an accurate local
terms of the operation of the local key rollover procedure. cache of the current state of the RPKI, which implies frequent
queries to the RPKI repository system to detect changes. When a CA
rekeys, it changes many signed objects, thus impacting all RPs.
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 and Sean Turner in preparing this document. Bruijnzeels and Sean Turner in preparing this document.
 End of changes. 6 change blocks. 
25 lines changed or deleted 27 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/