[IETF-PKIX] OCSP in ASN.1

[Ambarish Malpani <ambarish@xxxxxxxxxxxx>]

Hi Mike,

Given the number of people requesting (1) OCSP provide better support
for ASN.1 (2) OCSP not be necessarily tied to HTTP (but be able to
benefit from HTTP),  I have taken the liberty making some fairly major
changes to the OCSP spec and would like to offer it up as a basis for
moving forward.

 I believe this re-write has technical merit on the following grounds:

(1) It separates OCSP from HTTP but at the same time the protocol can
be implemented using HTTP (both GET and POST).
(2) It is easier to implement (a new ABNF parser is not required --
uses standard ASN.1)
(3) It is more extensible and more consistent with existing crypto
applications (by virtue of using ASN.1).
(4) It allows multiple cryptographic algorithms in the response (RSA
signatures, Diffie Hellman signatures, revocation tree based responses,
iterated hashing based responses etc.)

There are some other minor changes which I think are important but
details (a) certificate status uses notRevoked instead of valid (since
this protocol just checks revocation status - not validity for
a particular task)
(b) usage of both SHA and MD5 is changed to just a hashing algorithm
(preferrably SHA)
(c) certs are identified by both issuer DN and issuer public key
(explanation in the text) and the serial number.
(d) post is a default method
(e) multiple certificates can be supported in a single request.

Eager to receive your feedback (and also others on the net).

Regards,
Ambarish


--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  ambarish@valicert.com
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303
PKIX Working Group                                Mike Myers (VeriSign)
draft-ietf-pkix-ocsp-03.txt                        Rich Ankney (CertCo)
Expires in 6 months                          Ambarish Malpani(ValiCert)
                                              Slava Galperin (Netscape)
                                                             March 1998


                  Internet Public Key Infrastructure
              Online Certificate Status Protocol - OCSP
                    <draft-ietf-pkix-ocsp-03.txt>



Status of this Memo

