<pre>Internet Engineering Task Force (IETF)                      S. Santesson
Request for Comments: 6960                                  3xA Security
Obsoletes: <a href="./rfc2560">2560</a>, <a href="./rfc6277">6277</a>                                           M. Myers
Updates: <a href="./rfc5912">5912</a>                                        TraceRoute Security
Category: Standards Track                                      R. Ankney
ISSN: 2070-1721
                                                              A. Malpani
                                                         CA Technologies
                                                             S. Galperin
                                                                      A9
                                                                C. Adams
                                                    University of Ottawa
                                                               June 2013


                <span class="h1">X.509 Internet Public Key Infrastructure</span>
               <span class="h1">Online Certificate Status Protocol - OCSP</span>

Abstract

   This document specifies a protocol useful in determining the current
   status of a digital certificate without requiring Certificate
   Revocation Lists (CRLs).  Additional mechanisms addressing PKIX
   operational requirements are specified in separate documents.  This
   document obsoletes RFCs 2560 and 6277.  It also updates <a href="./rfc5912">RFC 5912</a>.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6960">http://www.rfc-editor.org/info/rfc6960</a>.












<span class="grey">Santesson, et al.            Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
      <a href="#section-1.1">1.1</a>. Requirements Language ......................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. Protocol Overview ...............................................<a href="#page-5">5</a>
      <a href="#section-2.1">2.1</a>. Request ....................................................<a href="#page-5">5</a>
      <a href="#section-2.2">2.2</a>. Response ...................................................<a href="#page-6">6</a>
      <a href="#section-2.3">2.3</a>. Exception Cases ............................................<a href="#page-8">8</a>
      <a href="#section-2.4">2.4</a>. Semantics of thisUpdate, nextUpdate, and producedAt ........<a href="#page-9">9</a>
      <a href="#section-2.5">2.5</a>. Response Pre-Production ....................................<a href="#page-9">9</a>
      <a href="#section-2.6">2.6</a>. OCSP Signature Authority Delegation .......................<a href="#page-10">10</a>
      <a href="#section-2.7">2.7</a>. CA Key Compromise .........................................<a href="#page-10">10</a>
   <a href="#section-3">3</a>. Functional Requirements ........................................<a href="#page-10">10</a>
      <a href="#section-3.1">3.1</a>. Certificate Content .......................................<a href="#page-10">10</a>
      <a href="#section-3.2">3.2</a>. Signed Response Acceptance Requirements ...................<a href="#page-10">10</a>
   <a href="#section-4">4</a>. Details of the Protocol ........................................<a href="#page-11">11</a>
      <a href="#section-4.1">4.1</a>. Request Syntax ............................................<a href="#page-11">11</a>
           <a href="#section-4.1.1">4.1.1</a>. ASN.1 Specification of the OCSP Request ............<a href="#page-11">11</a>
           <a href="#section-4.1.2">4.1.2</a>. Notes on OCSP Requests .............................<a href="#page-13">13</a>
      <a href="#section-4.2">4.2</a>. Response Syntax ...........................................<a href="#page-14">14</a>
           <a href="#section-4.2.1">4.2.1</a>. ASN.1 Specification of the OCSP Response ...........<a href="#page-14">14</a>
           <a href="#section-4.2.2">4.2.2</a>. Notes on OCSP Responses ............................<a href="#page-16">16</a>
                  <a href="#section-4.2.2.1">4.2.2.1</a>. Time ......................................<a href="#page-16">16</a>
                  <a href="#section-4.2.2.2">4.2.2.2</a>. Authorized Responders .....................<a href="#page-16">16</a>
                           4.2.2.2.1. Revocation Checking of
                                      an Authorized Responder ........<a href="#page-17">17</a>
                  <a href="#section-4.2.2.3">4.2.2.3</a>. Basic Response ............................<a href="#page-18">18</a>
      <a href="#section-4.3">4.3</a>. Mandatory and Optional Cryptographic Algorithms ...........<a href="#page-19">19</a>








<span class="grey">Santesson, et al.            Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


      <a href="#section-4.4">4.4</a>. Extensions ................................................<a href="#page-19">19</a>
           <a href="#section-4.4.1">4.4.1</a>. Nonce ..............................................<a href="#page-20">20</a>
           <a href="#section-4.4.2">4.4.2</a>. CRL References .....................................<a href="#page-20">20</a>
           <a href="#section-4.4.3">4.4.3</a>. Acceptable Response Types ..........................<a href="#page-20">20</a>
           <a href="#section-4.4.4">4.4.4</a>. Archive Cutoff .....................................<a href="#page-21">21</a>
           <a href="#section-4.4.5">4.4.5</a>. CRL Entry Extensions ...............................<a href="#page-21">21</a>
           <a href="#section-4.4.6">4.4.6</a>. Service Locator ....................................<a href="#page-22">22</a>
           <a href="#section-4.4.7">4.4.7</a>. Preferred Signature Algorithms .....................<a href="#page-22">22</a>
                  <a href="#section-4.4.7.1">4.4.7.1</a>. Extension Syntax ..........................<a href="#page-23">23</a>
                  <a href="#section-4.4.7.2">4.4.7.2</a>. Responder Signature Algorithm Selection ...<a href="#page-24">24</a>
                           <a href="#section-4.4.7.2.1">4.4.7.2.1</a>. Dynamic Response ...............<a href="#page-24">24</a>
                           <a href="#section-4.4.7.2.2">4.4.7.2.2</a>. Static Response ................<a href="#page-25">25</a>
           <a href="#section-4.4.8">4.4.8</a>. Extended Revoked Definition ........................<a href="#page-25">25</a>
   <a href="#section-5">5</a>. Security Considerations ........................................<a href="#page-26">26</a>
      <a href="#section-5.1">5.1</a>. Preferred Signature Algorithms ............................<a href="#page-27">27</a>
           <a href="#section-5.1.1">5.1.1</a>. Use of Insecure Algorithms .........................<a href="#page-27">27</a>
           <a href="#section-5.1.2">5.1.2</a>. Man-in-the-Middle Downgrade Attack .................<a href="#page-27">27</a>
           <a href="#section-5.1.3">5.1.3</a>. Denial-of-Service Attack ...........................<a href="#page-28">28</a>
   <a href="#section-6">6</a>. IANA Considerations ............................................<a href="#page-28">28</a>
   <a href="#section-7">7</a>. References .....................................................<a href="#page-28">28</a>
      <a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-28">28</a>
      <a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-29">29</a>
   <a href="#section-8">8</a>. Acknowledgements ...............................................<a href="#page-29">29</a>
   <a href="#appendix-A">Appendix A</a>. OCSP over HTTP ........................................<a href="#page-30">30</a>
     <a href="#appendix-A.1">A.1</a>. Request ....................................................<a href="#page-30">30</a>
     <a href="#appendix-A.2">A.2</a>. Response ...................................................<a href="#page-30">30</a>
   <a href="#appendix-B">Appendix B</a>. ASN.1 Modules .........................................<a href="#page-30">30</a>
     <a href="#appendix-B.1">B.1</a>. OCSP in ASN.1 - 1998 Syntax ................................<a href="#page-31">31</a>
     <a href="#appendix-B.2">B.2</a>. OCSP in ASN.1 - 2008 Syntax ................................<a href="#page-34">34</a>
   <a href="#appendix-C">Appendix C</a>. MIME Registrations ....................................<a href="#page-39">39</a>
     <a href="#appendix-C.1">C.1</a>. application/ocsp-request ...................................<a href="#page-39">39</a>
     <a href="#appendix-C.2">C.2</a>. application/ocsp-response ..................................<a href="#page-40">40</a>



















