rfc2560.txt

PKIX的RFC英文文档

   Ambarish Malpani
   ValiCert, Inc.
   1215 Terra Bella Ave.
   Mountain View, CA 94043

   Phone: [phone]
   EMail: [e-mail]


   Slava Galperin
   My CFO, Inc.
   1945 Charleston Road
   Mountain View, CA

   EMail: [e-mail]


   Carlisle Adams
   Entrust Technologies
   750 Heron Road, Suite E08
   Ottawa, Ontario
   K1V 1A7
   Canada

   EMail: [e-mail]








Myers, et al.               Standards Track                    [Page 16]

RFC 2560                       PKIX OCSP                       June 1999


Appendix A.

A.1 OCSP over HTTP

   This section describes the formatting that will be done to the
   request and response to support HTTP.

A.1.1 Request

   HTTP based OCSP requests can use either the GET or the POST method to
   submit their requests. To enable HTTP caching, small requests (that
   after encoding are less than 255 bytes), MAY be submitted using GET.
   If HTTP caching is not important, or the request is greater than 255
   bytes, the request SHOULD be submitted using POST.  Where privacy is
   a requirement, OCSP transactions exchanged using HTTP MAY be
   protected using either TLS/SSL or some other lower layer protocol.

   An OCSP request using the GET method is constructed as follows:

   GET {url}/{url-encoding of base-64 encoding of the DER encoding of
   the OCSPRequest}

   where {url} may be derived from the value of AuthorityInfoAccess or
   other local configuration of the OCSP client.

   An OCSP request using the POST method is constructed as follows: The
   Content-Type header has the value "application/ocsp-request" while
   the body of the message is the binary value of the DER encoding of
   the OCSPRequest.

A.1.2 Response

   An HTTP-based OCSP response is composed of the appropriate HTTP
   headers, followed by the binary value of the DER encoding of the
   OCSPResponse. The Content-Type header has the value
   "application/ocsp-response". The Content-Length header SHOULD specify
   the length of the response. Other HTTP headers MAY be present and MAY
   be ignored if not understood by the requestor.













Myers, et al.               Standards Track                    [Page 17]

RFC 2560                       PKIX OCSP                       June 1999


Appendix B.  OCSP in ASN.1

OCSP DEFINITIONS EXPLICIT TAGS::=

BEGIN

IMPORTS

      -- Directory Authentication Framework (X.509)
             Certificate, AlgorithmIdentifier, CRLReason
             FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                      module(1) authenticationFramework(7) 3 }


-- PKIX Certificate Extensions
             AuthorityInfoAccessSyntax
          FROM PKIX1Implicit88 {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                  id-mod(0) id-pkix1-implicit-88(2)}


          Name, GeneralName, CertificateSerialNumber, Extensions,
           id-kp, id-ad-ocsp
             FROM PKIX1Explicit88 {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                  id-mod(0) id-pkix1-explicit-88(1)};

OCSPRequest     ::=     SEQUENCE {
    tbsRequest                  TBSRequest,
    optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

TBSRequest      ::=     SEQUENCE {
    version             [0] EXPLICIT Version DEFAULT v1,
    requestorName       [1] EXPLICIT GeneralName OPTIONAL,
    requestList             SEQUENCE OF Request,
    requestExtensions   [2] EXPLICIT Extensions OPTIONAL }

Signature       ::=     SEQUENCE {
    signatureAlgorithm   AlgorithmIdentifier,
    signature            BIT STRING,
    certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

Version  ::=  INTEGER  {  v1(0) }

Request ::=     SEQUENCE {
    reqCert                    CertID,
    singleRequestExtensions    [0] EXPLICIT Extensions OPTIONAL }




Myers, et al.               Standards Track                    [Page 18]

RFC 2560                       PKIX OCSP                       June 1999


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

OCSPResponse ::= SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::= ENUMERATED {
    successful            (0),      --Response has valid confirmations
    malformedRequest      (1),      --Illegal confirmation request
    internalError         (2),      --Internal error in issuer
    tryLater              (3),      --Try again later
                                    --(4) is not used
    sigRequired           (5),      --Must sign the request
    unauthorized          (6)       --Request unauthorized
}

ResponseBytes ::=       SEQUENCE {
    responseType   OBJECT IDENTIFIER,
    response       OCTET STRING }

BasicOCSPResponse       ::= SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

ResponseData ::= SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   responderID              ResponderID,
   producedAt               GeneralizedTime,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::= CHOICE {
   byName   [1] Name,
   byKey    [2] KeyHash }

KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key
                         --(excluding the tag and length fields)

SingleResponse ::= SEQUENCE {
   certID                       CertID,
   certStatus                   CertStatus,
   thisUpdate                   GeneralizedTime,



Myers, et al.               Standards Track                    [Page 19]

RFC 2560                       PKIX OCSP                       June 1999


   nextUpdate           [0]     EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions     [1]     EXPLICIT Extensions OPTIONAL }

CertStatus ::= CHOICE {
    good                [0]     IMPLICIT NULL,
    revoked             [1]     IMPLICIT RevokedInfo,
    unknown             [2]     IMPLICIT UnknownInfo }

RevokedInfo ::= SEQUENCE {
    revocationTime              GeneralizedTime,
    revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

UnknownInfo ::= NULL -- this can be replaced with an enumeration

ArchiveCutoff ::= GeneralizedTime

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

ServiceLocator ::= SEQUENCE {
    issuer    Name,
    locator   AuthorityInfoAccessSyntax }

-- Object Identifiers

id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp                 OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic           OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce           OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl             OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response        OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck         OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }


END















Myers, et al.               Standards Track                    [Page 20]

RFC 2560                       PKIX OCSP                       June 1999


Appendix C. MIME registrations

C.1 application/ocsp-request

   To: [e-mail]
   Subject: Registration of MIME media type application/ocsp-request

   MIME media type name: application

   MIME subtype name: ocsp-request

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries a  request for information. This
   request may optionally be cryptographically signed.

   Interoperability considerations: None

   Published specification: IETF PKIX Working Group Draft on Online
   Certificate Status Protocol - OCSP

   Applications which use this media type: OCSP clients

   Additional information:

      Magic number(s): None
      File extension(s): .ORQ
      Macintosh File Type Code(s): none

   Person & email address to contact for further information:
   Ambarish Malpani <[e-mail]>

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <[e-mail]>

C.2 application/ocsp-response

   To: [e-mail]
   Subject: Registration of MIME media type application/ocsp-response

   MIME media type name: application




Myers, et al.               Standards Track                    [Page 21]

RFC 2560                       PKIX OCSP                       June 1999


   MIME subtype name: ocsp-response

   Required parameters: None

   Optional parameters: None
   Encoding considerations: binary

   Security considerations: Carries a cryptographically signed response

   Interoperability considerations: None

   Published specification: IETF PKIX Working Group Draft on Online
   Certificate Status Protocol - OCSP

   Applications which use this media type: OCSP servers

   Additional information:

   Magic number(s): None
   File extension(s): .ORS
   Macintosh File Type Code(s): none

   Person & email address to contact for further information:
   Ambarish Malpani <[e-mail]>

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <[e-mail]>






















Myers, et al.               Standards Track                    [Page 22]

RFC 2560                       PKIX OCSP                       June 1999


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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Myers, et al.               Standards Track                    [Page 23]