< draft-ietf-sidr-rpki-algs-02.txt   draft-ietf-sidr-rpki-algs-03.txt >
SIDR G. Huston SIDR G. Huston
Internet-Draft APNIC Internet-Draft APNIC
Intended status: Standards Track October 8, 2010 Intended status: Standards Track October 8, 2010
Expires: April 11, 2011 Expires: April 11, 2011
A Profile for Algorithms and Key Sizes for use in the Resource Public A Profile for Algorithms and Key Sizes for use in the Resource Public
Key Infrastructure Key Infrastructure
draft-ietf-sidr-rpki-algs-02.txt draft-ietf-sidr-rpki-algs-03.txt
Abstract Abstract
This document defines a profile for the algorithm and key size to be This document specifies the algorithms, algorithms' parameters,
used for signatures applied to certificates, Certificate Revocation asymmetric key formats, asymmetric key size and signature format for
Lists, and signed objects in the context of the Resource Public Key the Resource Public Key Infrastructure subscribers that generate
Infrastructure. digital signatures on certificates, Certificate Revocation Lists, and
signed objects as well as for the Relying Parties (RPs) that verify
these 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/.
skipping to change at page 2, line 7 skipping to change at page 2, line 9
(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
described in the Simplified BSD License. described in the Simplified BSD License.
1. Introduction 1. Introduction
This document defines a profile for the algorithm and key size to be This document specifies:
used for signatures applied to certificates, Certificate Revocation
Lists (CRLs), and signed objects in the context of the Resource
Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch].
This section of the profile is specified in a distinct profile * the digital signature algorithm and parameters;
document, referenced by the RPKI Certificate Policy (CP) * the hash algorithm and parameters;
[I-D.ietf-sidr-cp] and the RPKI Certificate Profile * the public and private key formats; and,
[I-D.ietf-sidr-res-certs], in order to allow for a degree of * the signature format
algorithm and key agility in the RPKI, while permitting some longer used by Resource Public Key Infrastructure (RPKI) subscribers when
term stability in the CP and Certificate Profile specifications. they apply digital signatures to certificates, Certificate Revocation
Lists (CRLs), and signed objects (e.g., Route Origin Authorizations
(ROAs) and manifests). Relying Parties (RPs) also use this document
when verify RPKI subscribers' digital signatures [ID.ietf-sidr-arch].
This document is referenced by other RPKI profiles and
specifications, including the RPKI Certificate Policy (CP)
[ID.ietf-sidr-cp], the RPKI Certificate Profile
[ID.ietf-sidr-res-certs], the SIDR architecture [ID.ietf-sidr-arch],
and the signed object template for the RPKI
[ID.ietf-sidr-signed-object]. Familiarity with these documents is
assumed.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC2119.
2. Algorithm and Key Size 2. Algorithms
This profile specifies the use of RSASSA-PKCS1-v1_5 [RFC3447] with Two cryptographic algorithms are used in the RPKI:
the SHA-256 hash algorithm to compute the signature of certificates,
CRLs, and signed objects in the context of the RPKI. Accordingly,
the OID value in the RPKI for such signatures MUST be
1.2.840.113549.1.1.11 (sha256WithRSAEncryption). The RSA key pairs
used to compute the signatures MUST have a 2048-bit modulus and a
public exponent (e) of 65,537.
In order to facilitate a potential need to transition to stronger * The signature algorithm used in certificates, CRLs, and signed
cryptographic algorithms in the future, Certification Authorities objects is RSA Public-Key Cryptography Standards (PKCS) #1
(CAs) and Relying Parties (RPs) SHOULD be able to generate and verify Version 1.5 (sometimes referred to as "RSASSA-PKCS1-v1_5") from
RSASSA-PKCS1-v1_5 signatures using the SHA-512 hash algorithm and RSA Section 5 of [RFC4055].
key sizes of 3072 and 4096 bits.
3. Future Upates * The hashing algorithm used in certificates, CRLs, and signed
objects is SHA-256 [SHS]. Hash algorithms are not identified
by themselves in certificates and CRLs instead they are
combined with the digital signature algorithm (see below).
When used in the Cryptographic Message Syntax (CMS) SignedData,
the hash algorithm (in this case, the hash algorithm is
sometimes called a message digest algorithm) is identified by
itself. For CMS SignedData, the object identifier and
parameters for SHA-256 in [RFC5754] MUST be used when
populating the digestAlgorithms and digestAlgorithm fields.
NOTE: The exception to the above hashing algorithm is the use
of SHA-1 [SHS] when CAs generate authority and subject key
identifiers [ID.ietf-sidr-res-certs].
When used to generate and verify digital signatures the hash and
digital signature algorithms are referred together, i.e., "RSA PKCS#1
v1.5 with SHA-256" or more simply "RSA with SHA-256". The Object
Identifier (OID) sha256withRSAEncryption from [RFC4055] MUST be used.
Locations for this OID are as follows:
In the certificate, the OID appears in the signature and
signatureAlgorithm fields [RFC4055];- In the CRL, the OID appears
in the signatureAlgorithm field [RFC4055]; and,- In CMS
SignedData, the OID appears in each SignerInfo signatureAlgoithm
field [RFC3370] using the OID from above.
3. Asymmetric Key Pair Formats
The RSA key pairs used to compute the signatures MUST have a 2048-bit
modulus and a public exponent (e) of 65,537.
3.1. Public Key Format
The Subject's public key is included in subjectPublicKeyInfo
[RFC5280]. It has two sub-fields: algorithm and subjectPublicKey.
The values for the structures and their sub-structures follow:
algorithm (which is an AlgorithmIdentifier type):
The object identifier for RSA PKCS#1 v1.5 with SHA-256 MUST be
used in the algorithm field, as specified in Section 5 of
[RFC4055]. The value for the associated parameters from that
clause MUST also be used for the parameters field.
subjectPublicKey:
RSAPublicKey MUST be used to encode the certificate's
subjectPublicKey field, as specified in [RFC4055].
3.2. Private Key Format
Local Policy determines private key format.
4. Signature Format
The structure for the certificate's signature field is as specified
in Section 1.2 of [RFC4055]. The structure for the Cryptographic
Message Syntax (CMS) SignedData's signature field is as specified in
[RFC3370].
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 updated to specify such future requirements, This profile should be updated 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 CAs and RPs SHOULD be capable of supporting a transition to allow for
the phased introduction of additional encryption algorithms and key the phased introduction of additional encryption algorithms and key
specifications, and also accomodate the orderly deprecation of specifications, and also accommodate the orderly deprecation of
previously specified algorithms and keys. Accordingly, CAs and RPs previously specified algorithms and keys. Accordingly, CAs and RPs
SHOULD be capable of supporting multiple RPKI algorithm and key SHOULD be capable of supporting multiple RPKI algorithm and key
profiles simultaneously within the scope of such anticipated profiles simultaneously within the scope of such anticipated
transitions. The recommended procedures to implement such a transitions. The recommended procedures to implement such a
transition of key sizes and algorithms is not specified in this transition of key sizes and algorithms is not specified in this
document. document.
4. Security Considerations In anticipation of a potential need to transition to stronger
cryptographic algorithms in the future, CAs and RPs SHOULD be able to
generate and verify RSASSA-PKCS1-v1_5 signatures using the SHA-512
hash algorithm and RSA key sizes of 3072 and 4096 bits.
The Security Considerations of [RFC3779], [RFC5280], and [RFC4055] 6. Security Considerations
apply to signatures as defined by this profile, and their use.
5. IANA Considerations The Security Considerations of [RFC4055], [RFC5280], and
[ID.ietf-sidr-res-certs] a apply to certificate and CRLs. The
Security Considerations of [RFC5754] apply to signed objects. No new
security are introduced as a result of this specification.
7. IANA Considerations
[There are no IANA considerations in this document.] [There are no IANA considerations in this document.]
6. Acknowledgments 8. Acknowledgments
The author acknowledges the re-use in this draft of material The author acknowledges 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. Cooper. Sean Turner has provided additional review input to this
document.
7. Normative References 9. Normative References
[I-D.ietf-sidr-arch] [ID.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch (work in Secure Internet Routing", draft-ietf-sidr-arch (work in
progress), July 2009. progress), September 2010.
[I-D.ietf-sidr-cp] [ID.ietf-sidr-cp]
Seo, K., Watro, R., Kong, D., and S. Kent, "Certificate Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
Policy (CP) for the Resource PKI (RPKI)", Policy (CP) for the Resource PKI (RPKI)",
draft-ietf-sidr-cp (work in progress), July 2009. draft-ietf-sidr-cp (work in progress), September 2010.
[I-D.ietf-sidr-res-certs] [ID.ietf-sidr-res-certs]
Husotn, G., Michaelson, G., and R. Loomans, "A Profile for Husotn, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", X.509 PKIX Resource Certificates",
draft-ietf-sidr-res-certs (work in progress), draft-ietf-sidr-res-certs (work in progress), May 2008.
February 2008.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [ID.ietf-sidr-signed-object]
Standards (PKCS) #1: RSA Cryptography Specifications Lepinski, M., Chi, A., and S. Kent, "Signed Object
Version 2.1", RFC 3447, February 2003. Template for the Resource Public Key Infrastructure",
draft-ietf-sidr-signed-object-01.txt (work in progress),
October 2010.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Addresses and AS Identifiers", RFC 3779, June 2004. Algorithms", RFC 3370, August 2002.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055, and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005. June 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, January 2010.
[SHS] National Institute of Standards and Technology (NIST),
"FIPS Publication 180-3: Secure Hash Standard", FIPS
Publication 180-3, October 2008.
Author's Address Author's Address
Geoff Huston Geoff Huston
APNIC APNIC
Email: gih@apnic.net Email: gih@apnic.net
 End of changes. 25 change blocks. 
51 lines changed or deleted 130 lines changed or added

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