This document is an Internet-Draft. 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."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories  on  ftp.is.co.za  (Africa),  nic.nordu.net  (Europe),
munnari.oz.au  (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

1. Abstract

The protocol conventions described in this document satisfy some of
the operational requirements of the Internet Public Key Infrastructure
(PKI). This document specifies a protocol useful in determining the
current status of a digital certificate without the use of CRLs.
Additional mechanisms addressing PKIX operational requirements are
specified in separate documents.

Section 2 provides an overview of the protocol. Section 3 goes through
the functional requirements, while section 4 provides the details of
the protocol. In section 5 we cover security issues with the
protocol. Appendix A demonstrates OCSP over HTTP.

Please send comments on this document to the ietf-pkix@tandem.com mail
list.

2. Protocol Overview

In lieu of or as a supplement to checking against a periodic CRL, it MAY
be necessary to obtain timely status regarding a certificate's
revocation status (cf. PKIX Part 1, Section 3.3). Examples include high-
value fund transfers or the compromise of a highly sensitive key.

The Online Certificate Status Protocol (OCSP) enables applications to
determine the validity and revocation state of an identified
certificate. An OCSP client issues a status request to an OCSP
responder and suspends acceptance of the subject certificate until the
responder provides a response.

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

2.1 Request

An OCSP request contains the following data:

- protocol version
- service request
- target identifier for one or more certificates to be checked
- 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 responder can perform the requested
service for the certificate in question. If any of the prior
conditions are not met, the OCSP responder produces an error message;
otherwise, it returns a definitive response.

2.2 Response

All definitive responses SHALL be digitally signed. The key
used to sign definitive responses need not be the same key
used to sign the certificate. The key used to sign the response can
belong to one of the following:

- a Trusted Responder, whose key is already embedded in the application
- the CA who issued the certificate in question
- an Authorized Responder, with a certificate which has a special extension
authorizing it to sign OCSP responses

A definitive response message is composed of:

- response type identifier (to allow for different response types)
- response validity interval
- target certificate identifier
- certificate status value
- identification of public key needed to validate the signature
- signature algorithm OID
- optional extensions
- signature computed across hash of previous six values

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

- notRevoked
- revoked
- onHold

The notRevoked state indicates that the certificate is not revoked. It
does not necessarily mean that the certificate was ever issued. Nor
does it mean that the certificate is in its validity interval. A
notRevoked state by an OCSP responder DOES NOT absolve the application
checking the certificate from checking its validity period and
signature.

The revoked state indicates that the certificate has been revoked.

The onHold state corresponds to valid certificates that are
operationally suspended in accordance with PKIX Part 1.

In case of errors, the OCSP Responder may return an error message. Errors
can be of the following types:

- malformedRequest
- requestorUnauthorized
- internalError
- tryLater

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

The response requestorUnauthorized is used in cases where the server
does not consider the client authorized to query it. Authorization
data is not explicitly a part of the request or this protocol.
However, certain responders may choose to require clients to ship an
authorization token with the request and may choose to refuse service
to clients that do not ship a correct authorization token.

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

The response tryLater is produced in any circumstance in which the
server has received a well formed OCSP request but is unable to process
it.

2.3 Response Pre-production

The response validity interval noted in the prior section is composed of
a {produced-at, valid-until} pair of elements in the response syntax.
Section 4.2 provides details of the response syntax.

OCSP responders MAY pre-produce signed responses reflecting the current
status of certificates at the time the response was produced. The time
at which the response was produced SHALL be reflected in the produced-at
field of the response.

The producer of the response MAY include a value for valid-until. The
exact interval between produced-at and valid-until for a given
response is a matter of local security and operational policy. If the
valid-until field is not present, the response was known to be correct
at the produced-at time. No assertions are being made about the
current state of the certificate.

If responses are pre-produced, then for a given certificate, the
periodicity of this pre-production SHOULD match the response validity
interval of the most recently produced response.


3. Functional Requirements

3.1 Certificate Content

In order to convey to OCSP clients a well-known point of information
access, CAs SHALL provide the capability to include the
AuthorityInfoAccess extension (defined in PKIX Part 1, section
4.2.2.1) in certificates intended to be applied to the service.

CAs that support an OCSP service, either hosted locally or provided by a
Trusted Third Party, SHALL provide a value for a
uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp
for the accessMethod in the AccessDescription SEQUENCE.

The value of the accessLocation field in the subject certificate
corresponds to the URL placed into an OCSP request.

3.2 Error Responses

Upon receipt of a request which fails to parse, the receiving OCSP
responder SHALL respond with an error message. Error responses MAY be
signed.

3.3 Signed Response Acceptance Requirements

Prior to accepting a signed response as valid, OCSP clients SHALL
confirm that:

- The certificate identified in a received response corresponds to
that which was identified in a former request.
- The signature on the response is valid.
- The identity of the signer matches the intended recipient of the
request.
- The signer is currently authorized to sign the response.


4. Detailed Protocol

The ASN.1 syntax imports terms defined in the X.509 Certificate and CRL
Profile Internet Draft. For signature calculation, the data to be signed is
encoded using the ASN.1 distinguished encoding rules (DER) [X.208].

ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.

The terms imported from elsewhere are:
Version, Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name,
AlgorithmIdentifier, GeneralizedTime

4.1 Request Syntax

OCSPRequest     ::=     SEQUENCE {
        version                 [0]     EXPLICIT Version DEFAULT v1,
        hash                            AlgorithmIdentifier,
        requestList                     SEQUENCE OF Request,
        requestExtensions       [1]     EXPLICIT Extensions OPTIONAL
}

Request                 ::=     SEQUENCE {
        issuerNameAndKeyHash            Hash,
        serialNumber                    CertificateSerialNumber,
        cert                    [0]     EXPLICIT Certificate OPTIONAL
}

IssuerNameAndKey                ::=     SEQUENCE {
        issuer                          Name,
        issuerPublicKey                 SubjectPublicKeyInfo
}

Hash                    ::=     OCTET STRING --hash of IssuerNameAndKey--

The issuerNameAndKeyHash is computed by hashing an IssuerNameAndKey
field constructed for the CA in question using a cryptographic hash
function (e.g., SHA-1) specified as the hash algorithm in the request.
There are two reasons to use both the name and the public key to identify the
issuer.

- The Name may be NULL.
- It is possible that two CAs may choose to use the same Name
(uniqueness in the Name is a recommendation that cannot be enforced).
Two CAs will never, however, have the same public key unless the CAs
either explicitly decided to share their private key, or the key of
one of the CAs was compromised).

