[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

PKIX Working Group                           Ambarish Malpani(ValiCert)
draft-malpani-rcsp-00.txt         Carlisle Adams (Entrust Technologies)
Expires in 6 months                                Rich Ankney (CertCo)
                                              Slava Galperin (Netscape)
                                                            March, 1998


                  Internet Public Key Infrastructure
             Real Time Certificate Status Protocol - RCSP
                     <draft-malpani-rcsp-00.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),  ftp.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 RCSP 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 Real Time Certificate Status Protocol (RCSP) enables applications
to determine the revocation state of an identified certificate. RCSP
may be used to satisfy some of the operational requirements of
providing more timely revocation information than is possible with
CRLs.  An RCSP client issues a status request to an RCSP responder and
suspends acceptance of the certificate in question 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 RCSP 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 RCSP responder

Upon receipt of a request, an RCSP 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 RCSP 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 MUST belong to one of
the following:

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

A definitive response message is composed of:

- response type identifier (to allow for different response types)
- version of the response
- name of the responder
- responses for each of the certificates in a request
- optional extensions
- signature algorithm OID
- signature computed across the hash of the response

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:

- 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 RCSP responder DOES NOT absolve the application
of the responsibility of checking that the certificate is in its
validity period and has been correctly signed.

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 RCSP 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 RCSP 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 RCSP responder reached
an 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 RCSP 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 {producedAt, nextUpdate} pair of elements in the response syntax.
Section 4.2 provides details of the response syntax.

RCSP responders MAY pre-produce signed responses specifying the
current status of certificates at the time the response was
produced. The time at which the response was known to be correct SHALL
be specified in the producedAt field of the response. This time is not
necessarily the same as the time at which the response was produced -
e.g. if the responder obtains a CRL from a CA and creates pre-produced
responses, the producedAt time should specify the thisUpdate time in
the CRL.

The producer of the response MAY include a value for nextUpdate. The
exact interval between producedAt and nextUpdate for a given response
is a matter of local security and operational policy. If the
nextUpdate field is not present, the response is known to be correct
at the producedAt time. No assertions are being made about the current
state of the certificate, nor are any recommendations being made as to
when the requestor should check again with the responder.  If the
value of nextUpdate is set, it is just a hint, not a guarantee, of
when the responder expects to have new information about that
certificate's status.

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.

2.4 Delegation of the task of RCSP responses to an Authorized Responder

One or more CAs may decide to delegate the task of producing RCSP
response to a third party (an Authorized Responder). In that case,
each of those CAs should provide the Authorized Responder with a
certificate
that includes a special extension authorizing the holder to issue RCSP
responses.


3. Functional Requirements

3.1 Certificate Content

In order to convey to RCSP 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 that can be checked using RCSP.

CAs that support an RCSP service, either hosted locally or provided by
an Authorized Responder, MAY provide a value for a
uniformResourceIndicator (URI) accessLocation and the OID value
id-ad-rcsp for the accessMethod in the AccessDescription SEQUENCE.
The value of the accessLocation field in the subject certificate
corresponds to the URL placed into an RCSP request. Alternatively, the
accessLocation for the RCSP provider may be configured locally at the
RCSP client (e.g., in cases where the RCSP provider is a trusted party
for the particular client, whose job is to aggregate revocation
information from all trusted CAs).

id-ad-rcsp OBJECT IDENTIFIER ::= {id-ad ?}

3.2 Error Responses

Upon receipt of a request which fails to parse, the receiving RCSP
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, RCSP clients SHALL
confirm that:

- The certificate identified in a received response corresponds to
that which was identified in the corresponding 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.690].

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

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

Request                 ::=     CHOICE {
        certID                  [0]     EXPLICIT CertID,
        cert                    [1]     EXPLICIT Certificate
}

CertID                  ::=     SEQUENCE {
        issuerNameAndKeyHash            Hash,
        serialNumber                    CertificateSerialNumber,
}

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

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

4.2 Notes on the RCSP Request Syntax

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 hashAlgorithm in the request.
The primary reason to use both the name and the public key to identify
the issuer is that 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.

While it is possible to identify a certificate by sending over either
the entire certificate or just a CertID, it is recommended that
clients use just the CertID to reduce the size of both the request
and the response.  However, certain RCSP responders MAY require the
entire certificate whose status is to be determined.

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.5. 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 RCSP Response

RCSPResponse            ::=     SEQUENCE {
        responseStatus                  RCSPResponseStatus,
        responseBytes           [0]     EXPLICIT ResponseBytes OPTIONAL
}

RCSPResponseStatus      ::=     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--
        tryLater                ( 4 )   --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 RCSP responder, responseType will be id-pkix-rcsp-basic,
where:
id-pkix-rcsp OBJECT IDENTIFIER ::= { id-pkix ? }
id-pkix-rcsp-basic OBJECT IDENTIFIER ::= { id-pkix-rcsp ? }

