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

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2012-04-16
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
IETF conflict review conflict-review-turner-additional-methods-4kis
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          S. Turner
Internet Draft                                                      IECA
Intended Status: Informational                                   S. Kent
Expires: October 18, 2012                                            BBN
                                                          April 16, 2012

           Additional Methods for Generating Key Identifiers
              draft-turner-additional-methods-4kis-01.txt

Abstract

   This document specifies additional methods for generating key
   identifiers from a public key.  This document also specifies an
   extension to identify the algorithms used to generate the key
   identifiers.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   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.
 

Turner & Kent           Expires October 18, 2012                [Page 1]
Internet-Draft       Additional Methods For AKI/SKI       April 16, 2012

1.  Introduction

   [RFC5280] defines the AKI (Authority Key Identifier) and SKI (Subject
   Key Identifier) certificate extensions.  These extensions allow one
   certificate to refer to another certificate via the matching of these
   corresponding values.  The principal use of this mechanism is to
   enable a relying party to disambiguate between two CA (Certification
   Authority) certificates with the same Subject name, located in the
   same directory entry.  These identifiers are used during
   certification path construction in support of heuristics to reduce
   relying party workload.  These identifiers are not used during
   certificate path validation.  These key identifiers are used by PKI-
   enabled security protocols, such as CMP (Certificate Management
   Protocol) [RFC4210] and CMS (Cryptographic Message Syntax) [RFC5652],
   to identify the certificate used to protect a message, a session,
   etc.

   [RFC5280] describes two mechanisms for generating AKI/SKI values: a
   160-bit SHA-1 (Secure Hash Algorithm) 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.  [RFC5280] allows for additional
   mechanisms.  (This is consistent with the fact that the SKI and AKI
   extensions are always marked non-critical.)

   This document defines four additional mechanisms for generating key
   identifier values, using 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 [RFC6234]. 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 additional key identifier generation mechanisms described in this
   document 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. 
   For example, a CA that issues certificates hashed with SHA-256 and
   signed with ECDSA on the P-256 curve [RFC5480] might no longer need
   to implement SHA-1 as part of their CA application.

 

Turner & Kent           Expires October 18, 2012                [Page 2]
Internet-Draft       Additional Methods For AKI/SKI       April 16, 2012

1.1.  Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Show full document text