Subject: [pkix] draft-pinkas-rfc2560bis-00

From: [email-masked]
Date: Tue, 28 Aug 2012 18:19:04 +0200

A new Internet-Draft is available from the on-line Internet-Drafts 
directories.

    Title         : X.509 Internet Public Key Infrastructure Online 
Certificate Status Protocol - OCSP
    Author(s)     : D. Pinkas
    Filename      : draft-pinkas-rfc2560bis
    Pages         : 41 
    Date          : Aug. 27, 2012 
 
   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 document obsoletes RFC 2560 and RFC 6277.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader 
implementation 
to automatically retrieve the ASCII version of the Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bis> 

A few explanations about the content of draft-ietf-pinkas-rfc2560bis-00.

25 changes are indicated at the beginning of the document.
I will only mention a few of them:

A - Explanations were missing to describe:

     - the building of a request by an OCSP client,
     - the processing of a request by an OCSP server, 
     - the building of a response  by an OCSP server, and 
     - the processing of a response by an OCSP client.

These explanations have been added.

B - Explanations were missing to  address CA key rollover and OCSP key 
rollover.
     These explanations have been added.

C - Backwards compatibility has been addressed in the following way:

      1) An OCSP response by be signed either by a CA or by an OCSP 
Responder.

      2) Besides local configuration settings which are optional, only two 
cases 
        SHALL be supported by OCSP clients (and thus OCSP servers) as 
explained below.

       The key to be used to verify a SingleResponse (within a 
BasicOCSPResponse) MUST:

          (1) either be the same key that the one used to sign the target 
certificate,

          (2) or be the public key from an OCSP responder that is 
contained in an OCSP certificate 
               that has been signed by the same key that the one used to 
sign the target certificate.
    . 
The text allows to use the same general processing for a few other cases, 
since "escape" 
sentences are provided to allow for these other cases, but only using 
"local configuration settings".

This means in particular that the Identrust model may be supported and 
that the "several many cases" 
that were detailed in the annexes from draft -04 from David Cooper and 
Stefan Santesson 
(but which were not interoperable with most current implementations) can 
take benefit of the description 
of the general processing.

Denis