<span class="grey">Santesson, et al.            Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   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.

   This specification obsoletes [<a href="./rfc2560" title="&quot;X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP&quot;">RFC2560</a>] and [<a href="./rfc6277" title="&quot;Online Certificate Status Protocol Algorithm Agility&quot;">RFC6277</a>].  The primary
   reason for the publication of this document is to address ambiguities
   that have been found since the publication of <a href="./rfc2560">RFC 2560</a>.  This
   document differs from <a href="./rfc2560">RFC 2560</a> in only a few areas:

   o  <a href="#section-2.2">Section 2.2</a> extends the use of the "revoked" response to allow
      this response status for certificates that have never been issued.

   o  <a href="#section-2.3">Section 2.3</a> extends the use of the "unauthorized" error response,
      as specified in [<a href="./rfc5019" title="&quot;The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments&quot;">RFC5019</a>].

   o  Sections <a href="#section-4.2.1">4.2.1</a> and <a href="#section-4.2.2.3">4.2.2.3</a> state that a response may include
      revocation status information for certificates that were not
      included in the request, as permitted in [<a href="./rfc5019" title="&quot;The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments&quot;">RFC5019</a>].

   o  <a href="#section-4.2.2.2">Section 4.2.2.2</a> clarifies when a responder is considered an
      Authorized Responder.

   o  <a href="#section-4.2.2.3">Section 4.2.2.3</a> clarifies that the ResponderID field corresponds
      to the OCSP responder signer certificate.

   o  <a href="#section-4.3">Section 4.3</a> changes the set of cryptographic algorithms that
      clients must support and the set of cryptographic algorithms that
      clients should support as specified in [<a href="./rfc6277" title="&quot;Online Certificate Status Protocol Algorithm Agility&quot;">RFC6277</a>].

   o  <a href="#section-4.4.1">Section 4.4.1</a> specifies, for the nonce extension, ASN.1 syntax
      that was missing in <a href="./rfc2560">RFC 2560</a>.

   o  <a href="#section-4.4.7">Section 4.4.7</a> specifies a new extension that may be included in a
      request message to specify signature algorithms the client would
      prefer the server use to sign the response as specified in
      [<a href="./rfc6277" title="&quot;Online Certificate Status Protocol Algorithm Agility&quot;">RFC6277</a>].

   o  <a href="#section-4.4.8">Section 4.4.8</a> specifies a new extension that indicates that the
      responder supports the extended use of the "revoked" response for
      non-issued certificates defined in <a href="#section-2.2">Section 2.2</a>.

   o  <a href="#appendix-B.2">Appendix B.2</a> provides an ASN.1 module using the 2008 syntax of
      ASN.1, which updates [<a href="./rfc5912" title="&quot;New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)&quot;">RFC5912</a>].





<span class="grey">Santesson, et al.            Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   An overview of the protocol is provided in <a href="#section-2">Section 2</a>.  Functional
   requirements are specified in <a href="#section-3">Section 3</a>.  Details of the protocol are
   discussed in <a href="#section-4">Section 4</a>.  We cover security issues with the protocol
   in <a href="#section-5">Section 5</a>.  <a href="#appendix-A">Appendix A</a> defines OCSP over HTTP, <a href="#appendix-B">Appendix B</a> provides
   ASN.1 syntactic elements, and <a href="#appendix-C">Appendix C</a> specifies the MIME types for
   the messages.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Requirements Language</span>

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Protocol Overview</span>

   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 certificates (cf. <a href="./rfc5280#section-3.3">[RFC5280], Section&nbsp;3.3</a>).
   Examples include high-value funds transfers or large stock trades.

   The Online Certificate Status Protocol (OCSP) enables applications to
   determine the (revocation) state of identified certificates.  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 certificates 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 one or more certificates and
   the server providing the corresponding status.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Request</span>

   An OCSP request contains the following data:

   - protocol version

   - service request

   - target certificate identifier

   - optional extensions, which MAY be processed by the OCSP responder







<span class="grey">Santesson, et al.            Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   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 these conditions is not met, the OCSP responder
   produces an error message; otherwise, it returns a definitive
   response.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Response</span>

   OCSP responses can be of various types.  An OCSP response consists of
   a response type and the bytes of the actual response.  There is one
   basic type of OCSP response that MUST be supported by all OCSP
   servers and clients.  The rest of this section pertains only to this
   basic response type.

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

   - the CA who issued the certificate in question

   - a Trusted Responder whose public key is trusted by the requestor

   - a CA Designated Responder (Authorized Responder, defined in
     <a href="#section-4.2.2.2">Section 4.2.2.2</a>) 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

   - identifier of the responder

   - time when the response was generated

   - responses for each of the certificates in a request

   - optional extensions

   - signature algorithm OID

   - signature computed across a hash of the response




