draft-ietf-pkix-ocspv2-ext-01.txt

PKIX的RFC英文文档

Network Working Group                                            M.Myers
draft-ietf-pkix-ocspv2-ext-01.txt                    TraceRoute Security
                                                              A. Malpani
                                             Malpani Consulting Services
                                                                D.Pinkas
                                                                    Bull
Target category: Standards Track                           December 2002
Expires in 6 months


                   X.509 Internet Public Key Infrastructure
                Online Certificate Status Protocol, version 2
                      draft-ietf-pkix-ocspv2-ext-01.txt


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

   The Online Certificate Status Protocol (OCSP) enables applications to
   determine on line the revocation status of a certificate. This 
   document specifies one extension for the OCSP protocol and defines 
   a version v2 for that protocol which allows additional means to 
   designate the certificate for which the revocation status is 
   requested. It also allows to ask for the revocation status of either 
   a public key certificate (PKC) or an attribute certificate (AC).



Malpani & all                                                   [Page 1]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


2. General

   OCSP is a protocol useful in determining the current status of a 
   digital certificate without requiring CRLs. Additional mechanisms 
   addressing PKIX operational requirements are specified in separate 
   documents.

   This document specifies one extensions that may be used with OCSP 
   in a request.

   Currently the serviceLocator extension may be used in a request to 
   route the request to the OCSP server which is known to be 
   authoritative for the identified certificate. The client fills in 
   that extension by copying the AuthorityInfoAccess (AIA) field from 
   the certificate which specifies the address of the OCSP server. 

   However, if the CA that has issued the certificate has chosen to only 
   issue CRLs, and if the client wants to talk to a single OCSP server 
   to get the revocation status of a certificate, that OCSP server may 
   not know where the CRL is available. For that reason a new extension 
   is being defined to allow the OCSP server to locate the CRL. That 
   extension is called the crlLocator. The client may fill-in that 
   extension by copying the CRLDistributionPoints (CDP) field from the 
   certificate which specifies the address of the CRL repository. 

   This document also specifies OCSPv2 which differs from OCSPv1 by the 
   fact that more means are provided to specify the certificate for 
   which the revocation status is provided. OCSPv2 also allows to get 
   the revocation status of Attribute Certificates.

   RFC 2560bis allows to reference the certificate using the following 
   structure:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuer's public key
       serialNumber        CertificateSerialNumber }

   Since the hash of the issuer's public key is mandatory, the protocol 
   can only be used when a certification path has been constructed 
   before. A goal of OCSPv2 is to allow to use the protocol when the 
   only information available is either the full certificate itself or 
   an ambiguous reference of the certificate for which the query will 
   be made.

   In many cases, it is more efficient to first make sure that the 
   certificate is not revoked, before trying to build a certification 
   path and making accesses to a repository (e.g. using LDAP). 





Malpani & all                                                   [Page 2]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002

   In addition, since only the hash of the issuer name is transmitted, 
   it was not easy for the OCSP responder, when using OCSPv1, to 
   identify the CA, unless working with an a priori list of CAs. The 
   goal of that extension is also to allow to fulfill the service, even 
   when the CAs are not a priori known to the OCSP responder.

OCSPv2 still allows the use of CertID (for backward compatibility), but 
allows for two other options:

   a) to send the full certificate,

   b) to send the issuer name, the certificate serial number, a hash 
      value computed over the ASN.1 DER encoded tbsCertificate field 
      from the certificate, and the signature (value and algorithm 
      identifier) of the certificate.

The hash value is computed using the hash function designated in the 
algorithm identifier of the signature.

   While sending the whole certificate allows an OCSP server to pick up 
   any information from the certificate, the certificate while being 
   transmitted may be observed.  A confidentiality service would 
   certainly provide an adequate protection, but the protocol will not 
   release private information, if only the issuer name, the 
   certificate serial number, a hash value and the signature are 
   disclosed.  In this way the second option may be preferable.  It is 
   up to the client to decide which option suits its needs.

   The OCSP response has been extended to cover the same possibilities 
   (the OCSP server simply copies what it received).

   In this document, the terms client and requestor are used
   interchangeably to indicate the entity making the OCSP request,
   while the terms server and responder are used to indicate the entity
   providing the response.

3. OCSPv2

3.1 Protocol Overview

   In lieu of or as a supplement to checking against a periodic CRL, it
   may be necessary to obtain timely information regarding the
   revocation status of a certificate (cf. [RFC3280], Section 3.3).
   Examples include high-value funds transfer or large stock trades.

   The Online Certificate Status Protocol (OCSP) enables applications to
   determine the (revocation) state of an identified certificate. OCSP
   may be used to satisfy some of the operational requirements of
   providing more timely revocation information than is possible with
   CRLs and may also be used to obtain additional status information. An
   OCSP client issues a status request to an OCSP responder and suspends
   acceptance of the certificate in question until the responder
   provides a response.


Malpani & all                                                   [Page 3]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


   This protocol specifies the data that needs to be exchanged between
   an application checking the status of a certificate and the server
   providing that status.

3.2  Request

   An OCSP request contains the following data:

   -- protocol version
   -- service request
   -- target certificate identifier
   -- optional extensions which MAY be processed by the OCSP Responder

   Upon receipt of a request, an OCSP Responder determines if:

   1. the message is well formed

   2. the responder is configured to provide the requested service and

   3. the request contains the information needed by the responder. If
   any one of the prior conditions are not met, the OCSP responder
   produces an error message; otherwise, it returns a definitive
   response.

3.3  Response

   OCSP responses can be of various types.  An OCSP response consists of
   a response type and the bytes of the actual response. 

   There is one basic type of OCSP response that MUST be supported by 
   all OCSP servers and clients. The rest of this section pertains only 
   to this basic response type.

   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requestor
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA

   A definitive response message is composed of:

   -- version of the response syntax
   -- name of the responder
   -- responses for each of the certificates in a request
   -- optional extensions
   -- signature algorithm OID
   -- signature computed across hash of the response




Malpani & all                                                   [Page 4]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002

   The response for each of the certificates in a request consists of

   -- target certificate identifier
   -- certificate status value
   -- response validity interval
   -- optional extensions

   This specification defines the following definitive response
   indicators for use in the certificate status value:

   -- good
   -- revoked
   -- unknown

   The "good" state indicates that the certificate has not been
   revoked. It does not indicate that the certificate was ever issued,
   or is in its validity interval.

   The "revoked" state indicates that the certificate has been revoked
   (either permanently or temporarily (on hold)).

   The "unknown" state indicates that the responder does not know, or
   is unwilling to tell, the requestor the status of the certificate. A
   client may be able to get a definitive response later, or at another
   responder.

   Response extensions may be used to convey additional information on
   assertions made by the responder regarding the status of the
   certificate such as positive statement about issuance, expiry, etc.

3.4  Exception Cases

   In case of errors, the OCSP Responder may return an error message.
   These messages are not signed. 

Errors can be of the following types:

   -- malformedRequest
   -- internalError
   -- tryLater
   -- sigRequired
   -- unauthorized

   A server produces the "malformedRequest" response if the request
   received does not conform to the OCSP syntax.

   The response "internalError" indicates that the OCSP responder
   reached an inconsistent internal state. The query should be retried,
   potentially with another responder.

   In the event that the OCSP responder is operational, but unable to
   return a status for the requested certificate, the "tryLater"
   response can be used to indicate that the service exists, but is
   temporarily unable to respond.

Malpani & all                                                   [Page 5]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


   The response "sigRequired" is returned in cases where the server
   requires the client sign the request in order to construct a
   response.

   The response "unauthorized" is returned in cases where the client is