Radio  Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|Proxy_Docs|rfc2560.txt =

page 6 of 13

   UnknownInfo ::= NULL -- this can be replaced with an enumeration

RFC 2560                       PKIX OCSP                       June 1999

4.2.2  Notes on OCSP Responses  Time

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

   The producedAt time is the time at which this response was signed.  Authorized Responders

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. It is necessary however to
   ensure that the entity signing this information is authorized to do
   so.  Therefore, a certificate's issuer MUST either sign the OCSP
   responses itself or it MUST explicitly designate this authority to
   another entity.  OCSP signing delegation SHALL be designated by the
   inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
   extension included in the OCSP response signer's certificate.  This
   certificate MUST be issued directly by the CA that issued the
   certificate in question.

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

   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing use of the id-ad-ocspSigning value as
   described above. They MAY provide a means of locally configuring one
   or more OCSP signing authorities, and specifying the set of CAs for
   which each signing authority is trusted. They MUST reject the
   response if the certificate required to validate the signature on the
   response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in

RFC 2560                       PKIX OCSP                       June 1999

   Additional acceptance or rejection criteria may apply to either the
   response itself or to the certificate used to validate the signature
   on the response.  Revocation Checking of an Authorized Responder

   Since an Authorized OCSP responder provides status information for
   one or more CAs, OCSP clients need to know how to check that an
   authorized responder's certificate has not been revoked. CAs may
   choose to deal with this problem in one of three ways:

   - A CA may specify that an OCSP client can trust a responder for the
   lifetime of the responder's certificate. The CA does so by including
   the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical
   extension. The value of the extension should be NULL. CAs issuing
   such a certificate should realized that a compromise of the
   responder's key, is as serious as the compromise of a CA key used to
   sign CRLs, at least for the validity period of this certificate. CA's
   may choose to issue this type of certificate with a very short
   lifetime and renew it frequently.

   id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

   - A CA may specify how the responder's certificate be checked for
   revocation. This can be done using CRL Distribution Points if the
   check should be done using CRLs or CRL Distribution Points, or
   Authority Information Access if the check should be done in some
   other way. Details for specifying either of these two mechanisms are
   available in [RFC2459].

   - A CA may choose not to specify any method of revocation checking
   for the responder's certificate, in which case, it would be up to the
   OCSP client's local security policy to decide whether that
   certificate should be checked for revocation or not.


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



0.00711703 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)