<span class="grey">Santesson, et al.            Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   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 no certificate
   with the requested certificate serial number currently within its
   validity interval is revoked.  This state 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 a positive statement about issuance, validity,
   etc.

   The "revoked" state indicates that the certificate has been revoked,
   either temporarily (the revocation reason is certificateHold) or
   permanently.  This state MAY also be returned if the associated CA
   has no record of ever having issued a certificate with the
   certificate serial number in the request, using any current or
   previous issuing key (referred to as a "non-issued" certificate in
   this document).

   The "unknown" state indicates that the responder doesn't know about
   the certificate being requested, usually because the request
   indicates an unrecognized issuer that is not served by this
   responder.

   NOTE: The "revoked" status indicates that a certificate with the
         requested serial number should be rejected, while the "unknown"
         status indicates that the status could not be determined by
         this responder, thereby allowing the client to decide whether
         it wants to try another source of status information (such as a



<span class="grey">Santesson, et al.            Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


         CRL).  This makes the "revoked" response suitable for
         non-issued certificates (as defined above) where the intention
         of the responder is to cause the client to reject the
         certificate rather than trying another source of status
         information.  The "revoked" status is still optional for
         non-issued certificates in order to maintain backwards
         compatibility with deployments of <a href="./rfc2560">RFC 2560</a>.  For example, the
         responder may not have any knowledge about whether a requested
         serial number has been assigned to any issued certificate, or
         the responder may provide pre-produced responses in accordance
         with <a href="./rfc5019">RFC 5019</a> and, for that reason, is not capable of providing
         a signed response for all non-issued certificate serial
         numbers.

   When a responder sends a "revoked" response to a status request for a
   non-issued certificate, the responder MUST include the extended
   revoked definition response extension (<a href="#section-4.4.8">Section 4.4.8</a>) in the
   response, indicating that the OCSP responder supports the extended
   definition of the "revoked" state to also cover non-issued
   certificates.  In addition, the SingleResponse related to this
   non-issued certificate:

   - MUST specify the revocation reason certificateHold (6),

   - MUST specify the revocationTime January 1, 1970, and

   - MUST NOT include a CRL references extension (<a href="#section-4.4.2">Section 4.4.2</a>) or any
     CRL entry extensions (<a href="#section-4.4.5">Section 4.4.5</a>).

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Exception Cases</span>

   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.





<span class="grey">Santesson, et al.            Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   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 that 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 or the server is not
   capable of responding authoritatively (cf. <a href="./rfc5019#section-2.2.3">[RFC5019], Section&nbsp;2.2.3</a>).

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Semantics of thisUpdate, nextUpdate, and producedAt</span>

   Responses defined in this document can contain four times --
   thisUpdate, nextUpdate, producedAt, and revocationTime.  The
   semantics of these fields are:

   thisUpdate      The most recent time at which the status being
                   indicated is known by the responder to have been
                   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.

   revocationTime  The time at which the certificate was revoked or
                   placed on hold.

<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>.  Response Pre-Production</span>

   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.






<span class="grey">Santesson, et al.            Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>.  OCSP Signature Authority Delegation</span>

   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 the extended key usage extension
   (defined in <a href="./rfc5280#section-4.2.1.12">[RFC5280], Section&nbsp;4.2.1.12</a>) in the OCSP signer's
   certificate.  This certificate MUST be issued directly to the
   responder by the cognizant CA.  See <a href="#section-4.2.2.2">Section 4.2.2.2</a> for details.

<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>.  CA Key Compromise</span>

   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.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Functional Requirements</span>

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Certificate Content</span>

   In order to convey to OCSP clients a well-known point of information
   access, CAs SHALL provide the capability to include the authority
   information access extension (defined in <a href="./rfc5280#section-4.2.2.1">[RFC5280], Section&nbsp;4.2.2.1</a>)
   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 Uniform Resource Identifier (URI) [<a href="./rfc3986" title="&quot;Uniform Resource Identifier (URI): Generic Syntax&quot;">RFC3986</a>] 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).

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Signed Response Acceptance Requirements</span>

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

   1. The certificate identified in a received response corresponds to
      the certificate that was identified in the corresponding request;

   2. The signature on the response is valid;





<span class="grey">Santesson, et al.            Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   3. The identity of the signer matches the intended recipient of the
      request;

   4. The signer is currently authorized to provide a response for the
      certificate in question;

   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.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Details of the Protocol</span>

   The ASN.1 syntax imports terms defined in [<a href="./rfc5280" title="&quot;Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC5280</a>].  For signature
   calculation, the data to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [<a href="#ref-X.690" title="&quot;Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)&quot;">X.690</a>].

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

   The terms imported from elsewhere are Extensions,
   CertificateSerialNumber, SubjectPublicKeyInfo, Name,
   AlgorithmIdentifier, and CRLReason.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Request Syntax</span>

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

<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>.  ASN.1 Specification of the OCSP Request</span>

   The ASN.1 structure corresponding to the OCSPRequest is:

   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 }






<span class="grey">Santesson, et al.            Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   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 issuer's public key
       serialNumber        CertificateSerialNumber }

   The fields in OCSPRequest have the following meanings:

   o  tbsRequest is the optionally signed OCSP request.

   o  optionalSignature contains the algorithm identifier and any
      associated algorithm parameters in signatureAlgorithm; the
      signature value in signature; and, optionally, certificates the
      server needs to verify the signed response (normally up to but not
      including the client's root certificate).

   The contents of TBSRequest include the following fields:

   o  version indicates the version of the protocol, which for this
      document is v1(0).

   o  requestorName is OPTIONAL and indicates the name of the OCSP
      requestor.

   o  requestList contains one or more single certificate status
      requests.

   o  requestExtensions is OPTIONAL and includes extensions applicable
      to the requests found in reqCert.  See <a href="#section-4.4">Section 4.4</a>.










<span class="grey">Santesson, et al.            Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   The contents of Request include the following fields:

   o  reqCert contains the identifier of a target certificate.

   o  singleRequestExtensions is OPTIONAL and includes extensions
      applicable to this single certificate status request.  See
      <a href="#section-4.4">Section 4.4</a>.

   The contents of CertID include the following fields:

   o  hashAlgorithm is the hash algorithm used to generate the
      issuerNameHash and issuerKeyHash values.

   o  issuerNameHash is the hash of the issuer's distinguished name
      (DN).  The hash shall be calculated over the DER encoding of the
      issuer's name field in the certificate being checked.

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

   o  serialNumber is the serial number of the certificate for which
      status is being requested.

<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>.  Notes on OCSP Requests</span>

   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.  <a href="#section-4.4">Section 4.4</a> 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).

   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.





