Henry B. Hotz wrote:
Stefan Santesson <stefan(_at_)aaa-sec(_dot_)com> 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