Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)
RFC 6916
| Document | Type |
RFC - Best Current Practice
(April 2013; No errata)
Also known as BCP 182
|
|
|---|---|---|---|
| Authors | Roque Gagliano , Stephen Kent , Sean Turner | ||
| Last updated | 2015-10-14 | ||
| Replaces | draft-rgaglian-sidr-algorithm-agility | ||
| Stream | Internent Engineering Task Force (IETF) | ||
| Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Alexey Melnikov | ||
| Shepherd write-up | Show (last changed 2012-11-07) | ||
| IESG | IESG state | RFC 6916 (Best Current Practice) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Stewart Bryant | ||
| IESG note | Alexey Melnikov (alexey.melnikov@isode.com) is the Document Shepherd. | ||
| Send notices to | (None) | ||
Internet Engineering Task Force (IETF) R. Gagliano
Request for Comments: 6916 Cisco Systems
BCP: 182 S. Kent
Category: Best Current Practice BBN Technologies
ISSN: 2070-1721 S. Turner
IECA, Inc.
April 2013
Algorithm Agility Procedure
for the Resource Public Key Infrastructure (RPKI)
Abstract
This document specifies the process that Certification Authorities
(CAs) and Relying Parties (RPs) participating in the Resource Public
Key Infrastructure (RPKI) will need to follow to transition to a new
(and probably cryptographically stronger) algorithm set. The process
is expected to be completed over a timescale of several years.
Consequently, no emergency transition is specified. The transition
procedure defined in this document supports only a top-down migration
(parent migrates before children).
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/rfc6916.
Gagliano, et al. Best Current Practice [Page 1]
RFC 6916 RPKI Algorithm Agility April 2013
Copyright Notice
Copyright (c) 2013 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Key Rollover Steps for Algorithm Migration . . . . . . . . . . 6
4.1. Milestones Definition . . . . . . . . . . . . . . . . . . 6
4.2. Process Overview . . . . . . . . . . . . . . . . . . . . . 7
4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 9
4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 14
5. Support for Multiple Algorithms in the RPKI Provisioning
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Validation of Multiple Instances of Signed Products . . . . . 15
7. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Key Rollover . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Repository Structure . . . . . . . . . . . . . . . . . . . . . 17
10. Deprecating an Algorithm Suite . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
13. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Gagliano, et al. Best Current Practice [Page 2]
RFC 6916 RPKI Algorithm Agility April 2013
1. Introduction
The Resource Public Key Infrastructure (RPKI) must accommodate
transitions between the public keys used by Certification Authorities
(CAs). Transitions of this sort are usually termed "key rollover".
Planned key rollover will occur regularly throughout the life of the
RPKI, as each CA changes its public keys, in a non-coordinated
fashion. (By non-coordinated we mean that the time at which each CA
elects to change its keys is locally determined, not coordinated
across the RPKI.) Moreover, because a key change might be
Show full document text