draft-ietf-sidr-keyroll-07.txt   draft-ietf-sidr-keyroll-08.txt 
SIDR G. Huston SIDR G. Huston
Internet-Draft G. Michaelson Internet-Draft G. Michaelson
Intended status: BCP APNIC Intended status: BCP APNIC
Expires: December 5, 2011 S. Kent Expires: January 12, 2012 S. Kent
BBN BBN
June 3, 2011 July 11, 2011
CA Key Rollover in the RPKI CA Key Rollover in the RPKI
draft-ietf-sidr-keyroll-07.txt draft-ietf-sidr-keyroll-08.txt
Abstract Abstract
This document describes how a Certification Authority (CA) in the This document describes how a Certification Authority (CA) in the
Resource Public Key Infrastructure (RPKI) performs a planned rollover Resource Public Key Infrastructure (RPKI) performs a planned rollover
of its key pair. This document also notes the implications of this of its key pair. This document also notes the implications of this
key rollover procedure for Relying Parties (RPs). In general, RPs key rollover procedure for Relying Parties (RPs). In general, RPs
are expected to maintain a local cache of the objects that have been are expected to maintain a local cache of the objects that have been
published in the RPKI repository, and thus the way in which a CA published in the RPKI repository, and thus the way in which a CA
performs key rollover impacts RPs. performs key rollover impacts RPs.
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 December 5, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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. Re-issuing Certificates and RPKI Signed Objects . . . . . . . 7 4. Re-issuing Certificates and RPKI Signed Objects . . . . . . . 7
4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 8 4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 8
4.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . 8 4.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document describes an algorithm to be employed by a This document describes an algorithm to be 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. This procedure is
a position to be able to validate all authentic objects in the RPKI "conservative" in that the CA's actions in key rollover are not
using the validation procedure described in [ID.ietf-sidr-arch] at intended to disrupt the normal operation of Relying Parties (RPs) in
all times. maintaining a local cached version of the RPKI distributed
repository. Using this procedure, RPs are in a position to be able
to validate all authentic objects in the RPKI using the validation
procedure described in [ID.ietf-sidr-arch] at all times.
1.1. Terminology and Concepts 1.1. Terminology and Concepts
It is assumed that the reader is familiar with the terms and concepts It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509
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] .
skipping to change at page 9, line 28 skipping to change at page 9, line 34
process. However, key lifetimes should be sufficiently long so that process. However, key lifetimes should be sufficiently long so that
the (system-wide) load associated with key rollover events (across the (system-wide) load associated with key rollover events (across
the entire RPKI) does not impose an excessive burden upon the the entire RPKI) does not impose an excessive burden upon the
population of RPs. RPs are encouraged to maintain an accurate local population of RPs. RPs are encouraged to maintain an accurate local
cache of the current state of the RPKI, which implies frequent cache of the current state of the RPKI, which implies frequent
queries to the RPKI repository system to detect changes. When a CA queries to the RPKI repository system to detect changes. When a CA
rekeys, it changes many signed objects, thus impacting all RPs. 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 RFC Editor, to be removed prior to publication: there are no
considerations stated in this document.] IANA 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.
8. References 8. References
8.1. Normative References 8.1. Normative References
 End of changes. 7 change blocks. 
11 lines changed or deleted 14 lines changed or added

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