draft-ietf-sidr-rpki-algs-04.txt | draft-ietf-sidr-rpki-algs-05.txt | |||
---|---|---|---|---|
SIDR G. Huston | SIDR G. Huston | |||
Internet-Draft APNIC | Internet-Draft APNIC | |||
Intended status: Standards Track November 9, 2010 | Intended status: Standards Track April 13, 2011 | |||
Expires: May 13, 2011 | Expires: October 15, 2011 | |||
A 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-rpki-algs-04.txt | draft-ietf-sidr-rpki-algs-05.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 (RPs) that verify | |||
these digital signatures. | these digital signatures. | |||
skipping to change at page 1, line 36 | skipping to change at page 1, line 36 | |||
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 May 13, 2011. | This Internet-Draft will expire on October 15, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 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 | |||
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 21 | skipping to change at page 3, line 21 | |||
identifiers [ID.ietf-sidr-res-certs]. | identifiers [ID.ietf-sidr-res-certs]. | |||
When used to generate and verify digital signatures the hash and | When used to generate and verify digital signatures the hash and | |||
digital signature algorithms are referred together, i.e., "RSA PKCS#1 | 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 | v1.5 with SHA-256" or more simply "RSA with SHA-256". The Object | |||
Identifier (OID) sha256withRSAEncryption from [RFC4055] MUST be used. | Identifier (OID) sha256withRSAEncryption from [RFC4055] MUST be used. | |||
Locations for this OID are as follows: | Locations for this OID are as follows: | |||
In the certificate, the OID appears in the signature and | In the certificate, the OID appears in the signature and | |||
signatureAlgorithm fields [RFC4055];- In the CRL, the OID appears | signatureAlgorithm fields [RFC4055]; | |||
in the signatureAlgorithm field [RFC4055]; and,- In CMS | In the CRL, the OID appears in the signatureAlgorithm field | |||
SignedData, the OID appears in each SignerInfo signatureAlgoithm | [RFC4055]; | |||
field [RFC3370] using the OID from above. | In CMS SignedData, the OID appears in each SignerInfo | |||
signatureAlgoithm field [RFC3370] using the OID from above; and, | ||||
In a certification request, the OID appears in the PKCS #10 | ||||
signatureAlgorithm field [RFC2986], or in the Certificate Request | ||||
Message Format (CRMF) POPOSigningKey signature field [RFC4211]. | ||||
3. Asymmetric Key Pair Formats | 3. Asymmetric Key Pair Formats | |||
The RSA key pairs used to compute the signatures MUST have a 2048-bit | The RSA key pairs used to compute the signatures MUST have a 2048-bit | |||
modulus and a public exponent (e) of 65,537. | modulus and a public exponent (e) of 65,537. | |||
3.1. Public Key Format | 3.1. Public Key Format | |||
The Subject's public key is included in subjectPublicKeyInfo | The Subject's public key is included in subjectPublicKeyInfo | |||
[RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. | [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. | |||
skipping to change at page 4, line 22 | skipping to change at page 4, line 26 | |||
in Section 1.2 of [RFC4055]. The structure for the Cryptographic | in Section 1.2 of [RFC4055]. The structure for the Cryptographic | |||
Message Syntax (CMS) SignedData's signature field is as specified in | Message Syntax (CMS) SignedData's signature field is as specified in | |||
[RFC3370]. | [RFC3370]. | |||
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 updated 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 | 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 accommodate 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 | |||
skipping to change at page 5, line 40 | skipping to change at page 5, line 40 | |||
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), May 2008. | draft-ietf-sidr-res-certs (work in progress), May 2008. | |||
[ID.ietf-sidr-signed-object] | [ID.ietf-sidr-signed-object] | |||
Lepinski, M., Chi, A., and S. Kent, "Signed Object | Lepinski, M., Chi, A., and S. Kent, "Signed Object | |||
Template for the Resource Public Key Infrastructure", | Template for the Resource Public Key Infrastructure", | |||
draft-ietf-sidr-signed-object-01.txt (work in progress), | draft-ietf-sidr-signed-object-01.txt (work in progress), | |||
October 2010. | October 2010. | |||
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification | ||||
Request Syntax Specification Version 1.7", RFC 2986, | ||||
November 2000. | ||||
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) | [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) | |||
Algorithms", RFC 3370, August 2002. | 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. | |||
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure | ||||
Certificate Request Message Format (CRMF)", RFC 4211, | ||||
September 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 | [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic | |||
Message Syntax", RFC 5754, January 2010. | Message Syntax", RFC 5754, January 2010. | |||
[SHS] National Institute of Standards and Technology (NIST), | [SHS] National Institute of Standards and Technology (NIST), | |||
"FIPS Publication 180-3: Secure Hash Standard", FIPS | "FIPS Publication 180-3: Secure Hash Standard", FIPS | |||
End of changes. 9 change blocks. | ||||
11 lines changed or deleted | 23 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/ |