Hi Guys,
    Here is a candidate for moving OCSP to a Draft Standard. There
are no changes in the bytes that go across the wire - basically all
clarifications.

A list of all the changes between this document and RFC 2560 are
in Appendix D (reproduced here).

I hope we can get to the Draft Standard state before this IETF.

Regards,
Ambarish


Appendix D. Changes

   This section contains the differences in this document from RFC 2560

   - Mention Appendix D in Section 1 and added an appendix D.
   - Added a paragraph in Section 1 equating a client with a requestor and
     server with responder
   - Section 2.2 - clarified the explanation of good, revoked and unknown
   - Added Section 2.8 requiring clients and responders to support HTTP
   - Added a note at the end of section 3.2, which allows a client to
     accept a response that provides statuses for only some of the
     certificates requested.
   - Clarified the issuerKeyHash in Section 4.1.1
   - Added "DER encoding of the" in the third paragraph Section 4.1.2
   - Section 4.2.1 - clarified that the signature is on the DER encoding
     of tbsResponseData (and not its hash)
   - Section 4.2.1 - specified the use of the certs field in
     BasicOCSPResponse
   - Section 4.2.1 - clarified how you compute KeyHash when providing
     the ResponderID byKey.
   - Section 4.2.2.2 - removed an extra quote in point 3
   - Section 4.3 - Made RSA mandatory. Also changed the references to
     point to the appropriate documents. Added the references to the
     References section
   - Section 4.4.1 - Clarified that a nonce in the request MUST be
   - included in the response for the response to be trusted.
   - Appendix A - A.1.1. - Got rid of support for GET - not sure that
     anybody does it. It is also unclear how a server would tell a
     client to ever use GET in the URL specified in the AIA
   - Add the module tag for the ASN.1 in OCSP
   - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
     Certificate OPTIONAL in the ASN.1 defintions. The avoids the
     ambiguity of whether the optional sequence may be present, but
     with 0 elements. This was done by definining a new element called
     Certificates, which is used. Look at the defintion of both
     Signature and BasicOCSPResponse.
   - Clarified the meaning of nextUpdate being absent (Section 2.4)
   - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
     correct OID - id-kp-OCSPSigning
   - Clarified criteria for response acceptance (Section 3.2)
   - Added a line in Section 5 indicating that nonces can be used to
     prevent prevent attacks using replays of precomputed responses
   - Added a paragraph in Section 5 requiring nonces to be unique for
     replay protection

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  ambarish@valicert.com
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043