Subject: Re: Candidate for moving OCSP to a Draft Standard

From: [email-masked] (Peter Gutmann)
Date: Sat, 16 Mar 2002 16:29:44 +1300 (NZDT)

Juergen Brauckmann <[email-masked]> writes:

>In the ISISMTT stuff there is a similar OCSP extension which is intended to
>allow the server to send the hash of the certificatein question back to the
>client.
>
>The problem with a simple boolean is IMO that it's not sure whether server and
>client are talking about the same certificate.

I gave up on all the strange identifiers which people keep inventing for certs
in PKI protocols and just put an ESSCertID in all my requests (OCSP, CMP, etc
etc), which solves the problem nicely :-).

>If we worry about certificates with a valid signature that may not be issued
>by a CA, than it should be possible for the client to check somehow that the
>server knows not only about a certificate which happen to have an IssuerDN and
>a serialnumber identical to that the client has, but that is entirely
>identical to it. This can be achieved by a server which sends a hash of a
>certificate back to the client, and the client then checking this hash.

That's another way of doing it... I went for the client-supplied-hash because
then the responder can be implemented as a straight lookup in an in-memory hash
table, which is extremely fast and efficient.

>In a normal PKIX way of doing status checking and path validation, you don't
>need to worry about never issued certificates.

You do for CMP, which speculatively issues certs to EEs.

(You also have the problem that if you design a system in which you wish away
 certain hard security problems, you end up in serious trouble if any of those
 problems do ever occur.  I'd rather be paranoid and cover all the angles, even
 the ones which should never occur).

Peter.

---

From: Ambarish Malpani <[email-masked]>
Date: Tue, 19 Mar 2002 14:53:18 -0800

Hi Dave,
     I believe all the requirement states is that CAs MUST allow
for the extension to be included in certs. It doesn't say that
the CA must actually actually put that extension in issued certs.

So the CA software will let you put the extension. You can choose
to issue certs without the extension.

Do you agree?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Tuesday, March 19, 2002 1:16 PM
> To: [email-masked]'
> Subject: Re: Candidate for moving OCSP to a Draft Standard
> 
> 
> 
> Ambarish,
> 
> Section 3.1 of RFC 2560 (unchanged in draft -03) includes the 
> following:
> 
>    CAs that support an OCSP service, either hosted locally or provided
>    by an Authorized Responder, MUST provide for the inclusion 
> of a value
>    for a uniformResourceIndicator (URI) accessLocation and 
> the OID value
>    id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.
> 
> This requirement prohibits local elements (i.e. LAN 
> administrators) from
> operating Authorized Responders, because every LAN URI would 
> have to be
> included in every EE certificate.  There are potentially hundreds or
> thousands of local elements that may wish to operate 
> Authorized Responders
> (although I expect that isn't part of your business model :-), and it
> would be completely impractical to list them all in each EE 
> certificate.
> 
> From a security perspective, the thing that distinguishes a Trusted
> Responder from an Authorized Responder is the existence of 
> the delegation
> certificate described in section 2.6.  AIA is an operational 
> convenience
> that allows clients to find responders without needing additional
> configuration information.  It (AIA) is not security-critical.
> 
> I request that the MUST in section 3.1 be changed to MAY.  Leaving it
> at MUST imposes a severe and unnecessary restriction on the possible
> operational scenarios.
> 
> Regards,
> Dave
> 
> 
> 
> 
> Ambarish Malpani wrote:
> > 
> > Hi Guys,
> >     Here is a candidate for moving OCSP to a Draft Standard. There
> > are no changes in the bytes that go across the wire - basically all
> > clarifications.
> > 
> > A list of all the changes between this document and RFC 2560 are
> > in Appendix D (reproduced here).
> > 
> > I hope we can get to the Draft Standard state before this IETF.
> > 
> > Regards,
> > Ambarish
>