Subject: RE: CDP in self signed root CA

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 6 Dec 2002 09:48:57 -0800

Hi Phillip:
 
I do not know exactly what Ron Rivest said and in what context, but
verifying a self-signed certificate against a CRL whose signature is
verified using the same public key as the one in the certificate is
useless.  All it does it give you false sense of security.  Granted, if
everyone behaved, you can revoke the trust anchor this way.
If you ever see the CRL you mark the trust anchor as irevocably
compromised.
 
I believe that Ron presented a paper on the revocation issue alone at
one of the Financial Crypto conferences. He also presented it at his
reading group. 
However, most likely need to prematurely revoke a trust anchor is
because of key compromise and a self-signed CRL will not help with that
since the person who compromised your key will also issue a CRL that
does not contain the trust anchor. 
You assume a single attack model in which the attacker can prevent all
messages from reaching the observer and has compromised the key in fact.
 
There are plenty of administrative reasons why one might want to
permenently wind up a CA. For example imagine that someone made
significant progress in factoring. One can imagine circumstances in
which it might be considered prudent to wind up the extant 1024 bit CA
roots now that 2048 bit CA roots are widely deployed.
 
There are plenty of industry association roots that have been wound down
for various reasons. Open up old copies of Internet Explorer and you
will find a slew of CA roots, many still valid  which were never used
for any purpose at all.
 
The only reasonable argument for not mandating the check is that the
cost overhead of doing so is considerable, the benefits small when one
considers the probability of compromise. I assert that that is a policy
issue that does not properly lie within the consideration of the group.
Now, to the practical aspects of X.509 and PKIX.  I think the folks who
helped architect X.509 and PKIX have a lot of security savvy and they
see that there is not cryptographic security to the self-signed trust
anchors (as illustrated above).   
If X.509 and PKIX are so great then how come 98% of the Internet users
still don't encrypt their mail with it?
 
Sorry arguments from authority cut no ice with me until you have solved
the problem completely and deployed substantially. I don't think anyone
wants to let X.509 go the same way as the failed directory architecture
it was once a part of.
 That is why both X.509 and 3280 DO NOT process self-signed certificate
in the certification path.  It primes the pump for the path validation
engine by providing the following: trust anchor DN, trust anchor digital
signature algorithm OID, trust anchor public key, and public key
parameters (if required).  That is all.  The rest of the checks a RP
client does on the trust anchors is all for the birds. 
If this is so it should be immediately apparent when reading the
specification.
 
Your argument that the root is not a part of the trust path does not
actually address the issue. The fact that a root does not require
validation as a part of trust path validation does not imply that it
should not be validated as part of trust root validation.
 
            Phill
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Thursday, December 05, 2002 11:48 PM
To: [email-masked]
Subject: RE: CDP in self signed root CA

I would like to see reference made to the precise wording in the spec
that people believe lead to these conclusions. I would consider the lack
of very explicit directions on this point to be a bug in the spec.

A self signed CA has a signer. The fact that the signer is itself means
that the only deduction that you can draw from the certificate is that
the holder of the private key asserted the contents to be true at some
time.
 
If a CRL exists that revokes the self signed CA one should logically
infer from that that the holder of the private key asserts that the
contents are false.
 
There is a CA that signs a self signed cert, the fact that it is the
subject does not change that.
 
Say what you like about a self signed cert, a self signed CRL is the
only piece of data in the entire PKI constellation that can be
absolutely considered trustworthy regardless of your trust model. Ron
Rivest proposed self signed revocation lists as the revocation mechanism
for SDSI for that reason.

        Phill

-----Original Message-----
From: Roger Younglove [mailto:[email-masked]]
Sent: Thursday, December 05, 2002 12:01 PM
To: 'Erwan Smits'; [email-masked]
Subject: RE: CDP in self signed root CA

Erwan,
I would agree with the agreement against. There is no authority above
the root CA to issue a CRL on it's cert as it is self signed. Each layer
of CAs below the root and the EEs have a level of authority above them
to issue CRLs that creates a path to validate for the CRLs.
 
Roger Younglove, CISSP
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [email-masked]
www.networksgroup.com
 
-----Original Message-----
From: Erwan Smits [mailto:[email-masked]] 
Sent: Thursday, December 05, 2002 11:36 AM
To: [email-masked]
Subject: CDP in self signed root CA
 
We are building a certificate hierarchy with 4 (CA) layers. We want to
include a CDP extension in every CA and end user certificate. At the
moment we have a discussion about the need for a CDP extension in the
Root CA. The argument against it is that it doesn't make sense because
there is no supperior CA that can sign the CRL. The argument for a CDP
is that for performing a correct path validation the CRL for every CA
(including the Root CA) and end-user certificate should be validated.
 
I scanned through RFC 3280, but it doesn't say anything about it. Does
anybody have suggestions?
 
Greetings,
 
Erwan Smits

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 6 Dec 2002 13:12:27 -0500

Phillip:
 