The response will be the DER encoding of BasicRCSPResponse

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

ResponseData            ::=     SEQUENCE {
        version                 [0]     EXPLICIT Version DEFAULT v1,
        responderName                   Name,
        responses                       SEQUENCE OF SingleResponse,
        responseExtensions      [1]     EXPLICIT Extensions OPTIONAL
}

SingleResponse          ::=     SEQUENCE {
        request                         Request,
        certStatus                      CertStatus,
        producedAt                      GeneralizedTime,
        nextUpdate              [0]     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--
}

4.2.2 Notes on RCSP Responses

If the certStatusType is revoked, time is the time of revocation of
the certificate.


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

The signature should be computed on the hash of the DER encoding of
the ResponseData.

4.3 Authorized Responders

One or more CAs may designate an Authorized RCSP Responder, by issuing
a special certificate. The Authorized Responder will have the right to
issue RCSP responses on behalf of that CA as long as that certificate
does not expire. The certificates for Authorized Responders SHALL
contain a non-critical extension, proving the authorization. The
extension identifier will be id-kp-rcsp, while the value will be the
DER encoding of the integer 1.  The certificate of an Authorized RCSP
Responder cannot be revoked. It is recommended that the life of this
certificate be kept short and every effort be made to protect its
private key atleast as carefully as that of the CA.

id-kp-rcsp OBJECT IDENTIFIER ::= {id-kp ?}

4.4 Mandatory and Optional Cryptographic Algorithms

Clients that request RCSP 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. RCSP responders SHALL support the SHA1 hash algorithm.

4.5 Extensions

This section defines the way to support some commonly requested
tasks. Support for all extensions is OPTIONAL, so critical
SHOULD NOT be set for any of these extensions.

4.5.1 Nonce

The nonce cryptographically binds a request and a response to prevent
replay attacks. The nonce is included as one of the requestExtensions
in requests, while in responses 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-rcsp-nonce, while
the extnValue is the value of the nonce.

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

4.5.2 Signed Requests

This extension allows the requestor to sign a request. The
requestor includes an extension that has the signatureIdentifier, the
actual bits of the signature and a sequence of certificates to allow
the RCSP responder to verify the signature. The data to be
signed is just the basic request (none of the extensions). The RCSP
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-rcsp-signature, while the value will
be SignatureData, where:

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


4.5.3 CRL References

It MAY be desirable for the RCSP responder to indicate the CRL on which
a revoked or onHold certificate is found. This can be useful where RCSP
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-rcsp-crl, while the
value
will be CrlID.

id-pkix-rcsp-crl OBJECT IDENTIFIER ::= { id-pkix-rcsp ? }
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.5.4 Acceptable Response Types

An RCSP client MAY wish to specify the kinds of response types it
understands. To do so, it SHOULD use an extension with the OID
id-pkix-rcsp-response, and the value AcceptableResponses. The id's
included in AcceptableResponses are the OIDs of the various response
types this client can accept (e.g., id-pkix-rcsp-basic).

id-pkix-rcsp-response OBJECT IDENTIFIER ::= {id-pkix-rcsp ?}
AcceptableResponses     ::=     SEQUENCE OF {
        id                              OBJECT IDENTIFIER
}

4.5.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 RCSP responses,
compromise of that key is as serious as the compromise of the CA's key
as long as the authorization is valid. An authorized RCSP responder's
key cannot be revoked.

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 can be produced more rapidly and thus reduce the danger of
this
attack. However, unsigned error responses open up the protocol to
another denial of service attack, where the attacker sends false error
responses.

The use of precomputed responses allows replay attacks in which an old
(notRevoked) response is replayed prior to its expiration but after
the certificate has been revoked. To reduce this vulnerability, it is
recommended that the period between producedAt and nextUpdate be
kept as small as possible.

6. Acknowledgements

    This protocol uses many ideas from the Online Certificate Status
Protocol (OCSP), developed by Mike Meyers (VeriSign) and Rich Ankney
(CertCo). We have also used comments from Marc Branchaud (XCert),
Robert Zuccherato (Entrust) and Anil Gangolli (Structured Arts).

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

8. Author's Address

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

Carlisle Adams
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario
K1V 1A7
Canada
cadams@entrust.com

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

Slava Galperin
Netscape Communications Corp.
MV-068
501 E. Middlefield Rd.
Mountain View, CA 94043
galperin@netscape.com

Appendix A

A.1 RCSP over HTTP

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

A.1.1 Request

An RCSP request is an HTTP 1.0 POST method. The Content-Type header
has the value "application/rcsp-request" while the body of the message
is the DER encoding of the RCSPRequest.

A.1.2 Response

An HTTP-based RCSP response is composed of the appropriate HTTP headers,
followed by the DER encoding of the RCSPResponse. The Content-Type
header has the value "application/rcsp-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.

Expires September, 1998


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/