Support for extensions is OPTIONAL. The critical flag SHOULD NOT be
set for any of them. This standard suggests several useful extensions
in Section 4.4. Additional extensions MAY be defined in additional
RFCs. Unrecognized extensions SHOULD be ignored.


4.2 Response Syntax

This section specifies the ASN.1 specification for a confirmation
response. The actual formatting of the message could vary depending on
the transport mechanism used (http, smtp, ldap, etc.).

4.2.1 ASN.1 Specification of the OCSP Response

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

OCSPResponseStatus      ::=     ENUMERATED {
        successful              ( 0 ),  --Response has valid confirmations--
        malformedRequest        ( 1 ),  --Illegal confirmation request--
        requestorUnauthorized   ( 2 ),  --User not authorized to use issuer--
        internalError           ( 3 ),  --Internal error in issuer--
        unsupportedRequest      ( 4 ),  --Server can't support the request--
        tryLater                ( 5 )   --Try again later--
}

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

If the responseStatus is one of the error conditions, responseBytes
are not set.

For a basic OCSP responder, responseType will be id-pkix-ocsp-basic, where:
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-pkix ? }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }

The response will be the DER encoding of BasicOCSPResponse

BasicOCSPResponse       ::=     SEQUENCE {
        version                 [0]     EXPLICIT Version DEFAULT v1,
        signatureAlgorithm              AlgorithmIdentifier,
        responseData                    ResponseData,
        signature                       BIT STRING
}

ResponseData            ::=     SEQUENCE {
        responses                       SEQUENCE OF SingleResponse,
        responseExtensions      [0]     EXPLICIT Extensions OPTIONAL
}

SingleResponse          ::=     SEQUENCE {
        request                         Request,
        certStatus                      CertStatus,
        producedAt                      GeneralizedTime,
        validUntil              [0]     EXPLICIT GeneralizedTime OPTIONAL,
        eventTime               [1]     EXPLICIT GeneralizedTime OPTIONAL,
        singleExtensions        [2]     EXPLICIT Extensions OPTIONAL
}

CertStatus              ::=     CHOICE {
        certStatusType          [0]    EXPLICIT CertStatusType
                                        (notRevoked | onHold),
        statusWithTime          [1]    EXPLICIT StatusWithTime
}

StatusWithTime          ::=     SEQUENCE {
        certStatusType                  CertStatusType (revoked),
        time                            GeneralizedTime
}


CertStatusType          ::=     ENUMERATED {
        notRevoked              (0),    --This serial number is not revoked--
        revoked                 (1),    --Serial number was revoked--
        onHold                  (2),    --Cert is on hold--
}

The semantics of time in StatusWithTime are:
- for revoked, time is the time of revocation

The producedAt and validUntil fields define a validity interval. This
interval corresponds to the {thisUpdate, nextUpdate} CRL validity
interval. Responses whose validUntil value is earlier than the local
system time value SHOULD be considered unreliable. Responses where the
validUntil value is not set are equivalant to a CRL with no time for
nextUpdate.

4.3 Mandatory and Optional Cryptographic Algorithms

Clients that request OCSP services SHALL be capable of processing
responses signed used DSA keys identified by the DSA sig-alg-oid
specified in section 7.2.2 of PKIX Part 1. Clients SHOULD also be
capable of processing RSA signatures as specified in section 7.2.1 of
PKIX Part 1. OCSP responders SHALL support the SHA1 hash algorithm.

4.4 Extensions

