Subject: [pkix] Making OCSP status flexible without creating a false sense of security

From: "Piyush Jain" <[email-masked]>
Date: Thu, 8 Nov 2012 10:32:02 -0800

I appreciate the point that current text describing the status in OCSP is
too restrictive and does not allow the responder to deal with situation
where 'revoked' response seems to be a better choice than either 'good' or
'unknown' response. However, my understanding (based on a discussion with
one of the original authors of OCSP long time ago) has always been that OCSP
status only conveys revocation status and response extensions convey
additional assertions.

Many folks on this forum believe that negative assertion should be conveyed
as a revoked status, primarily because millions of clients don't handle
unknown correctly and consider 'good' to be more than 'not revoked'.

While I do not believe that accommodating clients who do not follow the
standard correctly, is a reason to change the standard, I believe that
current text describing the revoked status is rigid. There is a way to
address this without endorsing the method adopted by CAB forum to deal with
compromised CAs, which IMO is inherently insecure. 

This is the text from last version of the draft 6:

"The "revoked" state indicates that the certificate has been revoked (either
permanantly or temporarily (on hold)). This state SHOULD also be returned if
the responder knows that the requested certificate has never been issued.
Note that the receiver of a response may have to	consult out-of-band
knowledge, or information in an extension defined outside of this standard,
to know whether a particular responder has knowledge about whether a
requested certificate has been issued or not and whether it responds "good"
or "revoked" to a status request for a non-issued certificate."

While the above proposal attempts to provide flexibility in terms of what
responder can return, it also introduces "non-issued" which is confusing
given that until now signatures have been considered proof of issuance.
Also, it just addresses one case of negative assertions. There may be other
scenarios where a negative assertion is required. So if this forum is
inclined to change the semantics of 'revoked' from indicating just the
revocation status to indicating any negative assertion, the above proposal
becomes limiting. Here is an alternative text that attempts to address these
limitations, assuming that WG is inclined toward changing the meaning of
revoked: 

"The "revoked" state indicates that the certificate has been revoked (either
permanently or temporarily (on hold)). This state MAY also be returned to
indicate that the certificate should not be trusted by the relying party,
even if it is not explicitly revoked by the CA". How the responder makes
this determination is beyond the scope of this document."

I believe that this alternative text allows flexibility to CAB forum without
creating the impression that OCSP can be an alternative to signature
checking. It puts the onus on CAB forum to explain the security (or lack
thereof) of their adopted methods.  Also, it allows implementations to use
revoked for any negative assertion instead of limiting its use for just one
kind of 'bad' certificate. 

Off course, we'll still need to provide guidance on what the
revocationReason and revocationTime values should be in such cases.

-Piyush

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 08 Nov 2012 19:54:21 -0400

The Minutes from the PKIX meeting in Atlanta are posted.

http://www.ietf.org/proceedings/85/minutes/minutes-85-pkix

Please let me know if something is wrong or missing.

/Stefan