OCSPv2: It's like asking Eddie the Shipboard Computer for tea!

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Network Working Group                                          P.Gutmann
draft-ietf-pkix-ocsp-sensible-id-00.txt           University of Auckland
Target category: Informational                             November 2002
Expires in 6 months

                   X.509 Internet Public Key Infrastructure
                        Sensible Identifiers for OCSP

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

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.

Copyright Notice

Copyright (C) The Internet Society (1999-2002).  All Rights Reserved.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in
uppercase, as shown) are to be interpreted as described in [RFC2119].

1. Abstract

Ever since its inception, the OCSP protocol has attracted an array of strange
and bizarre ways of identifying certificates, none of which are even remotely
compatible with existing practice such as issuerAndSerialNumber (CMS and
S/MIME), keyIdentifier (X.509 and PKIX), and certificate "fingerprints" or
"thumbprints" (widely used in practice to uniquely identify certificates).
This document defines a simple, straightforward certificate identifier
mechanism which reflects industry standards and established practice.

The document specifies a single item, SensibleIdentifier.

2. SensibleIdentifier

This OCSP extension is used to identify the certificate being queried in a
simple, straightforward, and standard manner.  When a compliant
implementations encounters a request containing this identifier, it SHOULD
ignore whatever gobbledigook may be present in the OCSP reqCert field (it's
hard to tell what this will be, since it changes at random on every draft) and
use the SensibleIdentifier instead.

id-pkix-ocsp-sensibleIdentifier OBJECT IDENTIFIER ::= { TBD }

SensibleIdentifier ::= CHOICE {
    issuerSerial      IssuerandSerialNumber,
    keyIdentifier [0] KeyIdentifier,
    certificate   [1] Certificate,
    certHash          OCTET STRING
    ...
    }

   issuerAndSerialNumber uniquely identifies a certificate by the
   distinguished name of the certificate issuer and an issuer-specific
   certificate serial number [RFC 3369].  This identifier is widely used in
   CMS and S/MIME, and may be trivially generated from any X.509 certificate.
   
   The keyIdentifier extension provides a means of identifying certificates
   that contain a particular public key [RFC 3280].  This identifier is not
   widely used (issuerAndSerialNumber is used in its place), but is mandatory
   in [RFC 3280] and present in a majority of certificates, so it is included
   here.  Note that this identifier has special semantics, see the Security
   Considerations and [RFC 3280] for more information.

   certificate is the entire certificate.  This identifier type is
   tautological, and may be required in cases where the recipient is expected
   to extract identification information itself.
   
   certHash is an SHA-1 hash of the certificate.  Almost everything implements
   this (variously as "fingerprint" or "thumbprint" or some other name), the
   ID type is widely recognised, and interoperability/correctness checking is
   trivial to achieve.  This type may be used where the overhead of sending
   the full certificate is not desired, for example in crypto tokens or mobile
   devices which don't have the resources to handle a full OCSP implementation
   and which merely populate a pre-generated query with a fresh nonce and
   20-byte certHash.
   
References

[RFC 3369] "Cryptographic Message Syntax (CMS)", Russ Housley, August 2002.

[RFC 3280] "Internet X.509 Public Key Infrastructure: Certificate and CRL
            Profile", RFC 3280, Russ Housley, Warwick Ford, Tim Polk and
            David Solo, April 2002.

3. Security considerations

The semantics for KeyIdentifier are somewhat different from the other
identifier types.  The keyIdentifier uniquely identifies a key rather than a
certificate.  Implementors should be aware that the use of this identifier
will indicate that a certificate for the corresponding key is not-revoked, but
not necessarily the certificate they have.  In other words, it may be used to
determine that the *key* is not-revoked, not the particular certificate.  See
[RFC 3280] for more details on the use of KeyIdentifiers.

The outer DER wrapper of a certificate may use multiple encodings which result
in the same inner content having a different overall hash value.  By varying
the encoding, it's possible to convert a "revoked" into an "unknown" status
(although not a "not-revoked" status).  The same effect may be obtained by
changing a bit or two in other parts of the message or certificate.  In case
this is a security concern (that is, if for some reason the implementation
treats an "unknown" response as "certificate is valid" rather than
"certificate is invalid") then implementations should avoid the use of
certHash.

Author Address

Peter Gutmann
University of Auckland
Private Bag 92019
Auckland, New Zealand

EMail: pgut001@xxxxxxxxxxxxxxxxx

Full Copyright Statement

Copyright (C) The Internet Society (1999).  All Rights Reserved.

This document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and derivative
works.  However, this document itself may not be modified in any way, such as
by removing the copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined in the
Internet Standards process must be followed, or as required to translate it
into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by
the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.