Re: operational protocols

Mike Smith <mfsmith@zionsbank.com> Mon, 07 April 1997 14:07 UTC

Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA25452; Mon, 7 Apr 1997 07:07:53 -0700
Received: from zionsbank.com by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf-pkix@tandem.com> id HAA25449; Mon, 7 Apr 1997 07:07:51 -0700
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 07 Apr 1997 08:04:54 -0600
Message-Id: <s348aaa6.057@zionsbank.com>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 07 Apr 1997 08:04:45 -0600
From: Mike Smith <mfsmith@zionsbank.com>
To: housley@spyrus.com
Cc: Stefan.Hoeben@esat.kuleuven.ac.be, ietf-pkix@tandem.com
Subject: Re: operational protocols
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline

So, a directory needs to rely on the CAs to provide a CIL if the CAs don't provide them with all of the certificates they issue?  If the CA doesn't provide the certs, why would they provide a CIL?  Why would they provide a CIL if they issue 90% private certs, 10% public.

Lastly, why would someone wish to use a directory it can not trust?  Obviously, these directory services will be operating in a different trust model than the repository model defined in Utah. Possibly, they will be operating under different financial structures as well.

Michael

>>> Stef Hoeben <Stefan.Hoeben@esat.kuleuven.ac.be> 04/07/97 02:21AM >>>

Russ:

> I do not see how the CIL can be usefully used as a certificate
> extension.
> Please provide a more detailed explaination.

Normally, a CA gives its certs and CRL to a Directory, which is
normally no _Trusted_ Third Party. Because the certs and CRL are
signed by the CA, the Directory can't mess these up. But the
Directory can answer on a request for a certificate: 'I don't have
it, the CA never issued it'
So if a Directory really doesn't have a certificate, it must prove
it to the user. This can be done by the CIL: a list with the serial
numbers (or other ID's) of all certificates the CA has given to the
Directory, and this list must be signed by the CA.
So if a user requests a cert which the Directory didn't have, the
Directory _must_ give the CIL which the user can check so verify
the requested cert isn't in the CIL.
=> The only problem looks: how to tell the users they will get a
   CIL instead of a 'I don't have that cert' if they ask for a
   non-existing cert.
   I don't think you can put it in a private extension of the
   certficate, because that's exactly what a nasty Directory
   won't give...


> How is LDAP different than any other access to a certificate and CRL 
> repository?  I do not see what makes the CIL important in the LDAP 
> environment more than any other environment (like FTP or full DAP).

Oops, mistake: LDAP isn't different. It's the same for the other
protocols. Sorry for the confusion.


> Also, does the use of distributed, replicated Directories help solve your 
> concern? If not, how about the use of more than one distriution mechanism, 
> say FTP and LDAP.

You mean some independent directories with the same info? Sure, that would
help, but isn't that expensive and impractical in most cases?


Also, please allow me to ask my questions again ...

 - In the abstract, it looks like only the OCSP protocol 
 can be use for online checking. But this is also possible
 with the LDAP protocol, isn't it? Isn't the only difference 
 that LDAP gives the whole certificate or CRL, while the 
 OCSP only gives the status?
 
 - Do you put the OCSP protocol _in_ an HTML file? Do you 
 have to define new tags?  Are there examples avaiable 
 somewhere? Do Netscape and Microsoft have to put this 
 procotol in their browsers? (Sorry for the dumb questions.)


Stef