Subject: OCSP and LDAP

From: Massimiliano Pala <[email-masked]>
Date: Sat, 04 Jan 2003 18:24:23 +0100

Hi all,

it might be an old question but If you can not answer me I really don't know
where to look... Here it is.

We are trying to rebuild our OCSPd backend and one of the possibilities was
to use the LDAP server to store (besides the issued certificates) informations
needed to the OCSPd to build the responses (i.e. at least the status of the
certificates).

Are there RFCs/raccomandations that will help us in using a good schema
for storing this kind of informations and in not making big mistakes ?

Thank to you all for all the work you are doing.

-- 

C'you on the bit stream,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [email-masked]
                                                  Tel.:   +39 (0)59  270  094
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365

---

From: Adam Tresch <[email-masked]>
Date: Sat, 04 Jan 2003 21:45:43 +0100

Massimiliano,

if am i right, then the easyest way to retreive the cert status form the
actual CRL.
You dont need to extand the schema, use only the valid CRL as the source
of the info.
But, in this case, the CA must issue a new crl after each revocation
immediately.

Adam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Massimiliano Pala
Sent: Saturday, January 04, 2003 6:24 PM
To: [email-masked]
Subject: OCSP and LDAP

Hi all,

it might be an old question but If you can not answer me I really don't
know
where to look... Here it is.

We are trying to rebuild our OCSPd backend and one of the possibilities
was
to use the LDAP server to store (besides the issued certificates)
informations
needed to the OCSPd to build the responses (i.e. at least the status of
the
certificates).

--

C'you on the bit stream,

	Massimiliano Pala

--o-----------------------------------------------------------------------
--
Massimiliano Pala [OpenCA Project Manager]
[email-masked]
                                                  Tel.:   +39 (0)59  270
094
http://www.openca.org                            Fax:    +39   178  221
8225
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222
365

---

From: "Ambarish Malpani" <[email-masked]>
Date: Sat, 4 Jan 2003 14:54:52 -0800

Hi Massimiliano,
    You should seriously consider having your responder work off a
CA's CRL, rather than trying to access its database directly.
There are a set of reasons why this is a good idea. Here are are
few (in no particular order):

- CA independence (might not be important for you)
- Helps auditability of the VA
- Allows better control over replication (where you don't need
	to rely on LDAP replication - most CAs won't want to
	replicate the rest of their LDAP data)
- Better performance - can keep the revocation data in memory and
	respond from memory - won't need to also have a LDAP lookup

Hope this helps,
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [email-masked]
http://www.malpani.biz

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Massimiliano Pala
> Sent: Saturday, January 04, 2003 9:24 AM
> To: [email-masked]
> Subject: OCSP and LDAP
> 
> 
> Hi all,
> 
>                                                   Tel.:   +39 
> (0)59  270  094

---

From: Massimiliano Pala <[email-masked]>
Date: Sun, 05 Jan 2003 11:26:34 +0100

Hi all,

I am quoting one answer for all as it seems them all share the same
vision.

> CA's CRL, rather than trying to access its database directly.

Well, our approach is towards the usage of an off-line CA so my
problem is that usually the CRL could be not up to date to the latest
status of the certificate (let's say a user request its certificate
to be revoked, from this time to the time the CRL will be issued
there could be a time gap during which I want the certificate
to be reported as invalid -- let's say with the onHold reason).

For this reason I need some more information rather than the only
CRL.

There is another question about this approach: if the client request
the status of one certificate with a serial that is not within the CRL,
should not the responder check for it (i.e. its existance?) and
if it does not have informations about it return an "unknown"
answer ?

> - CA independence (might not be important for you)

This is one of the most important reason that drives my questions.

> 	respond from memory - won't need to also have a LDAP lookup

I know, indeed we actually use a single file generated from the
certificates' db that is read by the responder and kept in memory,
but as the number of certificates grows and in case of a spawning
process approach used memory grows and performance drop.

IMHO I guess I need the latest CRL and the latest CSL (list of
"suspended" certificates -- i.e. certificates that for any reason
"could" be revoked but them are not, yet).

 From your answers I guess there is no reference on how to store
this information onto LDAP.

Do you think the best method could be storing a single pkcs7 file
with all the information into the main ca entry onto LDAP (and
when the CA updates the information, the OCSP will update its
internal data) or it is best having a field in the user's entry ?

Thanks to all of you for your answers.

-- 

C'you,

	Massimiliano Pala

---

From: "Simon Tardell" <[email-masked]>
Date: Mon, 6 Jan 2003 12:00:28 +0100

> Well, our approach is towards the usage of an off-line CA so 
> my problem is that usually the CRL could be not up to date to 
> the latest status of the certificate (let's say a user 
> request its certificate to be revoked, from this time to the 
> time the CRL will be issued there could be a time gap during 
> which I want the certificate to be reported as invalid -- 
> let's say with the onHold reason).
> 
> For 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.
 
> There is another question about this approach: if the client 
> request the status of one certificate with a serial that is 
> not within the CRL, should not the responder check for it 
> (i.e. its existance?) and if it does not have informations 
> about it return an "unknown" answer ?

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.
 
Simon

Simon Tardell, cell +46 70 3198319, [email-masked]

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 06 Jan 2003 13:07:44 +0100

Simon Tardell wrote:
[...]r this reason I need some more information rather than the only CRL.
> 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 ?

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.

[ unknown ]
> least if you have the wrong kind of client). The OCSPv2 draft has a

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.

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.

-- 

C'you,

	Massimiliano Pala

---

From: "Simon Tardell" <[email-masked]>
Date: Tue, 7 Jan 2003 12:12:53 +0100

> 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 
> 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