This section defines the way to support some commonly requested
tasks. Support for all extensions is OPTIONAL.

4.4.1 Nonce

The nonce cryptographically binds a request and response, to prevent
replay attacks. The nonce is included as one of the requestExtensions,
in requests, while in response it would be included as one of the
responseExtensions.  In both the request and the response, the nonce
will be identified by the object identifier id-pkix-ocsp-nonce, while
the extnValue is the value of the nonce.

id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }

4.4.2 Signed Requests

This extension allows the requestor to sign the request. The
requestor includes an extension that has the signatureIdentifier, the
actual bits of the signature and a sequence of certificates to allow
the OCSP responder to verify the signature. The data to be
signed is just the basic request (none of the extensions). The OCSP
Responder can verify the signature, potentially using certificates
that have been included with the extension. The signature on a request
will be identified by id-pkix-ocsp-signature, while the value will
be SignatureData, where:

id-pkix-ocsp-signature OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }
SignatureData           ::=     SEQUENCE {
        signatureAlgorithm      AlgorithmIdentifier,
        signature               BIT STRING,
        certs           [0]     EXPLICIT SEQUENCE OF Certificate OPTIONAL
}


4.4.3 CRL References

It MAY be desirable for the OCSP responder to indicate the CRL on which
a revoked or held certificate is found. This can be useful where OCSP
is used between repositories, and also as an auditing mechanism. The
CRL may be specified by a URL (the URL at which the CRL is available),
a number (CRL number) or a time (the time at which the relevant CRL
was created). These extensions will be specified as singleExtensions.
The identifier for this extension will be id-pkix-ocsp-crl, while the value
will be CrlID.

id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }
CrlID           ::=     SEQUENCE {
        crlUrl          [0]     EXPLICIT IA5String OPTIONAL,
        crlNum          [1]     EXPLICIT INTEGER OPTIONAL,
        crlTime         [2]     EXPLICIT GeneralizedTime OPTIONAL
}

For the choice crlUrl, the IA5String will specify the URL at which the
CRL is available. For crlNum, the INTEGER will specify the value of the CRL
number extension of the relevant CRL. For crlTime, the GeneralizedTime
will indicate the time at which the relevant CRL was issued.

4.4.4 Other Extensions

CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are also
supported as singleExtensions.

5. Security Considerations

For this service to be effective, systems using certificates must
connect to the certificate status service provider. In the event such
a connection cannot be obtained, these systems could implement CRL
processing logic as a fall-back position.

If a CA authorizes another public key to sign OCSP responses,
compromise of that key is as serious as the compromise of the CA's key
as long as the authorization is valid.

A denial of service vulnerability is evident with respect to a flood
of queries constructed to produce error responses. The production of a
cryptographic signature significantly affects response generation
cycle time, thereby exacerbating the situation. Unsigned error
responses provide a reasonable tradeoff against this particular
attack.

Unsigned error responses open up the protocol to a denial of
service attack, where the attacker sends false error responses.

The use of precomputed responses may allow replay attacks in which
an old (notRevoked) response is replayed prior to its expiration but after
the certificate has been revoked.

This data is information which may conceivably be used to enforce
legal contracts, resolve disputes or transfer financial risk from one
party to another. The design of software that processes this type
should be trustworthy in its design and operations.

6. References

[HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee,
       R. Fielding & H. Frystyk, RFC 1945, May 1996.

[MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels,
 S. Bradner, RFC 2119, March 1997.

[URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter,
M.  McCahill, RFC 1738, December 1994.

7. Author's Address

Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA 94019
mmyers@verisign.com

Rich Ankney
CertCo, LLC
13506 King Charles Dr.
Chantilly, VA  20151
rankney@erols.com

Ambarish Malpani
ValiCert, Inc.
3160 W. Bayshore Drive
Palo Alto, CA 94303
ambarish@valicert.com

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

An OCSP request is an HTTP 1.0 POST method. The Content-Type header
has the value "application/ocsp-request", while the body of the
message is 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 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.

Published specification: This document.