<span class="grey">Santesson, et al.            Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Response Syntax</span>

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

<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>.  ASN.1 Specification of the OCSP Response</span>

   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, the responseBytes
   field is 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 }

   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.








<span class="grey">Santesson, et al.            Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   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 of ResponseData.  The responder MAY include certificates in
   the certs field of BasicOCSPResponse that help the OCSP client verify
   the responder's signature.  If no certificates are included, then
   certs SHOULD be absent.

   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





<span class="grey">Santesson, et al.            Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>.  Notes on OCSP Responses</span>

<span class="h5"><a class="selflink" id="section-4.2.2.1" href="#section-4.2.2.1">4.2.2.1</a>.  Time</span>

   Responses can contain four times -- thisUpdate, nextUpdate,
   producedAt, and revocationTime.  The semantics of these fields are
   defined in <a href="#section-2.4">Section 2.4</a>.  The format for GeneralizedTime is as
   specified in <a href="./rfc5280#section-4.1.2.5.2">Section&nbsp;4.1.2.5.2 of [RFC5280]</a>.

   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.

   If nextUpdate is not set, the responder is indicating that newer
   revocation information is available all the time.

<span class="h5"><a class="selflink" id="section-4.2.2.2" href="#section-4.2.2.2">4.2.2.2</a>.  Authorized Responders</span>

   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 do one of the following:

   - sign the OCSP responses itself, or

   - explicitly designate this authority to another entity

   OCSP signing delegation SHALL be designated by the inclusion of
   id-kp-OCSPSigning in an extended key usage certificate extension
   included in the OCSP response signer's certificate.  This certificate
   MUST be issued directly by the CA that is identified in the request.

   The CA SHOULD use the same issuing key to issue a delegation
   certificate as that used to sign the certificate being checked for
   revocation.  Systems relying on OCSP responses MUST recognize a
   delegation certificate as being issued by the CA that issued the
   certificate in question only if the delegation certificate and the
   certificate being checked for revocation were signed by the same key.










<span class="grey">Santesson, et al.            Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   Note: For backwards compatibility with <a href="./rfc2560">RFC 2560</a> [<a href="./rfc2560" title="&quot;X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP&quot;">RFC2560</a>], it is not
         prohibited to issue a certificate for an Authorized Responder
         using a different issuing key than the key used to issue the
         certificate being checked for revocation.  However, such a
         practice is strongly discouraged, since clients are not
         required to recognize a responder with such a certificate as an
         Authorized Responder.

   id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing the use of the id-kp-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 does not 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-kp-OCSPSigning in an extended key usage
      extension and is issued by the CA that issued the certificate in
      question as stated above.

   Additional acceptance or rejection criteria may apply to either the
   response itself or to the certificate used to validate the signature
   on the response.

<span class="h6"><a class="selflink" id="section-4.2.2.2.1" href="#section-4.2.2.2.1">4.2.2.2.1</a>.  Revocation Checking of an Authorized Responder</span>

   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 SHALL be NULL.
     CAs issuing such a certificate should realize that a compromise of
     the responder's key is as serious as the compromise of a CA key






