Subject: RE: OCSP request

From: Irene Gassko <[email-masked]>
Date: Thu, 03 Aug 2000 13:08:14 -0400

At 11:46 AM 07/27/2000 +0200, Simon Tardell wrote:
>Denis,
>
>> > This is not sufficient for systems that must be  robust/tolerant against
>CA
>> > key compromise or such things. 
>> 
>> Key compromise is an exceptional event (that should not happen, but
>> might happen) that must be addressed under a disaster recovery plan
>> (i.e. revoke the CA whose key has been compromised in all the
>> certificates that has been issued for that CA by other CAs). 
>
>I see the disaster, but I don't see the recovery in this.
>
>As I see it, the problem the German model tries to tackle is that a CA which
>has issued lots of certificates to the public (say millions) gets it keys
>compromised somehow. Time-stamping services secure documents signed before
>this moment, but there is another problem. Millions of germans are now
>unable to go about their daily business. Potentially the German economy
>grinds to a halt while the CA reissues millions of smart cards. Obviously
>this would be a very bad thing. I'd hate to know that this scenario has not
>been prepared in advance. Since the end-user keys did not get compromised
>they can still be trusted. What is a problem is the linkage between the
>holder and his keys, embodied in the certificates. 

Actually, such a scenario can be avoided. We suggest a possible solution
in our paper which my coauthor put on his web site 

<http://www.bell-labs.com/user/philmac/research/cert-pkcfinal.ps.gz>http://
www.bell-labs.com/user/philmac/research/cert-pkcfinal.ps.gz

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.

Irene

----------------------------------------------------------------------------
-------------------------------------------------------
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: Stephen Kent <[email-masked]>
Date: Sun, 6 Aug 2000 17:55:17 -0400

Irene,

<snip>

>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

---

From: Irene Gassko <[email-masked]>
Date: Mon, 07 Aug 2000 10:19:54 -0400

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

Irene Gassko			 Bell Laboratories		http://www.lucent.com

---

From: Richard Levitte <[email-masked]>
Date: Mon, 07 Aug 2000 16:35:01 +0200

I think we're into a little bit of nit-picking here.  On this list, it's
probably not possible to suggest a change of an ITU (do I remember
correctly?) standard, such as X.509.  Talking about changes to an RFC
would probably prove a bit more fruitful.  In this case, you probably
mean RFC2459 or whatever draft that updates it.

However, if I understand correctly, the meaning of RFC2459 is to be as
close as possible to X.509, which makes the RFC bound to X.509,
therefore making incompatible changes a bad thing.

Furthermore, if making the signature OPTIONAL (which I assume would be
the result), I'm sure there would be changes in the ASN.1 coding (be it
BER, DER, or whatever) that doesn't allow correct interpretation of
older certificates.  Don't take my word for it though, I haven't studied
the possible effects enough to actually know.  This is just a hunch
(sp?)...

-- 
Richard Levitte			!!! New cell phone number !!!
[email-masked]

/* You might enjoy viewing the complete vCard */

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Aug 2000 21:07:19 -0400

Irene,

>archiving, would not it be a good idea to allow such usage (as in

The charter of this WG is to profile X.509, which includes the 
syntax, processing, and underlying models for PKI.  Interoperability 
is a primary thrust of the work. The change you suggest would not be 
backward compatible with X.509, or with any of the previous PKIX 
syntax, so it's hard to imagine making such a change.  Even a MAY 
would break existing implementations.

Steve

---

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

Steve,

Thanks a lot for this clarification.

In fact, making signatures optional is not needed for our scheme
to work, I only mentioned it for efficiency reason. Like Richard
and Tony suggested it may work independently without disturbing
current implementations. It can provide a fallback support for CA
key change, for example, especially if this change is a result of
a private key compromise. Actually, I mentioned our solution in
the course of an archiving discussion, as a way to protect against
keys being discovered and signature schemes being broken in
the future.

Irene

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 08 Aug 2000 14:47:54 +0200

Irene,

> a private key compromise. Actually, I mentioned our solution in

Simple non-technical question. Is -to your own best knowledge- this
scheme patented ?

Thanks,

Denis