draft-ietf-sidr-rfc6485bis-01.txt   draft-ietf-sidr-rfc6485bis-02.txt 
SIDR G. Huston SIDR G. Huston
Internet-Draft G. Michaelson, Ed. Internet-Draft G. Michaelson, Ed.
Obsoletes: 6485 (if approved) APNIC Obsoletes: 6485 (if approved) APNIC
Intended status: Standards Track March 28, 2014 Intended status: Standards Track May 15, 2015
Expires: September 29, 2014 Expires: November 16, 2015
The Profile for Algorithms and Key Sizes for use in the Resource Public The Profile for Algorithms and Key Sizes for use in the Resource Public
Key Infrastructure Key Infrastructure
draft-ietf-sidr-rfc6485bis-01.txt draft-ietf-sidr-rfc6485bis-02.txt
Abstract Abstract
This document specifies the algorithms, algorithms' parameters, This document specifies the algorithms, algorithms' parameters,
asymmetric key formats, asymmetric key size and signature format for asymmetric key formats, asymmetric key size and signature format for
the Resource Public Key Infrastructure subscribers that generate the Resource Public Key Infrastructure subscribers that generate
digital signatures on certificates, Certificate Revocation Lists, and digital signatures on certificates, Certificate Revocation Lists, and
signed objects as well as for the Relying Parties (RPs) that verify signed objects as well as for the Relying Parties that verify these
these digital signatures. digital signatures.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 29, 2014. This Internet-Draft will expire on November 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 12 skipping to change at page 3, line 12
When used in the context of the Cryptographic Message Syntax When used in the context of the Cryptographic Message Syntax
(CMS) SignedData, the hashing algorithm is identified (CMS) SignedData, the hashing algorithm is identified
individually (in this case the hashing algorithm is sometimes individually (in this case the hashing algorithm is sometimes
called a message digest algorithm). called a message digest algorithm).
NOTE: The exception to the above hashing algorithm use is the NOTE: The exception to the above hashing algorithm use is the
use of SHA-1 [SHS] when CAs generate authority and subject key use of SHA-1 [SHS] when CAs generate authority and subject key
identifiers [RFC6487]. identifiers [RFC6487].
For generating and verifying certificates, and CRLs the hashing and For generating and verifying certificates and CRLs the hashing and
digital signature algorithms are referred to together, i.e., "RSA digital signature algorithms are referred to together, i.e., "RSA
PKCS#1 v1.5 with SHA-256" or more simply "RSA with SHA-256". The PKCS#1 v1.5 with SHA-256" or more simply "RSA with SHA-256". The
Object Identifier (OID) sha256WithRSAEncryption from [RFC4055] MUST Object Identifier (OID) sha256WithRSAEncryption from [RFC4055] MUST
be used in this case. be used in this case.
For CMS SignedData, the object identifier and parameters for SHA-256 For CMS SignedData, the object identifier and parameters for SHA-256
in [RFC5754] MUST be used for the SignedData digestAlgorithms field in [RFC5754] MUST be used for the SignedData digestAlgorithms field
and the SignerInfo digestAlgorithm field when generating and and the SignerInfo digestAlgorithm field when generating and
verifying CMS SignedData objects. The object identifier and verifying CMS SignedData objects. The object identifier and
parameters for rsaEncryption MUST be used for the SignerInfo parameters for rsaEncryption MUST be used for the SignerInfo
skipping to change at page 4, line 41 skipping to change at page 4, line 41
5. Additional Requirements 5. Additional Requirements
It is anticipated that the RPKI will require the adoption of updated It is anticipated that the RPKI will require the adoption of updated
key sizes and a different set of signature and hash algorithms over key sizes and a different set of signature and hash algorithms over
time, in order to maintain an acceptable level of cryptographic time, in order to maintain an acceptable level of cryptographic
security to protect the integrity of signed products in the RPKI. security to protect the integrity of signed products in the RPKI.
This profile should be relaced to specify such future requirements, This profile should be relaced to specify such future requirements,
as and when appropriate. as and when appropriate.
CAs and RPs SHOULD be capable of supporting a transition to allow for Certification Authorities (CAs) and RPs SHOULD be capable of
the phased introduction of additional encryption algorithms and key supporting a transition to allow for the phased introduction of
specifications, and also accommodate the orderly deprecation of additional encryption algorithms and key specifications, and also
previously specified algorithms and keys. Accordingly, CAs and RPs accommodate the orderly deprecation of previously specified
SHOULD be capable of supporting multiple RPKI algorithm and key algorithms and keys. Accordingly, CAs and RPs SHOULD be capable of
profiles simultaneously within the scope of such anticipated supporting multiple RPKI algorithm and key profiles simultaneously
transitions. The recommended procedures to implement such a within the scope of such anticipated transitions. The recommended
transition of key sizes and algorithms is not specified in this procedures to implement such a transition of key sizes and algorithms
document. is not specified in this document.
6. Security Considerations 6. Security Considerations
The Security Considerations of [RFC4055], [RFC5280], and [RFC6487] The Security Considerations of [RFC4055], [RFC5280], and [RFC6487]
apply to certificate and CRLs. The Security Considerations of apply to certificate and CRLs. The Security Considerations of
[RFC5754] apply to signed objects. No new security are introduced as [RFC5754] apply to signed objects. No new security are introduced as
a result of this specification. a result of this specification.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 5, line 30 skipping to change at page 5, line 30
is considered to be outside the limited scope of an erratum. is considered to be outside the limited scope of an erratum.
Section 2 of [RFC6485] specified a single signature algorithm (SHA- Section 2 of [RFC6485] specified a single signature algorithm (SHA-
256) and a single CMS OID, sha256withRSAEncryption, to be used for 256) and a single CMS OID, sha256withRSAEncryption, to be used for
the SignerInfo field of the CMS object. A closer reading of the SignerInfo field of the CMS object. A closer reading of
[RFC4055] and [RFC5754] has identified that the CMS SignerInfo field [RFC4055] and [RFC5754] has identified that the CMS SignerInfo field
must support use of the rsaEncryption OID for full conformance with must support use of the rsaEncryption OID for full conformance with
the CMS specifications, and the normative references in [RFC6485] the CMS specifications, and the normative references in [RFC6485]
inherited this requirement. inherited this requirement.
This document changes Section 2 of [RFC4055]. By conforming to the This document changes Section 2 of [RFC6485]. By conforming to the
CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects
are less likely to be rejected as non-conformant with the CMS are less likely to be rejected as non-conformant with the CMS
standards. No change is made to the cryptographic status of the CMS standards. No change is made to the cryptographic status of the CMS
objects produced. This change reflects the behaviour of deployed objects produced. This change reflects the behaviour of deployed
interoperating code. No other changes have been made to the interoperating code. No other changes have been made to the
specification as described in [RFC6485]. specification as described in [RFC6485].
9. Acknowledgments 9. Acknowledgments
The author acknowledges the re-use in this draft of material The authors acknowledge the re-use in this draft of material
originally contained in working drafts the RPKI Certificate Policy originally contained in working drafts the RPKI Certificate Policy
and Resource Certificate profile documents. The co-authors of these and Resource Certificate profile documents. The co-authors of these
two documents, namely Stephen Kent, Derrick Kong, Karen Seo, Ronald two documents, namely Stephen Kent, Derrick Kong, Karen Seo, Ronald
Watro, George Michaelson and Robert Loomans, are acknowledged, with Watro, George Michaelson and Robert Loomans, are acknowledged, with
thanks. The constraint on key size noted in this profile is the thanks. The constraint on key size noted in this profile is the
outcome of comments from Stephen Kent and review comments from David outcome of comments from Stephen Kent and review comments from David
Cooper. Sean Turner has provided additional review input to this Cooper. Sean Turner has provided additional review input to this
document. document.
Andrew Chi and David Mandelberg discovered the issue addressed in Andrew Chi and David Mandelberg discovered the issue addressed in
 End of changes. 9 change blocks. 
19 lines changed or deleted 19 lines changed or added

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