RE: OCSP Questions

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

Hi Denis,

>----------
>From: 	Denis Pinkas[SMTP:D.Pinkas@frcl.bull.fr]
>Sent: 	Tuesday, November 18, 1997 8:37 PM
>To: 	Carlisle Adams
>Cc: 	'ietf-pkix@tandem.com'
>Subject: 	Re: OCSP Questions
>
>> Hi Denis,
>> >Basically the complication comes from the fact that the trust conditions
>> >must be indicated, so that the path validation can take place.
>> 
>> Does this argument really hold any water?  Is there really a defensible
>> reason why you need trust conditions for a path but not for a single
>> certificate?  
>
>There is a reason. For a single certificate you ask to a representative
>of the CA. The trust conditions are not necessary: you simply ask
>whether the certificate is or is not revoked. I assume that the naming
>constraints are checked locally, not by the server (this is the current
>approach of the OCSP). For a chain, you ask to a trusted verifier (not a
>representative of a CA) and thus you need to indicate your trust
>conditions, this includes trust points and naming constraints.

This argument makes sense until you see the flaw:  "For a single
certificate you ask to a representative of the CA....  For a chain, you
ask to a trusted verifier (not a representative of a CA)".  This assumes
that the OCSP responder (for the single certificate case) will *always*
be the representative of a CA.  But the current draft is written so that
the OCSP responder can be an arbitrary entity with its own certificate
(i.e., a trusted verifier).  If this is the case, then you need to
specify trust conditions whether the request is for a single certificate
or for a chain.

Now Mike said recently that he thought the non-CA case was perhaps too
complicated, so maybe he will remove this possibility from the draft (so
that an OCSP responder is always a representative of a CA).  But does it
actually make sense to force every CA provider in the IPKI to also build
an OCSP responder?  (Note that if even one CA provider doesn't do this,
then you have certificates whose status can't be checked, so the whole
point of this protocol starts to fall apart).  Does it not make more
sense to allow the notion of trusted verifiers, so that somebody that
wants to build such a box can do so (independently of any particular CA)
and service a (large or small) segment of the IPKI?  But trusted
verifiers necessitates the input of trust conditions...


--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
--------------------------------------------