Subject: RE: OCSP request

From: Al Arsenault <[email-masked]>
Date: Mon, 7 Aug 2000 10:45:45 -0400

The problem with this scheme is that, even if it does help with archiving 
and recovery in the case of CA key compromise, it doesn't help in the 
normal certificate processing operations.

With a certificate signed by a CA, I know that "the CA has vouched for the 
correctness of each of the data items in this certificate", subject to the 
normal discussions on how thoroughly the CA has verified them, yada, yada, 
yada.

With a certificate not being signed, or being signed by the originator, I 
just know that I have a data structure, and I'm not sure about the CA's 
willingness to vouch for those items, until such time as I go fetch the 
signed Merkle tree that pertains and verify it, recursively to where I get 
to a trusted root.  That is, I don't know if I have a complete spoof 
attempt, a corrupted cert, or anything else, until such time as I do the 
"revocation check".

So it seems to me that in the normal processing mode, this proposal is 
actually somewhat *less* efficient than the current scheme, where I can do 
some checks on the cert BEFORE I fetch the CRL or ping the OCSP responder, 
and thus not even bother with revocation checking on things that have 
already failed.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

-----Original Message-----
From:	Irene Gassko [SMTP:[email-masked]]
Sent:	Monday, August 07, 2000 10:20 AM
To:	Stephen Kent
Cc:	[email-masked]
Subject:	RE: OCSP request

Steve,

You are right and I know that currently signatures are mandatory.
But making changes in order to solve serious problems is a part
of the standards process, isn't it? A lot of discussion in this
group is devoted to suggested improvements in the standard. If
making signatures optional can help with CA key change and cert
archiving, would not it be a good idea to allow such usage (as in
MAY)?

Irene

At 05:55 PM 08/06/2000 -0400, Stephen Kent wrote:
>Irene,
>
><snip>
>
>
>>The main idea is to eliminate signatures in certificates and have CA
>>sign a Merkle tree of certificates instead. Then CA key compromise
>>requires the change in that signature (which can be downloaded 
separately)
>>but leaves cards and certificates unperturbed. You can use multiple
>>signatures with different signature algorithms and keep keys on different
>>continents if you wish. This scheme also helps with archiving. And you do 
not
>>need a CRL. It can be used with X.509 certificates, making the signature
>>on a certificate optional, rather than mandatory. Or you can make it
>>an owner's signature instead of a CA's signature.
>
>Irrespective of the merit of the approach to which you allude, the
>result would not be an X.509 cert. Signatures are mandatory, not
>optional, in the format that is the basis of this WG's activity.
>
>Steve

------------------------------------------------------------------------  
----
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	(978) 960-5767
Room 30-2-A31			 e-mail: 	[email-masked]
N. Andover, MA 01845		 fax: 	(978) 960-3240

---

From: Irene Gassko <[email-masked]>
Date: Tue, 08 Aug 2000 08:19:29 -0400

>and thus not even bother with revocation checking on things that have 
This is absolutely correct if you only want to check one individual
certificate,
do not care about the possibility of revocation much and are not worried
about potential CA key compromise. Yes, and also if you trust directories
to tell you truthfully whether they have a particular certificate you are
looking
for. 

If you are checking a number of certificates from the same CA (say, Visa cards)
then you only need to check one signature and a few hashes, which is much
more efficient then checking a signature from every certificate. You can even
check that signature in advance, for example a vendor can do it outside of rush
hours and then only a few hashes need to be computed: this is more efficient
than verifying a signature each time. If your certificate is your credit
card and today
is your shopping day, you can prefetch verification path to speed up
approval for
your purchases (in this case I assume it to be a smartcard, as is common in
Europe). 

Besides efficiency issues there are other properties that a current scheme does
not possess. For example, if a CA key gets silently compromised, and 
a certificate is forged quietly, with the current technology there is no way 
to discover that a certificate is fake. However, in our scheme, in order to 
fabricate a certificate, the root value of the Merkle tree has to be altered, 
which will be too conspicuous to miss. 

And another property. Even though directories are supposed to be untrusted (or
we would not need a CA signature at all), if we are looking for a
certificate, we
are willing to believe that a particular certificate is not in the
directory, on the
directory's say so. Our approach allows you get a get a proof that this
directory
really does not possess a cert you are looking for. No more trust needed for
untrusted directories. 

So, it looks like efficiency really depends on how those certificates are used.

Irene

>>optional, in the format that is the basis of this WG's activity.

----------------------------------------------------------------------------