draft-ietf-sidr-keyroll-04.txt   draft-ietf-sidr-keyroll-05.txt 
SIDR G. Huston SIDR G. Huston
Internet-Draft G. Michaelson Internet-Draft G. Michaelson
Intended status: BCP APNIC Intended status: BCP APNIC
Expires: May 13, 2011 S. Kent Expires: June 6, 2011 S. Kent
BBN BBN
November 9, 2010 December 3, 2010
CA Key Rollover in the RPKI CA Key Rollover in the RPKI
draft-ietf-sidr-keyroll-04.txt draft-ietf-sidr-keyroll-05.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 May 13, 2011. This Internet-Draft will expire on June 6, 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 23 skipping to change at page 2, line 23
2. CA Key Rollover Procedure . . . . . . . . . . . . . . . . . . 3 2. CA Key Rollover Procedure . . . . . . . . . . . . . . . . . . 3
3. Relying Party Requirements . . . . . . . . . . . . . . . . . . 7 3. Relying Party Requirements . . . . . . . . . . . . . . . . . . 7
4. Re-issuing 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 . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 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
skipping to change at page 8, line 23 skipping to change at page 8, line 23
CA certificates, i.e., to copy over all fields and extensions, and CA certificates, i.e., to copy over all fields and extensions, and
MAY change only the notBefore date and the serial number. If the CA MAY change only the notBefore date and the serial number. If the CA
adopts this approach, then the new EE certificate is inserted into adopts this approach, then the new EE certificate is inserted into
the CMS wrapper, but the signed context remains the same. (If the the CMS wrapper, but the signed context remains the same. (If the
signing time or binary signing time values in the CMS wrapper are 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.)
Alternatively, the CA MAY elect to generate a new key pair for this Alternatively, the CA MAY elect to generate a new key pair for this
EE certificate. If it does so, the object content MUST be resigned EE certificate. If it does so, the object content MUST be resigned
under the private key corresponding to the EE certificate. In this under the private key corresponding to the EE certificate. In this
case the EE certificate MUST contain a new public key and a new case the EE certificate MUST contain a new public key and a new
notBefore value, it MAY contain a new notAfter value, but all other notBefore value, and it MAY contain a new notAfter value, but all
field and extension values remain constant. If the signing time or other field and extension values, other that those relating to the
binary signing time values in the CMS wrapper are non-null, they MAY digital signature and its associated certificate validation path,
be updated to reflect the current time. remain unchanged. If the signing time or binary signing time values
in the CMS wrapper are non-null, they MAY be updated to reflect the
current time.
As noted in Section 2.1.6.4.3 and 2.1.6.4.4 of
[ID.ietf-sidr-signed-object], the presence or absence of the
SigningTime and/or the BinarySigningTime attribute MUST NOT affect
the validity of the RPKI signed object.
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
 End of changes. 6 change blocks. 
9 lines changed or deleted 16 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/