To repeat myself, practical deployments do not see value to validation
of trust anchors.  In terms of roots bundled in the browsers, and
Windows, these are a bigger problem than checking them against a
self-issued CRL.  One may need to delete them or trust them only for
some defined applications.  Checking them against their own issues CRL
should be the least of the problem.
 
If you feel trust anchor should be processes like any other certificate,
take that up with X.509 and PKIX.
 
I assume you agree that unlike other CRL, self-issued CRL is useless
against that most security critical of revocation, "key compromise!!! 
-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Friday, December 06, 2002 12:49 PM
To: 'Santosh Chokhani'; Hallam-Baker, Phillip; [email-masked]
Subject: RE: CDP in self signed root CA

Hi Phillip:

 

 

            Phill
 
-----Original Message-----

 

        Phill

-----Original Message-----
From: Roger Younglove [mailto:[email-masked]]
Sent: Thursday, December 05, 2002 12:01 PM
To: 'Erwan Smits'; [email-masked]
Subject: RE: CDP in self signed root CA

Erwan,
 
Roger Younglove, CISSP
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
 
-----Original Message-----
From: Erwan Smits [mailto:[email-masked]] 
Sent: Thursday, December 05, 2002 11:36 AM
To: [email-masked]
Subject: CDP in self signed root CA

 
Greetings,
 
Erwan Smits

---

From: Steve Hanna <[email-masked]>
Date: Fri, 06 Dec 2002 13:42:56 -0500

Phillip Hallam-Baker wrote:
> Santosh Chokhani wrote:
> > That is why both X.509 and 3280 DO NOT process self-signed
> > certificate in the certification path. It primes the pump
> > for the path validation engine by providing the following:
> > trust anchor DN, trust anchor digital signature algorithm OID,
> > trust anchor public key, and public key parameters (if required).
> > That is all.  The rest of the checks a RP client does on the
> > trust anchors is all for the birds.
>

Section 6.1 of RFC 3280 says:

   When the trust anchor is provided in the form of a self-signed
   certificate, this self-signed certificate is not included as
   part of the prospective certification path.

That's pretty clear.

-Steve

---

From: Steve Hanna <[email-masked]>
Date: Fri, 06 Dec 2002 17:54:05 -0500

Phillip Hallam-Baker wrote:
> Santosh Chokhani wrote:
> > I do not know exactly what Ron Rivest said and in what context,
> > but verifying a self-signed certificate against a CRL whose
> > signature is verified using the same public key as the one in the
> > certificate is useless.  All it does it give you false sense of
> > security.  Granted, if everyone behaved, you can revoke the trust
> > anchor this way.
>
> I believe that Ron presented a paper on the revocation issue alone
> at one of the Financial Crypto conferences. He also presented it
> at his reading group.

I believe that Phil is referring to this paper:

Can We Eliminate Certificate Revocation Lists?
 by Ronald L. Rivest
 (Proceedings of Financial Cryptography '98; Springer Lecture Notes
  in Computer Science No. 1465 (Rafael Hirschfeld, ed.), February
  1998), pages 178--183

This paper is available from Ron Rivest's web page at
http://theory.lcs.mit.edu/~rivest/publications.html
In it, he makes several interesting proposals. I believe
that Phil is referring to the "suicide note" idea. Each key
holder would prepare in advance a self-signed message stating
that his key has been compromised. Copies of this message
would be saved in safe places. If the key is ever compromised,
the holder would give the suicide note to a "suicide bureau" (SB)
which publicizes the compromise to other SBs. This information
is then made available to relying parties. [1]

This idea is pretty different from a self-signed CRL. In fact,
Rivest's paper was trying to do away with CRLs altogether.
He wanted to use short-lived certificates instead.

The "suicide note" concept could be used to double-check
trust anchor status. Self-signed CRLs are a pale imitation,
since a suicide note is irrevocable and a self-signed CRL
is easily superceded by a newer one signed by the person
who compromised the key. Also, a suicide note can be produced
even if the key is no longer accessible to the proper key
holder. Not so for a self-signed CRL.

Checking suicide notes or self-signed CRLs to verify trust
anchors can be done now by especially attentive relying
parties, in addition to the validation algorithm defined
in RFC 3280. But it's not part of the basic algorithm
required by 3280 and I don't think we should add it to that
required algorithm. This is really beyond basic path validation.

I would be interested in discussing ways to store, check, and
update trust anchor lists. Maybe this could be a supplementary
standard. Let me know if you're interested.

-Steve

[1] Note that in Rivest's paper, the key holder presents a
fresh "certificate of health" from an SB certifying that its
key has not been reported compromised. This can be extended
to allow the relying party to fetch that certificate from the
SB. And it should also be extended to have the SB provide the
suicide note in case of suicide, so that a nasty SB can't
sabotage a key holder by refusing to certify its health.

One question Rivest did not address is "who vouches for SBs?"
When checking the status of a trust anchor, this is a problem.
If the trust anchor vouches for the SBs by certifying them,
then someone who compromises the trust anchor can revoke the
good SBs and certify bad ones.