Network Working Group S. Turner Internet Draft IECA Updates: 5280 (once approved) S. Kent Intended Status: Standards Track BBN Expires: December 15, 2010 June 15, 2010 Additional Methods for Generating Key Identifiers draft-turner-additional-methods-4kis-00.txt Abstract This document specifies additional methods for generating key identifiers from a public key. This document updates RFC 5280. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 15, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Turner & Kent Expires December 15, 2010 [Page 1] Internet-Draft Additional Methods For AKI/SKI June 2010 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. 1. Introduction [PKIX] defines the authority key identifier and subject key identifier certificate extensions to allow one certificate to refer to another certificate via the matching of these corresponding values. The principle use of this mechanism is to enable a relying party to disambiguate between two CA certificates with the same Subject name, located in the same directory entry. These identifiers are used during certification path construction as heuristic to reduce relying party workload. These identifiers are not used during certificate path validation. These key identifiers also are used by other protocols, such as Certificate Management Protocol (CMP) [CMP] and Cryptographic Message Syntax (CMS) [CMS], to identify the certificate used to protect the message, session, etc. [ECALGS] describes two mechanisms for generating AKI/SKI values: a 160-bit SHA-1 hash of the public key and a four-bit type field with the value 0100 followed by the least significant 60 bits of the SHA-1 hash. Both of these mechanisms were designed to be non-security critical. That is, the use a hash algorithm was intended to provide a high probability (but not a guarantee) of uniqueness. [PKIX] allows for additional mechanisms. This document defines four additional mechanisms that use SHA-224, SHA-256, SHA-384, and SHA-512 [SHS]. Sample code for SHA-224, SHA- 256, SHA-384, and SHA-512 can be found in [SHS-CODE]. The motivation for defining these additional means of generating AKI/SKI values is to accommodate use of additional, standard one-way hash functions that are becoming more widely used in PKI contexts. The plethora of options does not impact interoperability because key identifiers are unilaterally generated by Certification Authorities (CAs). Relying parties only compare and copy these values and thus are insulated (for the most part) from the specific mechanisms used to generate them. The additional key identifier generation mechanisms described below maintain the 160-bit value size, to avoid adversely affecting relying party code. With these additional mechanisms CAs can omit code for algorithms that are otherwise unwanted or unused. Turner & Kent Expires December 15, 2010 [Page 2] Internet-Draft Additional Methods For AKI/SKI June 2010 For example, a CA that issues certificates hashed with SHA-256 and signed with ECDSA on the P-256 curve [ECALGS] might no longer need to implement SHA-1 as part of their CA application. This document updates Section 4.2.1.2 of RFC 5280 [PKIX]. 1.1. Requirements Terminology 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 [WORDS]. 2. Additional Methods for Generating Key Identifiers As specified in [PKIX], both authority and subject key identifiers SHOULD be derived from the public key. Four additional mechanisms CAs can use to identify public keys are as follows: 1) The keyIdentifier is composed of the least significant 160-bits of the SHA-224 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits). 2) The keyIdentifier is composed of the least significant 160-bits of the SHA-256 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits). 3) The keyIdentifier is composed of the least significant 160-bits of the SHA-384 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits). 4) The keyIdentifier is composed of the least significant 160-bits of the SHA-512 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits). 3. Security Considerations The security considerations of [PKIX] apply. While hash algorithms provide collision resistance, this property is not needed for key identifiers. 4. IANA Considerations None. Turner & Kent Expires December 15, 2010 [Page 3] Internet-Draft Additional Methods For AKI/SKI June 2010 5. References 5.1. Normative References [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [SHS] National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008. [WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2. Informative References [CMP] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005. [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009. [ECALGS] Turner, S., Brown, D., Yiu, K., Housley, R., and W. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009. [SHS-CODE] Eastlake 3rd, D. and T. Hansen, US Secure Hash Algorithms (SHA and SHA based HMAC and HKDF), draft-eastlake-sha2b- 02.txt, work-in-progress. Turner & Kent Expires December 15, 2010 [Page 4] Internet-Draft Additional Methods For AKI/SKI June 2010 Authors' Addresses Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA EMail: turners@ieca.com Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 EMail: kent@bbn.com Turner & Kent Expires December 15, 2010 [Page 5]