diff options
Diffstat (limited to 'doc/rfc/rfc2560.txt')
| -rw-r--r-- | doc/rfc/rfc2560.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc2560.txt b/doc/rfc/rfc2560.txt new file mode 100644 index 0000000..6bb55b6 --- /dev/null +++ b/doc/rfc/rfc2560.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group M. Myers +Request for Comments: 2560 VeriSign +Category: Standards Track R. Ankney + CertCo + A. Malpani + ValiCert + S. Galperin + My CFO + C. Adams + Entrust Technologies + June 1999 + + + X.509 Internet Public Key Infrastructure + Online Certificate Status Protocol - OCSP + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +1. Abstract + + This document specifies 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. + + An overview of the protocol is provided in section 2. Functional + requirements are specified in section 4. Details of the protocol are + in section 5. We cover security issues with the protocol in section + 6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1 + syntactic elements and appendix C specifies the mime types for the + messages. + + 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]. + + + + + +Myers, et al. Standards Track [Page 1] + +RFC 2560 PKIX OCSP June 1999 + + +2. 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. [RFC2459], 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. + + 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. + +2.1 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. + +2.2 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. + + + + +Myers, et al. Standards Track [Page 2] + +RFC 2560 PKIX OCSP June 1999 + + + 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 requester + -- 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 + + 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 a positive response to the status inquiry. + At a minimum, this positive response indicates that the certificate + is not revoked, but does not necessarily mean that the certificate + was ever issued or that the time at which the response was produced + is within the certificate's validity interval. 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, validity, etc. + + The "revoked" state indicates that the certificate has been revoked + (either permanantly or temporarily (on hold)). + + The "unknown" state indicates that the responder doesn't know about + the certificate being requested. + + + + + +Myers, et al. Standards Track [Page 3] + +RFC 2560 PKIX OCSP June 1999 + + +2.3 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. + + 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 + not authorized to make this query to this server. + +2.4 Semantics of thisUpdate, nextUpdate and producedAt + + Responses can contain three times in them - thisUpdate, nextUpdate + and producedAt. The semantics of these fields are: + + - thisUpdate: The time at which the status being indicated is known + to be correct + - nextUpdate: The time at or before which newer information will be + available about the status of the certificate + - producedAt: The time at which the OCSP responder signed this + response. + + If nextUpdate is not set, the responder is indicating that newer + revocation information is available all the time. + + + + + + + +Myers, et al. Standards Track [Page 4] + +RFC 2560 PKIX OCSP June 1999 + + +2.5 Response Pre-production + + OCSP responders MAY pre-produce signed responses specifying the + status of certificates at a specified time. The time at which the + status was known to be correct SHALL be reflected in the thisUpdate + field of the response. The time at or before which newer information + will be available is reflected in the nextUpdate field, while the + time at which the response was produced will appear in the producedAt + field of the response. + +2.6 OCSP Signature Authority Delegation + + The key that signs a certificate's status information need not be the + same key that signed the certificate. A certificate's issuer + explicitly delegates OCSP signing authority by issuing a certificate + containing a unique value for extendedKeyUsage in the OCSP signer's + certificate. This certificate MUST be issued directly to the + responder by the cognizant CA. + +2.7 CA Key Compromise + + If an OCSP responder knows that a particular CA's private key has + been compromised, it MAY return the revoked state for all + certificates issued by that CA. + +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 [RFC2459], section 4.2.2.1) + in certificates that can be checked using OCSP. Alternatively, the + accessLocation for the OCSP provider may be configured locally at the + OCSP client. + + CAs that support an OCSP service, either hosted locally or provided + by an Authorized Responder, MUST provide for the inclusion of 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 + defines the transport (e.g. HTTP) used to access the OCSP responder + and may contain other transport dependent information (e.g. a URL). + + + + + + + +Myers, et al. Standards Track [Page 5] + +RFC 2560 PKIX OCSP June 1999 + + +3.2 Signed Response Acceptance Requirements + + Prior to accepting a signed response as valid, OCSP clients SHALL + confirm that: + + 1. The certificate identified in a received response corresponds to + that which was identified in the corresponding request; + + 2. The signature on the response is valid; + + 3. The identity of the signer matches the intended recipient of the + request. + + 4. The signer is currently authorized to sign the response. + + 5. The time at which the status being indicated is known to be + correct (thisUpdate) is sufficiently recent. + + 6. When available, the time at or before which newer information will + be available about the status of the certificate (nextUpdate) is + greater than the current time. + +4. Detailed Protocol + + The ASN.1 syntax imports terms defined in [RFC2459]. 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: Extensions, + CertificateSerialNumber, SubjectPublicKeyInfo, Name, + AlgorithmIdentifier, CRLReason + +4.1 Requests + + This section specifies the ASN.1 specification for a confirmation + request. The actual formatting of the message could vary depending on + the transport mechanism used (HTTP, SMTP, LDAP, etc.). + +4.1.1 Request Syntax + + OCSPRequest ::= SEQUENCE { + tbsRequest TBSRequest, + optionalSignature [0] EXPLICIT Signature OPTIONAL } + + TBSRequest ::= SEQUENCE { + + + +Myers, et al. Standards Track [Page 6] + +RFC 2560 PKIX OCSP June 1999 + + + 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 } + + CertID ::= SEQUENCE { + hashAlgorithm AlgorithmIdentifier, + issuerNameHash OCTET STRING, -- Hash of Issuer's DN + issuerKeyHash OCTET STRING, -- Hash of Issuers public key + serialNumber CertificateSerialNumber } + + issuerNameHash is the hash of the Issuer's distinguished name. The + hash shall be calculated over the DER encoding of the issuer's name + field in the certificate being checked. issuerKeyHash is the hash of + the Issuer's public key. The hash shall be calculated over the value + (excluding tag and length) of the subject public key field in the + issuer's certificate. The hash algorithm used for both these hashes, + is identified in hashAlgorithm. serialNumber is the serial number of + the certificate for which status is being requested. + +4.1.2 Notes on the Request Syntax + + The primary reason to use the hash of the CA's public key in addition + to the hash of the CA's name, 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. + + Support for any specific extension is OPTIONAL. The critical flag + SHOULD NOT be set for any of them. Section 4.4 suggests several + useful extensions. Additional extensions MAY be defined in + additional RFCs. Unrecognized extensions MUST be ignored (unless they + have the critical flag set and are not understood). + + + + +Myers, et al. Standards Track [Page 7] + +RFC 2560 PKIX OCSP June 1999 + + + The requestor MAY choose to sign the OCSP request. In that case, the + signature is computed over the tbsRequest structure. If the request + is signed, the requestor SHALL specify its name in the requestorName + field. Also, for signed requests, the requestor MAY include + certificates that help the OCSP responder verify the requestor's + signature in the certs field of Signature. + +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 + + An OCSP response at a minimum consists of a responseStatus field + indicating the processing status of the prior request. If the value + of responseStatus is one of the error conditions, responseBytes are + not set. + + 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 + } + + The value for responseBytes consists of an OBJECT IDENTIFIER and a + response syntax identified by that OID encoded as an OCTET STRING. + + ResponseBytes ::= SEQUENCE { + responseType OBJECT IDENTIFIER, + response OCTET STRING } + + For a basic OCSP responder, responseType will be id-pkix-ocsp-basic. + + id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } + id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } + + + + + + +Myers, et al. Standards Track [Page 8] + +RFC 2560 PKIX OCSP June 1999 + + + OCSP responders SHALL be capable of producing responses of the id- + pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be + capable of receiving and processing responses of the id-pkix-ocsp- + basic response type. + + The value for response SHALL be the DER encoding of + BasicOCSPResponse. + + BasicOCSPResponse ::= SEQUENCE { + tbsResponseData ResponseData, + signatureAlgorithm AlgorithmIdentifier, + signature BIT STRING, + certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } + + The value for signature SHALL be computed on the hash of the DER + encoding ResponseData. + + 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, + 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 + + + +Myers, et al. Standards Track [Page 9] + +RFC 2560 PKIX OCSP June 1999 + + +4.2.2 Notes on OCSP Responses + +4.2.2.1 Time + + The thisUpdate 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 thisUpdate time is later than the local system time + SHOULD be considered unreliable. Responses where the nextUpdate value + is not set are equivalent to a CRL with no time for nextUpdate (see + Section 2.4). + + The producedAt time is the time at which this response was signed. + +4.2.2.2 Authorized Responders + + The key that signs a certificate's status information need not be the + same key that signed the certificate. It is necessary however to + ensure that the entity signing this information is authorized to do + so. Therefore, a certificate's issuer MUST either sign the OCSP + responses itself or it MUST explicitly designate this authority to + another entity. OCSP signing delegation SHALL be designated by the + inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate + extension included in the OCSP response signer's certificate. This + certificate MUST be issued directly by the CA that issued the + certificate in question. + + id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} + + Systems or applications that rely on OCSP responses MUST be capable + of detecting and enforcing use of the id-ad-ocspSigning value as + described above. They MAY provide a means of locally configuring one + or more OCSP signing authorities, and specifying the set of CAs for + which each signing authority is trusted. They MUST reject the + response if the certificate required to validate the signature on the + response fails to meet at least one of the following criteria: + + 1. Matches a local configuration of OCSP signing authority for the + certificate in question; or + + 2. Is the certificate of the CA that issued the certificate in + question; or + + 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage + extension and is issued by the CA that issued the certificate in + question." + + + + +Myers, et al. Standards Track [Page 10] + +RFC 2560 PKIX OCSP June 1999 + + + Additional acceptance or rejection criteria may apply to either the + response itself or to the certificate used to validate the signature + on the response. + +4.2.2.2.1 Revocation Checking of an Authorized Responder + + Since an Authorized OCSP responder provides status information for + one or more CAs, OCSP clients need to know how to check that an + authorized responder's certificate has not been revoked. CAs may + choose to deal with this problem in one of three ways: + + - A CA may specify that an OCSP client can trust a responder for the + lifetime of the responder's certificate. The CA does so by including + the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical + extension. The value of the extension should be NULL. CAs issuing + such a certificate should realized that a compromise of the + responder's key, is as serious as the compromise of a CA key used to + sign CRLs, at least for the validity period of this certificate. CA's + may choose to issue this type of certificate with a very short + lifetime and renew it frequently. + + id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } + + - A CA may specify how the responder's certificate be checked for + revocation. This can be done using CRL Distribution Points if the + check should be done using CRLs or CRL Distribution Points, or + Authority Information Access if the check should be done in some + other way. Details for specifying either of these two mechanisms are + available in [RFC2459]. + + - A CA may choose not to specify any method of revocation checking + for the responder's certificate, in which case, it would be up to the + OCSP client's local security policy to decide whether that + certificate should be checked for revocation or not. + +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 [RFC2459]. Clients SHOULD also be + capable of processing RSA signatures as specified in section 7.2.1 of + [RFC2459]. OCSP responders SHALL support the SHA1 hashing algorithm. + +4.4 Extensions + + This section defines some standard extensions, based on the extension + model employed in X.509 version 3 certificates see [RFC2459]. Support + for all extensions is optional for both clients and responders. For + + + +Myers, et al. Standards Track [Page 11] + +RFC 2560 PKIX OCSP June 1999 + + + each extension, the definition indicates its syntax, processing + performed by the OCSP Responder, and any extensions which are + included in the corresponding response. + +4.4.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-ocsp-nonce, while + the extnValue is the value of the nonce. + + id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } + +4.4.2 CRL References + + It may be desirable for the OCSP responder to indicate the CRL on + which a revoked or onHold 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 3 } + + 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.3 Acceptable Response Types + + An OCSP 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-ocsp-response, and the value AcceptableResponses. This + extension is included as one of the requestExtensions in requests. + The OIDs included in AcceptableResponses are the OIDs of the various + response types this client can accept (e.g., id-pkix-ocsp-basic). + + + + +Myers, et al. Standards Track [Page 12] + +RFC 2560 PKIX OCSP June 1999 + + + id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } + + AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER + + As noted in section 4.2.1, OCSP responders SHALL be capable of + responding with responses of the id-pkix-ocsp-basic response type. + Correspondingly, OCSP clients SHALL be capable of receiving and + processing responses of the id-pkix-ocsp-basic response type. + +4.4.4 Archive Cutoff + + An OCSP responder MAY choose to retain revocation information beyond + a certificate's expiration. The date obtained by subtracting this + retention interval value from the producedAt time in a response is + defined as the certificate's "archive cutoff" date. + + OCSP-enabled applications would use an OCSP archive cutoff date to + contribute to a proof that a digital signature was (or was not) + reliable on the date it was produced even if the certificate needed + to validate the signature has long since expired. + + OCSP servers that provide support for such historical reference + SHOULD include an archive cutoff date extension in responses. If + included, this value SHALL be provided as an OCSP singleExtensions + extension identified by id-pkix-ocsp-archive-cutoff and of syntax + GeneralizedTime. + + id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } + + ArchiveCutoff ::= GeneralizedTime + + To illustrate, if a server is operated with a 7-year retention + interval policy and status was produced at time t1 then the value for + ArchiveCutoff in the response would be (t1 - 7 years). + +4.4.5 CRL Entry Extensions + + All the extensions specified as CRL Entry Extensions - in Section 5.3 + of [RFC2459] - are also supported as singleExtensions. + +4.4.6 Service Locator + + An OCSP server may be operated in a mode whereby the server receives + a request and routes it to the OCSP server which is known to be + authoritative for the identified certificate. The serviceLocator + request extension is defined for this purpose. This extension is + included as one of the singleRequestExtensions in requests. + + + + +Myers, et al. Standards Track [Page 13] + +RFC 2560 PKIX OCSP June 1999 + + + id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } + + ServiceLocator ::= SEQUENCE { + issuer Name, + locator AuthorityInfoAccessSyntax OPTIONAL } + + Values for these fields are obtained from the corresponding fields in + the subject certificate. + +5. Security Considerations + + For this service to be effective, certificate using systems must + connect to the certificate status service provider. In the event such + a connection cannot be obtained, certificate-using systems could + implement CRL processing logic as a fall-back position. + + A denial of service vulnerability is evident with respect to a flood + of queries. The production of a cryptographic signature significantly + affects response generation cycle time, thereby exacerbating the + situation. 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 (good) response is replayed prior to its expiration date but + after the certificate has been revoked. Deployments of OCSP should + carefully evaluate the benefit of precomputed responses against the + probability of a replay attack and the costs associated with its + successful execution. + + Requests do not contain the responder they are directed to. This + allows an attacker to replay a request to any number of OCSP + responders. + + The reliance of HTTP caching in some deployment scenarios may result + in unexpected results if intermediate servers are incorrectly + configured or are known to possess cache management faults. + Implementors are advised to take the reliability of HTTP cache + mechanisms into account when deploying OCSP over HTTP. + + + + + + + + + + + + +Myers, et al. Standards Track [Page 14] + +RFC 2560 PKIX OCSP June 1999 + + +6. References + + [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and CRL + Profile", RFC 2459, January 1999. + + [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. + Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC + 2068, January 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform + Resource Locators (URL)", RFC 1738, December 1994. + + [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, + Information Technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers, et al. Standards Track [Page 15] + +RFC 2560 PKIX OCSP June 1999 + + +7. Authors' Addresses + + Michael Myers + VeriSign, Inc. + 1350 Charleston Road + Mountain View, CA 94043 + + EMail: mmyers@verisign.com + + + Rich Ankney + CertCo, LLC + 13506 King Charles Dr. + Chantilly, VA 20151 + + EMail: rankney@erols.com + + + Ambarish Malpani + ValiCert, Inc. + 1215 Terra Bella Ave. + Mountain View, CA 94043 + + Phone: 650.567.5457 + EMail: ambarish@valicert.com + + + Slava Galperin + My CFO, Inc. + 1945 Charleston Road + Mountain View, CA + + EMail: galperin@mycfo.com + + + Carlisle Adams + Entrust Technologies + 750 Heron Road, Suite E08 + Ottawa, Ontario + K1V 1A7 + Canada + + EMail: cadams@entrust.com + + + + + + + + +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: ietf-types@iana.org + 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 <ambarish@valicert.com> + + Intended usage: COMMON + + Author/Change controller: + Ambarish Malpani <ambarish@valicert.com> + +C.2 application/ocsp-response + + To: ietf-types@iana.org + 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 <ambarish@valicert.com> + + Intended usage: COMMON + + Author/Change controller: + Ambarish Malpani <ambarish@valicert.com> + + + + + + + + + + + + + + + + + + + + + + +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] + |