Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)
RFC 6489
| Document | Type |
RFC - Best Current Practice
(February 2012; Errata)
Also known as BCP 174
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Replaces | draft-huston-sidr-keyroll | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Reviews | |||
| Stream | WG state | WG Document | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 6489 (Best Current Practice) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Stewart Bryant | ||
| Send notices to | (None) | ||
Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 6489 G. Michaelson
BCP: 174 APNIC
Category: Best Current Practice S. Kent
ISSN: 2070-1721 BBN
February 2012
Certification Authority (CA) Key Rollover in
the Resource Public Key Infrastructure (RPKI)
Abstract
This document describes how a Certification Authority (CA) in the
Resource Public Key Infrastructure (RPKI) performs a planned rollover
of its key pair. This document also notes the implications of this
key rollover procedure for relying parties (RPs). In general, RPs
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
performs key rollover impacts RPs.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6489.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Huston, et al. Best Current Practice [Page 1]
RFC 6489 Key Rollover February 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
1.1. Terminology and Concepts ...................................2
2. CA Key Rollover Procedure .......................................3
3. Relying Party Requirements ......................................6
4. Reissuing Certificates and RPKI Signed Objects ..................7
4.1. CA Certificates ............................................7
4.2. RPKI Signed Objects ........................................7
5. Security Considerations .........................................8
6. Acknowledgements ................................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
1. Introduction
This document describes an algorithm to be employed by a
Certification Authority (CA) in the Resource Public Key
Infrastructure (RPKI) [RFC6480] to perform a rollover of its key
pair.
This document defines a conservative procedure for such entities to
follow when performing a key rollover. This procedure is
"conservative" in that the CA's actions in key rollover are not
intended to disrupt the normal operation of relying parties (RPs) in
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 [RFC6480] at all times.
1.1. Terminology and Concepts
It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509
Extensions for IP Addresses and AS Identifiers" [RFC3779], the
profile for RPKI Certificates [RFC6487], and the RPKI repository
structure [RFC6481] .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Show full document text