Henry B. Hotz wrote: > > Stefan Santesson <stefan@xxxxxxxxxxx> wrote: > > > > Nothing has changed in this regard. > > > > The good response is pretty clear that it by default provides information > > that the cert is not on a black-list (is not know to be revoked). > > However, it is also made clear that extensions may be used to expand this > > default information about the status. > > > > This is how it always have been, and still is in RFC 256bis. > > So a non-issued cert may be "good". An rfc2560 OCSP responder might return "good" status for a "not issued" cert. That is listed as a caveat in the rfc2560 description for "good". > > > The revoked response simply means that the certificate is revoked. > > Combined with the new extension, it MAY also be used for non-issued certs. > > So a non-issued cert may be "revoked". Yes. That is already possible and fully conforming with rfc2560. It is just not explicitly standardized how to do it. IMO it is preferable to standardize how to do it consistently, rather than "letting a thousand flowers bloom" on the significantly underspecified rfc2560. > > > It's really as simple as that. > > I would have thought that what was simple was to say a non-issued cert > was "unknown", since it's neither known-good, nor known-revoked. That is another permissible response for an rfc2560 OCSP responder. But there is more to consider than just what is permissible by the spec, and that is client behaviour of an installed base that has grown over more than a decade. If a non-marginal fraction of the installed base will either fallback to CRL checking or do a soft-fail (assume good) upon receiving "unknown" status, then this choice of response might not be very sensible. > > Is there any collection of extensions which will allow an RP to know, > for sure, what value will be returned for a never-issued cert? The two MUSTs at the end of section 2.2 in rfc2560bis-18 plus the MUST contain the responseExtension from section 4.4.8. To facilitate recognizing the revocationTime from the end of section 2.2 rfc2560bis-18, it really ought to be written as UTCTime! from (-18): - MUST specify the revocationTime January 1, 1970, and; to (example): - MUST specify the revocationTime "700101000000Z" > > > It is only the discussion on this list that is confusing and that has > > managed turn something really simple into a complicated debate. > > What *I* find confusing is the apparent degree of belief that it is > possible to improve 2560 and simultaneously to maintain backward > compatibility. That should only be possible if there are some > previously-ignored extensions which alter the semantics of the > information --- effectively creating a version 2 protocol. As far as the spec rfc2560 is concerned, this is trivial from a formal perspective since there is hardly any client behaviour defined in rfc2560. But the absence of definition of client behaviour in rfc2560 also limits what kind of behaviour can be added now. In particular, mandating specific behaviour (MUST rather than SHOULD) or prohibiting specific behaviour (MUST NOR rather than SHOULD NOT) is going to be a backwards incompatible change, and unless there is a really convincing rationale for addition of MUST / MUST NOT behaviour, this will result in a conflict with rfc2119 Section 6! http://tools.ietf.org/html/rfc2119#section-6 > > I don't find the claim that nothing has changed helpful. The claim that "nothing has changed" is provably untrue as long as the imperative MUST for using the Extension in section 4.4.8 of rfc2560bis-18 persists. > > What I would find helpful, and what I think some people really would > like, is for OCSP to be able to provide white-list information in > addition to the previous black-list information. When I read through > 2560bis, I could not tell if there was an extension which would allow > an RP to tell if "good" actually meant a cert was on the white list > (and to know the responder has the white list), or merely not on the > black list. (Yes, I'm repeating myself. Am I making more sense, > or just wasting everyone's time?) You're correct, a white-list confirmation is not in rfc2560bis. There seem to be white-list confirmations in current use as OCSP extensions for some "Qualified Electronic Signature" (QES) usage scenarios, but the PKIX WG constituency in favour of the rfc2560 defects prevented that any existing solutions would be adopted for rfc2560bis. The technical issue with white-listing is, that the original claim about the OCSP protocol properties is technically wrong. rfc2560 OCSP, just like CRLs, is _not_ about the status of certificates, it is purely about the status of certificate serial numbers. In order to obtain a technically sound white-listing response, the "good" response will have to include a certificate hash in an OCSP singleResponse extension, not just a mere serial number. And that seems to be the solution adopted by some existing "QES" usage scenarios. Since such solutions exist, adopting one of those in rfc2560bis should be technically trivial. But... this is PKIX WG, and my impression over the past 2 years following this WG is that _nothing_ is trivial in PKIX. I remember that fruitless discussion about an rfc5280 CRL processing defect. A related, more severe defect exists in X.509 08/2005. Curiously, the X.509 defect has already been sensibly fixed in X.509 11/2008. However, it turned out to be impossible to make PKIX adopt the X.509 11/2008 fix for rfc5280bis. During a hot debate, a significant momentum even emerged to adopt further breakage from X.509 08/2005 instead the fix from X.509 11/2008, and it took some effort to prevent the additional breakage from getting rough consensus within PKIX WG... -Martin