RE: OCSP and LDAP

["Simon Tardell" <simon@xxxxxxxxxx>]

> Simon Tardell wrote:
> [...]r this reason I need some more information rather than 
> the only CRL.
> > 
> > 
> > No, if you want to remove the latency in the system that is 
> related to 
> > the issuance interval of your CRL, then you should issue CRLs 
> > immediately as the revocation occurs.
> 
> But this, in some environment it is not possible. Let's say 
> the CA is in a timed controlled access, unavailable from 8pm 
> to 8am (for different reasons, i.e. security, lack of 
> personnel, etc.. ) and a user asks for revocation at 9pm, 
> should we let the certificate being reported as valid till 8am ?

Not necessarily. Just because the staff is in bed, it doesn't mean that
the CA can't issue deltas with onHold in the meanwhile. It achieves the
same thing, except two things:

1/ You don't introduce an extra directory which --
   --would have to be sufficiently understood in order not to compromise
the security of the system as a whole
   --would not be interoperable with anyone elses CA (private schema)
2/ You don't introduce another source of authority beside the CA.
Although it is the business idea of a wellknown company, many believe
the the final word on what certificate is valid and what is not lies
with the CA...

> For this reason I need some additional information, my 
> question was about the presence of a standard describing 
> where to store them onto LDAP and if, to you, it could be 
> better storing them on a per certificate basis or in a single 
> entry in the main organization entry.

The latter describes a CRL...
 
> [ unknown ]
> > No. There is an unclear wording in RFC2560 that might lead the 
> > thoughts in that direction. "unknown" means that the OCSP 
> is unable or 
> > unwilling to answer the revocation query (because it 
> doesn't know the 
> > CA, or because it doesn't have up to date revocation information or 
> > whatever). A logical reaction to an "unknown" response is to go to 
> > some other OCSP responder that might be better connected for the 
> > moment. If you confuse the meaning of "unknown" to be an assertion 
> > (that the certificate was indeed never issued) then that 
> availability 
> > feature breaks down (at least if you have the wrong kind of 
> client). 
> > The OCSPv2 draft has a better wording.
> 
> Quoting the RFC2560 << The "unknown" state indicates that the 
> responder doesn't know about the certificate being requested. 
> >>. I was not saying that the "unknown" means that the 
> certificate has never being issued, anyway how could the 
> responder know which certificates have been issued ? In this 
> case the responder can';t be sure about the validity of a 
> certificate and it should, to me at least, therefore return 
> an "unknown" status.

This was not the intention, and the text has been refrased for the draft
of OCSPv2:
"
   This specification defines the following definitive response
   indicators for use in the certificate status value:

   -- good
   -- revoked
   -- unknown

   The "good" state indicates that the certificate has not been
   revoked. It does not indicate that the certificate was ever issued,
   or is in its validity interval.

   The "revoked" state indicates that the certificate has been revoked
   (either permanently or temporarily (on hold)).

   The "unknown" state indicates that the responder does not know, or
   is unwilling to tell, the requestor the status of the certificate. A
   client may be able to get a definitive response later, or at another
   responder.

   Response extensions may be used to convey additional information on
   assertions made by the responder regarding the status of the
   certificate such as positive statement about issuance, expiry, etc.
"

>From this is it is quite clear that the base query is about revocation,
and that the answer to the question "has this neverissued certificate
been revoked?" is "no".

The interpretation you are suggesting has been discussed before at great
length in this group, and I hesitate to regurgitate it. 

However, it is possible to put a question (and corresponding answer)
about issuance into an extension. The question is possibly, why? What
risk is it you are trying to cover for? And, is there perhaps already
another, less magic, mechanism to handle it?
 
> Because of these considerations I think the OCSP reponder 
> needs additional data besides the only CRL(s), although I 
> know that this is a fast way of having it working but this 
> works only when the CRLs are immediately (in the same second) 
> issued after certificate revocation and this does not work in 
> environment when some human interaction (for example verification).
> 
> It seems, to me, just translating the CRLs in another format 
> without adding a real improvement to the validating 
> process... I think the OCSP to be more useful than this.

Adding is ok, but altering is a no-no. If different implementors have
different interpretations of the base query, then clients and servers
from different vendors will not interoperate.

Simon

Simon Tardell, cell +46 70 3198319, simon@xxxxxxxxxx