[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Candidate for moving OCSP to a Draft Standard
Ambarish,
Three remarks:
1) It would be interresting to say what happens in case an OCSP request
is made after the end of the validity period of a certificate.
nextUpdate is currently defined as: "The time at or before which newer
information will be available about the status of *the* certificate".
If the certificate has expired, such information about *that* certificate
will never be available. Anyway, since the server does not necessarily have
access to the end-entity certificate, then it does not even know that the
certificate has expired.
A more appropriate definition about nextUpdate would be: "The time at or
before which newer status revocation information will be available from the
CA which has issued the certificate".
In addition, some guidance, in particular in the security considerations
section would be useful. Here is some tentative text:
An OCSP response does not indicate that the certificate is in its validity
interval. So, it is up to the clients to make sure that thisUpdate is
within the validity period of the end-entity certificate, which means that
clients MUST be able to parse the end-entity certificate to interpret the
validity period.
2) The "good" status has always been misleading. The text says:
The "good" state indicates that the certificate has not been revoked.
According to this definition, which is correct, an unambiguous status would
better be called: "not revoked" rather than "good".
3) A typo (suppress one "is"):
It does not indicate that the certificate was ever issued,
is or is in its validity interval.
should be changed into:
It does not indicate that the certificate was ever issued,
or is in its validity interval.
Denis
> 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@xxxxxxxxxxxx
> 339 N. Bernardo Ave. http://www.valicert.com
> Mountain View, CA 94043
>
> ----------------------------------------------------------------------------
> Name: OCSP-draft-03.txt
> OCSP-draft-03.txt Type: Plain Text (text/plain)
> Encoding: quoted-printable