PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Radio  Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|Proxy_Docs|rfc2560.txt =

page 3 of 13



   The response "unauthorized" is returned in cases where the client is
   not authorized to make this query to this server.

2.4  Semantics of thisUpdate, nextUpdate and producedAt

   Responses can contain three times in them - thisUpdate, nextUpdate
   and producedAt. The semantics of these fields are:

   - thisUpdate: The time at which the status being indicated is known
                 to be correct
   - nextUpdate: The time at or before which newer information will be
                 available about the status of the certificate
   - producedAt: The time at which the OCSP responder signed this
                 response.

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








 
RFC 2560                       PKIX OCSP                       June 1999


2.5  Response Pre-production

   OCSP responders MAY pre-produce signed responses specifying the
   status of certificates at a specified time. The time at which the
   status was known to be correct SHALL be reflected in the thisUpdate
   field of the response. The time at or before which newer information
   will be available is reflected in the nextUpdate field, while the
   time at which the response was produced will appear in the producedAt
   field of the response.

2.6  OCSP Signature Authority Delegation

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. A certificate's issuer
   explicitly delegates OCSP signing authority by issuing a certificate
   containing a unique value for extendedKeyUsage in the OCSP signer's
   certificate. This certificate MUST be issued directly to the
   responder by the cognizant CA.

2.7  CA Key Compromise

   If an OCSP responder knows that a particular CA's private key has
   been compromised, it MAY return the revoked state for all
   certificates issued by that CA.

3.  Functional Requirements

3.1  Certificate Content

   In order to convey to OCSP clients a well-known point of information
   access, CAs SHALL provide the capability to include the
   AuthorityInfoAccess extension (defined in [RFC2459], section 4.2.2.1)
   in certificates that can be checked using OCSP.  Alternatively, the
   accessLocation for the OCSP provider may be configured locally at the
   OCSP client.

   CAs that support an OCSP service, either hosted locally or provided
   by an Authorized Responder, MUST provide for the inclusion of a value
   for a uniformResourceIndicator (URI) accessLocation and the OID value
   id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

   The value of the accessLocation field in the subject certificate
   defines the transport (e.g. HTTP) used to access the OCSP responder
   and may contain other transport dependent information (e.g. a URL).








 
RFC 2560                       PKIX OCSP                       June 1999


3.2  Signed Response Acceptance Requirements

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

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

   2. The signature on the response is valid;

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

   4. The signer is currently authorized to sign the response.

=3=

1|2| < PREV = PAGE 3 = NEXT > |4|5|6|7|8|9|10|11|12|13

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 

0.012536 wallclock secs ( 0.00 usr + 0.01 sys = 0.01 CPU)