Additional Methods for Generating Key Identifiers
draft-turner-additional-methods-4kis-00

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]