<span class="grey">Santesson, et al.            Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


     used to sign CRLs, at least for the validity period of this
     certificate.  CAs 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 is to be checked
     for revocation.  This can be done by using CRL Distribution Points
     if the check should be done using CRLs, or by using Authority
     Information Access if the check should be done in some other way.
     Details for specifying either of these two mechanisms are available
     in [<a href="./rfc5280" title="&quot;Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC5280</a>].

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

<span class="h5"><a class="selflink" id="section-4.2.2.3" href="#section-4.2.2.3">4.2.2.3</a>.  Basic Response</span>

   The basic response type contains:

   o  the version of the response syntax, which MUST be v1 (value is 0)
      for this version of the basic response syntax;

   o  either the name of the responder or a hash of the responder's
      public key as the ResponderID;

   o  the time at which the response was generated;

   o  responses for each of the certificates in a request;

   o  optional extensions;

   o  a signature computed across a hash of the response; and

   o  the signature algorithm OID.

   The purpose of the ResponderID information is to allow clients to
   find the certificate used to sign a signed OCSP response.  Therefore,
   the information MUST correspond to the certificate that was used to
   sign the response.

   The responder MAY include certificates in the certs field of
   BasicOCSPResponse that help the OCSP client verify the responder's
   signature.





<span class="grey">Santesson, et al.            Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


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

   o  an identifier of the certificate for which revocation status
      information is being provided (i.e., the target certificate);

   o  the revocation status of the certificate (good, revoked, or
      unknown); if revoked, it indicates the time at which the
      certificate was revoked and, optionally, the reason why it was
      revoked;

   o  the validity interval of the response; and

   o  optional extensions.

   The response MUST include a SingleResponse for each certificate in
   the request.  The response SHOULD NOT include any additional
   SingleResponse elements, but, for example, OCSP responders that
   pre-generate status responses might include additional SingleResponse
   elements if necessary to improve response pre-generation performance
   or cache efficiency (according to <a href="./rfc5019#section-2.2.1">[RFC5019], Section&nbsp;2.2.1</a>).

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Mandatory and Optional Cryptographic Algorithms</span>

   Clients that request OCSP services SHALL be capable of processing
   responses signed using RSA with SHA-256 (identified by the
   sha256WithRSAEncryption OID specified in [<a href="./rfc4055" title="&quot;Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC4055</a>]).  Clients SHOULD
   also be capable of processing responses signed using RSA with SHA-1
   (identified by the sha1WithRSAEncryption OID specified in [<a href="./rfc3279" title="&quot;Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC3279</a>])
   and the Digital Signature Algorithm (DSA) with SHA-1 (identified by
   the id-dsa-with-sha1 OID specified in [<a href="./rfc3279" title="&quot;Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC3279</a>]).  Clients MAY
   support other algorithms.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Extensions</span>

   This section defines some standard extensions, based on the extension
   model employed in X.509 version 3 certificates (see [<a href="./rfc5280" title="&quot;Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC5280</a>]).
   Support for all extensions is optional for both clients and
   responders.  For each extension, the definition indicates its syntax,
   processing performed by the OCSP responder, and any extensions that
   are included in the corresponding response.











<span class="grey">Santesson, et al.            Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>.  Nonce</span>

   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           OBJECT IDENTIFIER ::= { id-ad-ocsp }
     id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

     Nonce ::= OCTET STRING

<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a>.  CRL References</span>

   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.

<span class="h4"><a class="selflink" id="section-4.4.3" href="#section-4.4.3">4.4.3</a>.  Acceptable Response Types</span>

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





<span class="grey">Santesson, et al.            Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


     id-pkix-ocsp-response  OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }

     AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

   As noted in <a href="#section-4.2.1">Section 4.2.1</a>, 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.

<span class="h4"><a class="selflink" id="section-4.4.4" href="#section-4.4.4">4.4.4</a>.  Archive Cutoff</span>

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

<span class="h4"><a class="selflink" id="section-4.4.5" href="#section-4.4.5">4.4.5</a>.  CRL Entry Extensions</span>

   All the extensions specified as CRL entry extensions -- in
   <a href="./rfc5280#section-5.3">Section&nbsp;5.3 of [RFC5280]</a> -- are also supported as singleExtensions.












<span class="grey">Santesson, et al.            Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


<span class="h4"><a class="selflink" id="section-4.4.6" href="#section-4.4.6">4.4.6</a>.  Service Locator</span>

   An OCSP server may be operated in a mode whereby the server receives
   a request and routes it to the OCSP server that 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.

     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.

<span class="h4"><a class="selflink" id="section-4.4.7" href="#section-4.4.7">4.4.7</a>.  Preferred Signature Algorithms</span>

   Since algorithms other than the mandatory-to-implement algorithms are
   allowed, and since a client currently has no mechanism to indicate
   its algorithm preferences, there is always a risk that a server
   choosing a non-mandatory algorithm will generate a response that the
   client may not support.

   While an OCSP responder may apply rules for algorithm selection,
   e.g., using the signature algorithm employed by the CA for signing
   CRLs and certificates, such rules may fail in common situations:

   o  The algorithm used to sign the CRLs and certificates may not be
      consistent with the key pair being used by the OCSP responder to
      sign responses.

   o  A request for an unknown certificate provides no basis for a
      responder to select from among multiple algorithm options.

   The last criterion cannot be resolved through the information
   available from in-band signaling using the <a href="./rfc2560">RFC 2560</a> [<a href="./rfc2560" title="&quot;X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP&quot;">RFC2560</a>]
   protocol without modifying the protocol.












<span class="grey">Santesson, et al.            Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   In addition, an OCSP responder may wish to employ different signature
   algorithms than the one used by the CA to sign certificates and CRLs
   for two reasons:

   o  The responder may employ an algorithm for certificate status
      response that is less computationally demanding than for signing
      the certificate itself.

   o  An implementation may wish to guard against the possibility of a
      compromise resulting from a signature algorithm compromise by
      employing two separate signature algorithms.

   This section describes:

   o  An extension that allows a client to indicate the set of preferred
      signature algorithms.

   o  Rules for signature algorithm selection that maximize the
      probability of successful operation in the case that no supported
      preferred algorithm(s) are specified.

<span class="h5"><a class="selflink" id="section-4.4.7.1" href="#section-4.4.7.1">4.4.7.1</a>.  Extension Syntax</span>

   A client MAY declare a preferred set of algorithms in a request by
   including a preferred signature algorithms extension in
   requestExtensions of the OCSPRequest.

     id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }

     PreferredSignatureAlgorithms ::= SEQUENCE OF
                                      PreferredSignatureAlgorithm

     PreferredSignatureAlgorithm ::= SEQUENCE {
        sigIdentifier        AlgorithmIdentifier,
        pubKeyAlgIdentifier  SMIMECapability OPTIONAL
        }

   The syntax of AlgorithmIdentifier is defined in <a href="./rfc5280#section-4.1.1.2">Section&nbsp;4.1.1.2 of
   RFC 5280</a> [<a href="./rfc5280" title="&quot;Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC5280</a>].  The syntax of SMIMECapability is defined in
   <a href="./rfc5751">RFC 5751</a> [<a href="./rfc5751" title="&quot;Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification&quot;">RFC5751</a>].

   sigIdentifier specifies the signature algorithm the client prefers,
   e.g., algorithm=ecdsa-with-sha256.  Parameters are absent for most
   common signature algorithms.







<span class="grey">Santesson, et al.            Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   pubKeyAlgIdentifier specifies the subject public key algorithm
   identifier the client prefers in the server's certificate used to
   validate the OCSP response, e.g., algorithm=id-ecPublicKey and
   parameters= secp256r1.

   pubKeyAlgIdentifier is OPTIONAL and provides a means to specify
   parameters necessary to distinguish among different usages of a
   particular algorithm, e.g., it may be used by the client to specify
   what curve it supports for a given elliptic curve algorithm.

   The client MUST support each of the specified preferred signature
   algorithms, and the client MUST specify the algorithms in the order
   of preference, from the most preferred to the least preferred.

   <a href="#section-4.4.7.2">Section 4.4.7.2</a> of this document describes how a server selects an
   algorithm for signing OCSP responses to the requesting client.

<span class="h5"><a class="selflink" id="section-4.4.7.2" href="#section-4.4.7.2">4.4.7.2</a>.  Responder Signature Algorithm Selection</span>

   <a href="./rfc2560">RFC 2560</a> [<a href="./rfc2560" title="&quot;X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP&quot;">RFC2560</a>] did not specify a mechanism for deciding the
   signature algorithm to be used in an OCSP response.  This does not
   provide a sufficient degree of certainty as to the algorithm selected
   to facilitate interoperability.

<span class="h6"><a class="selflink" id="section-4.4.7.2.1" href="#section-4.4.7.2.1">4.4.7.2.1</a>.  Dynamic Response</span>

   A responder MAY maximize the potential for ensuring interoperability
   by selecting a supported signature algorithm using the following
   order of precedence, as long as the selected algorithm meets all
   security requirements of the OCSP responder, where the first
   selection mechanism has the highest precedence:

   1. Select an algorithm specified as a preferred signature algorithm
      in the client request.

   2. Select the signature algorithm used to sign a certificate
      revocation list (CRL) issued by the certificate issuer providing
      status information for the certificate specified by CertID.

   3. Select the signature algorithm used to sign the OCSPRequest.

   4. Select a signature algorithm that has been advertised as being the
      default signature algorithm for the signing service using an
      out-of-band mechanism.

   5. Select a mandatory or recommended signature algorithm specified
      for the version of OCSP in use.




<span class="grey">Santesson, et al.            Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   A responder SHOULD always apply the lowest-numbered selection
   mechanism that results in the selection of a known and supported
   algorithm that meets the responder's criteria for cryptographic
   algorithm strength.

<span class="h6"><a class="selflink" id="section-4.4.7.2.2" href="#section-4.4.7.2.2">4.4.7.2.2</a>.  Static Response</span>

   For purposes of efficiency, an OCSP responder is permitted to
   generate static responses in advance of a request.  The case may not
   permit the responder to make use of the client request data during
   the response generation; however, the responder SHOULD still use the
   client request data during the selection of the pre-generated
   response to be returned.  Responders MAY use the historical client
   requests as part of the input to the decisions of what different
   algorithms should be used to sign the pre-generated responses.

<span class="h4"><a class="selflink" id="section-4.4.8" href="#section-4.4.8">4.4.8</a>.  Extended Revoked Definition</span>

   This extension indicates that the responder supports the extended
   definition of the "revoked" status to also include non-issued
   certificates according to <a href="#section-2.2">Section 2.2</a>.  One of its main purposes is
   to allow audits to determine the responder's type of operation.
   Clients do not have to parse this extension in order to determine the
   status of certificates in responses.

   This extension MUST be included in the OCSP response when that
   response contains a "revoked" status for a non-issued certificate.
   This extension MAY be present in other responses to signal that the
   responder implements the extended revoked definition.  When included,
   this extension MUST be placed in responseExtensions, and it MUST NOT
   appear in singleExtensions.

   This extension is identified by the object identifier
   id-pkix-ocsp-extended-revoke.

     id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}

   The value of the extension SHALL be NULL.  This extension MUST NOT be
   marked critical.












<span class="grey">Santesson, et al.            Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Security Considerations</span>

   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 vulnerability to denial of service 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.

   Responding with a "revoked" state to a certificate that has never
   been issued may enable someone to obtain a revocation response for a
   certificate that is not yet issued, but soon will be issued, if the
   certificate serial number of the certificate that will be issued can
   be predicted or guessed by the requestor.  Such a prediction is easy
   for a CA that issues certificates using sequential certificate serial
   number assignment.  This risk is handled in the specification by
   requiring compliant implementations to use the certificateHold reason
   code, which avoids permanently revoking the serial number.  For CAs
   that support "revoked" responses to status requests for non-issued
   certificates, one way to completely avoid this issue is to assign
   random certificate serial number values with high entropy.








<span class="grey">Santesson, et al.            Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Preferred Signature Algorithms</span>

   The mechanism used to choose the response signing algorithm MUST be
   considered to be sufficiently secure against cryptanalytic attack for
   the intended application.

   In most applications, it is sufficient for the signing algorithm to
   be at least as secure as the signing algorithm used to sign the
   original certificate whose status is being queried.  However, this
   criterion may not hold in long-term archival applications, in which
   the status of a certificate is being queried for a date in the
   distant past, long after the signing algorithm has ceased being
   considered trustworthy.

<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>.  Use of Insecure Algorithms</span>

   It is not always possible for a responder to generate a response that
   the client is expected to understand and that meets contemporary
   standards for cryptographic security.  In such cases, an OCSP
   responder operator MUST balance the risk of employing a compromised
   security solution and the cost of mandating an upgrade, including the
   risk that the alternative chosen by end users will offer even less
   security or no security.

   In archival applications, it is quite possible that an OCSP responder
   might be asked to report the validity of a certificate on a date in
   the distant past.  Such a certificate might employ a signing method
   that is no longer considered acceptably secure.  In such
   circumstances, the responder MUST NOT generate a signature using a
   signing mechanism that is not considered acceptably secure.

   A client MUST accept any signing algorithm in a response that it
   specified as a preferred signing algorithm in the request.  It
   follows, therefore, that a client MUST NOT specify as a preferred
   signing algorithm any algorithm that is either not supported or not
   considered acceptably secure.

<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>.  Man-in-the-Middle Downgrade Attack</span>

   The mechanism to support client indication of preferred signature
   algorithms is not protected against a man-in-the-middle downgrade
   attack.  This constraint is not considered to be a significant
   security concern, since the OCSP responder MUST NOT sign OCSP
   responses using weak algorithms even if requested by the client.  In
   addition, the client can reject OCSP responses that do not meet its
   own criteria for acceptable cryptographic security no matter what
   mechanism is used to determine the signing algorithm of the response.




<span class="grey">Santesson, et al.            Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>.  Denial-of-Service Attack</span>

   Algorithm agility mechanisms defined in this document introduce a
   slightly increased attack surface for denial-of-service attacks where
   the client request is altered to require algorithms that are not
   supported by the server.  Denial-of-service considerations as
   discussed in <a href="./rfc4732">RFC 4732</a> [<a href="./rfc4732" title="&quot;Internet Denial-of-Service Considerations&quot;">RFC4732</a>] are relevant for this document.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  IANA Considerations</span>

   This document includes media type registrations (in <a href="#appendix-C">Appendix C</a>) for
   ocsp-request and ocsp-response that were registered when <a href="./rfc2560">RFC 2560</a> was
   published.  Because this document obsoletes <a href="./rfc2560">RFC 2560</a>, IANA has
   updated the references in the "Application Media Types" registry for
   ocsp-request and ocsp-response to point to this document.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  References</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC2616">RFC2616</a>]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.

   [<a id="ref-RFC3279">RFC3279</a>]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
              Identifiers for the Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", <a href="./rfc3279">RFC 3279</a>, April 2002.

   [<a id="ref-RFC3986">RFC3986</a>]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              <a href="./rfc3986">RFC 3986</a>, January 2005.

   [<a id="ref-RFC4055">RFC4055</a>]  Schaad, J., Kaliski, B., and R. Housley, "Additional
              Algorithms and Identifiers for RSA Cryptography for use in
              the Internet X.509 Public Key Infrastructure Certificate
              and Certificate Revocation List (CRL) Profile", <a href="./rfc4055">RFC 4055</a>,
              June 2005.

   [<a id="ref-RFC5280">RFC5280</a>]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", <a href="./rfc5280">RFC 5280</a>, May 2008.





<span class="grey">Santesson, et al.            Standards Track                   [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   [<a id="ref-RFC5751">RFC5751</a>]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", <a href="./rfc5751">RFC 5751</a>, January 2010.

   [<a id="ref-RFC6277">RFC6277</a>]  Santesson, S. and P. Hallam-Baker, "Online Certificate
              Status Protocol Algorithm Agility", <a href="./rfc6277">RFC 6277</a>, June 2011.

   [<a id="ref-X.690">X.690</a>]    ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008,
              "Information Technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", November 2008.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Informative References</span>

   [<a id="ref-RFC2560">RFC2560</a>]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", <a href="./rfc2560">RFC 2560</a>, June 1999.

   [<a id="ref-RFC4732">RFC4732</a>]  Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
              Denial-of-Service Considerations", <a href="./rfc4732">RFC 4732</a>,
              December 2006.

   [<a id="ref-RFC5019">RFC5019</a>]  Deacon, A. and R. Hurst, "The Lightweight Online
              Certificate Status Protocol (OCSP) Profile for High-Volume
              Environments", <a href="./rfc5019">RFC 5019</a>, September 2007.

   [<a id="ref-RFC5912">RFC5912</a>]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
              Public Key Infrastructure Using X.509 (PKIX)", <a href="./rfc5912">RFC 5912</a>,
              June 2010.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Acknowledgements</span>

   Development of this document has been made possible thanks to
   extensive inputs from members of the PKIX working group.

   Jim Schaad provided valuable support by compiling and checking the
   ASN.1 modules of this specification.













<span class="grey">Santesson, et al.            Standards Track                   [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  OCSP over HTTP</span>

   This section describes the formatting that will be done to the
   request and response to support HTTP [<a href="./rfc2616" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">RFC2616</a>].

<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>.  Request</span>

   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 if 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 Transport Layer Security/Secure Socket Layer
   (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 the authority
   information access extension in the certificate being checked for
   revocation, 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.

<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>.  Response</span>

   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.

<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  ASN.1 Modules</span>

   This appendix includes the ASN.1 modules for OCSP.  <a href="#appendix-B.1">Appendix B.1</a>
   includes an ASN.1 module that conforms to the 1998 version of ASN.1
   for all syntax elements of OCSP, including the preferred signature
   algorithms extension that was defined in [<a href="./rfc6277" title="&quot;Online Certificate Status Protocol Algorithm Agility&quot;">RFC6277</a>].  This module
   replaces the modules in <a href="./rfc2560#appendix-B">Appendix&nbsp;B of [RFC2560]</a> and <a href="./rfc6277#appendix-A.2">Appendix&nbsp;A.2 of
   [RFC6277]</a>.  <a href="#appendix-B.2">Appendix B.2</a> includes an ASN.1 module, corresponding to
   the module present in B.1, that conforms to the 2008 version of



<span class="grey">Santesson, et al.            Standards Track                   [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


   ASN.1.  This module replaces the modules in <a href="./rfc5912#section-12">Section&nbsp;12 of [RFC5912]</a>
   and <a href="./rfc6277#appendix-A.1">Appendix&nbsp;A.1 of [RFC6277]</a>.  Although a 2008 ASN.1 module is
   provided, the module in <a href="#appendix-B.1">Appendix B.1</a> remains the normative module as
   per the policy of the PKIX working group.

<span class="h3"><a class="selflink" id="appendix-B.1" href="#appendix-B.1">B.1</a>.  OCSP in ASN.1 - 1998 Syntax</span>

OCSP-2013-88
      {iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-ocsp-2013-88(81)}

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

IMPORTS

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

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

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) }





<span class="grey">Santesson, et al.            Standards Track                   [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


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 issuer's 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 }







<span class="grey">Santesson, et al.            Standards Track                   [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
                         -- (i.e., the SHA-1 hash of the value of the
                         -- BIT STRING subjectPublicKey [excluding
                         -- the tag, length, and number of unused
                         -- bits] in the responder's certificate)

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

ArchiveCutoff ::= GeneralizedTime

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

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

CrlID ::= SEQUENCE {
    crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
    crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
    crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm

PreferredSignatureAlgorithm ::= SEQUENCE {
   sigIdentifier   AlgorithmIdentifier,
   certIdentifier  AlgorithmIdentifier OPTIONAL }









<span class="grey">Santesson, et al.            Standards Track                   [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


-- 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 }
id-pkix-ocsp-pref-sig-algs   OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }

END

<span class="h3"><a class="selflink" id="appendix-B.2" href="#appendix-B.2">B.2</a>.  OCSP in ASN.1 - 2008 Syntax</span>

OCSP-2013-08
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-2013-08(82)}

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

IMPORTS

Extensions{}, EXTENSION, ATTRIBUTE
FROM PKIX-CommonTypes-2009 -- From [<a href="./rfc5912" title="&quot;New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)&quot;">RFC5912</a>]
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}

AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY
FROM AlgorithmInformation-2009 -- From [<a href="./rfc5912" title="&quot;New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)&quot;">RFC5912</a>]
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0)
    id-mod-algorithmInformation-02(58)}

AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions
FROM PKIX1Implicit-2009 -- From [<a href="./rfc5912" title="&quot;New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)&quot;">RFC5912</a>]
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}

Name, CertificateSerialNumber, id-kp, id-ad-ocsp, Certificate
FROM PKIX1Explicit-2009 -- From [<a href="./rfc5912" title="&quot;New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)&quot;">RFC5912</a>]
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}



<span class="grey">Santesson, et al.            Standards Track                   [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


sa-dsaWithSHA1, sa-rsaWithMD2, sa-rsaWithMD5, sa-rsaWithSHA1
FROM PKIXAlgs-2009 -- From [<a href="./rfc5912" title="&quot;New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)&quot;">RFC5912</a>]
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0)
    id-mod-pkix1-algorithms2008-02(56)};

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 {{re-ocsp-nonce |
                     re-ocsp-response, ...,
                     re-ocsp-preferred-signature-algorithms}} OPTIONAL }

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

Version  ::=  INTEGER  {  v1(0) }

Request ::=     SEQUENCE {
    reqCert                    CertID,
    singleRequestExtensions    [0] EXPLICIT Extensions
                                       { {re-ocsp-service-locator,
                                              ...}} OPTIONAL }

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

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









<span class="grey">Santesson, et al.            Standards Track                   [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


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
}

RESPONSE ::= TYPE-IDENTIFIER

ResponseSet RESPONSE ::= {basicResponse, ...}

ResponseBytes ::=       SEQUENCE {
    responseType        RESPONSE.
                            &amp;id ({ResponseSet}),
    response            OCTET STRING (CONTAINING RESPONSE.
                            &amp;Type({ResponseSet}{@responseType}))}

basicResponse RESPONSE ::=
    { BasicOCSPResponse IDENTIFIED BY id-pkix-ocsp-basic }

BasicOCSPResponse       ::= SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier{SIGNATURE-ALGORITHM,
                            {sa-dsaWithSHA1 | sa-rsaWithSHA1 |
                                 sa-rsaWithMD5 | sa-rsaWithMD2, ...}},
   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
                               {{re-ocsp-nonce, ...,
                                 re-ocsp-extended-revoke}} 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)





<span class="grey">Santesson, et al.            Standards Track                   [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


SingleResponse ::= SEQUENCE {
   certID                       CertID,
   certStatus                   CertStatus,
   thisUpdate                   GeneralizedTime,
   nextUpdate           [0]     EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions     [1]     EXPLICIT Extensions{{re-ocsp-crl |
                                             re-ocsp-archive-cutoff |
                                             CrlEntryExtensions, ...}
                                             } 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

ArchiveCutoff ::= GeneralizedTime

AcceptableResponses ::= SEQUENCE OF RESPONSE.&amp;id({ResponseSet})

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

CrlID ::= SEQUENCE {
    crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
    crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
    crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm

PreferredSignatureAlgorithm ::= SEQUENCE {
   sigIdentifier  AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
   certIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}} OPTIONAL
}

-- Certificate Extensions

ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED
                                 BY id-pkix-ocsp-nocheck }






<span class="grey">Santesson, et al.            Standards Track                   [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


-- Request Extensions

re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED
                              BY id-pkix-ocsp-nonce }

re-ocsp-response EXTENSION ::= { SYNTAX AcceptableResponses IDENTIFIED
                                 BY id-pkix-ocsp-response }

re-ocsp-service-locator EXTENSION ::= { SYNTAX ServiceLocator
                                        IDENTIFIED BY
                                        id-pkix-ocsp-service-locator }

re-ocsp-preferred-signature-algorithms EXTENSION ::= {
   SYNTAX PreferredSignatureAlgorithms
   IDENTIFIED BY id-pkix-ocsp-pref-sig-algs  }

-- Response Extensions

re-ocsp-crl EXTENSION ::= { SYNTAX CrlID IDENTIFIED BY
                                id-pkix-ocsp-crl }

re-ocsp-archive-cutoff EXTENSION ::= { SYNTAX ArchiveCutoff
                                       IDENTIFIED BY
                                       id-pkix-ocsp-archive-cutoff }

re-ocsp-extended-revoke EXTENSION ::= { SYNTAX NULL IDENTIFIED BY
                                        id-pkix-ocsp-extended-revoke }

-- 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 }
id-pkix-ocsp-pref-sig-algs   OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }

END








<span class="grey">Santesson, et al.            Standards Track                   [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


<span class="h2"><a class="selflink" id="appendix-C" href="#appendix-C">Appendix C</a>.  MIME Registrations</span>

<span class="h3"><a class="selflink" id="appendix-C.1" href="#appendix-C.1">C.1</a>.  application/ocsp-request</span>

   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 document on the
      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 &amp; email address to contact for further information:
      Stefan Santesson &lt;sts@aaa-sec.com&gt;

   Intended usage: COMMON

   Author/Change controller: IETF












<span class="grey">Santesson, et al.            Standards Track                   [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


<span class="h3"><a class="selflink" id="appendix-C.2" href="#appendix-C.2">C.2</a>.  application/ocsp-response</span>

   To: ietf-types@iana.org
   Subject: Registration of MIME media type application/ocsp-response

   MIME media type name: application

   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 document on the
      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 &amp; email address to contact for further information:
      Stefan Santesson &lt;sts@aaa-sec.com&gt;

   Intended usage: COMMON

   Author/Change controller: IETF















<span class="grey">Santesson, et al.            Standards Track                   [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc6960">RFC 6960</a>                        PKIX OCSP                      June 2013</span>


Authors' Addresses

   Stefan Santesson
   3xA Security AB
   Scheelev. 17
   223 70 Lund
   Sweden

   EMail: sts@aaa-sec.com


   Michael Myers
   TraceRoute Security

   EMail: mmyers@fastq.com


   Rich Ankney


   Ambarish Malpani
   CA Technologies
   455 West Maude Ave.  Suite 210
   Sunnyvale, CA  94085
   United States

   EMail: ambarish@gmail.com


   Slava Galperin
   A9.com Inc.
   130 Lytton Ave.  Suite 300
   Palo Alto, CA  94301
   United States

   EMail: slava.galperin@gmail.com


   Carlisle Adams
   University of Ottawa
   800 King Edward Avenue
   Ottawa ON K1N 6N5
   Canada

   EMail: cadams@eecs.uottawa.ca






Santesson, et al.            Standards Track                   [Page 41]
</pre>