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]