Subject: RE: CDP in self signed root CA

From: "Tom Gindin" <[email-masked]>
Date: Fri, 6 Dec 2002 13:20:39 -0500

Santosh:

      RFC 3280 explicitly excludes self-signed certificates used as trust
anchors from the path, but not any other certificates used as trust
anchors.  Obviously, if one checks a self-signed CRL and sees the issuer
there, the issuer is now invalid.  The absence of the issuer certificate
from a self-signed CRL does not mean "nothing", it means that one of the
following three cases is true:
1     The issuer certificate is fully valid.
2     There has been an undetected key compromise.
3     There has been a detected key compromise and the repository has been
compromised as well.
      The inability of the RP to distinguish between cases 1 and 2 is
equally applicable to EE certs, where CRL's are checked.  For a CA, case 3
is effectively added to case 2.  Unless you think that key compromise is
the only reason that people would check CA certificates and that almost all
cases of detected CA key compromise will also result in repository
compromise, checking a self-signed CRL is hardly worthless.

            Tom Gindin

"Santosh Chokhani" <[email-masked]>@mail.imc.org on 12/06/2002
12:40:20 PM

Sent by:    [email-masked]

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    "'Hallam-Baker, Phillip'" <[email-masked]>, <[email-masked]>
Subject:    RE: CDP in self signed root CA

Tom:

The basic point is this:

1.  Trust anchors are not part of the certification path.

2.  If one were to add trust anchor validation, presence of self-signed
certificate on self-signed CRL obviously means do not use it -- We do
that all the time by permitting subscribers to use the compromised key
to sign revocation request.

3.  If one were to add trust anchor validation, absence of self-signed
certificate on self-signed CRL means nothing.

So, where does that leave you?  In limbo?

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Friday, December 06, 2002 12:32 PM
To: Santosh Chokhani
Cc: 'Hallam-Baker, Phillip'; [email-masked]
Subject: RE: CDP in self signed root CA

      Santosh:

      Whether the revocation of a self-signed certificate is worthless
or not depends mainly on context.  Of the CRL reasons which are
meaningful for a CA, affiliationChanged, superseded, and
cessationOfOperation are perfectly reliable and meaningful in a
self-signed CRL.  For that matter, CA Compromise is also meaningful but
in that case you can't rely on the CRL not being overridden by a falsely
clean one produced by the compromiser.
      However, if the update path for the directory being accessed (or
other CRL repository) is directly trusting any specific key other than
the primary CA key (or even a user name/password combination),
compromising the CA key does not give the compromiser power to publish
his falsely clean CRL in that location.  This does not mean that the
repository is more secure than the CA, merely that its security is
largely independent of the CA's, and thus trusting the combination of CA
and CRL repository is less risky than trusting the CA alone.
      Similar points apply more strongly (in a slightly different
environment) to a cross-certificate used as a trust anchor.  RFC 3280
does not exclude (at least by its wording) such certificates from the
certification path.

            Tom Gindin

"Santosh Chokhani" <[email-masked]>@mail.imc.org on 12/06/2002
10:16:21 AM

Sent by:    [email-masked]

To:    "'Hallam-Baker, Phillip'" <[email-masked]>,
<[email-masked]>
cc:
Subject:    RE: CDP in self signed root CA

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.

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.

Thus, from security viewpoint, this gyration is useless.

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).  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.
      -----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:38:37 -0500

Tom:

See responses in [].

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Friday, December 06, 2002 1:21 PM
To: Santosh Chokhani
Cc: 'Hallam-Baker, Phillip'; [email-masked]
Subject: RE: CDP in self signed root CA

      Santosh:

      RFC 3280 explicitly excludes self-signed certificates used as
trust anchors from the path, but not any other certificates used as
trust anchors.
[The RFC excludes any public key you start with as your first trust
public key, be it self-signed certificate or something else]

Obviously, if one checks a self-signed CRL and sees the issuer there,
the issuer is now invalid.  The absence of the issuer certificate from a
self-signed CRL does not mean "nothing", it means that one of the
following three cases is true:
1     The issuer certificate is fully valid.
2     There has been an undetected key compromise.
3     There has been a detected key compromise and the repository has
been
compromised as well.
[It does not mean item 3 since the network can not be trusted and an
adversary can replay the bogusly created CRL.  Taken 1 and 2 and 3
together, it means it could be valid or it could be invalid.  To me,
when you feel strongly about A and ~A, it means nothing.]

      The inability of the RP to distinguish between cases 1 and 2 is
equally applicable to EE certs, where CRL's are checked.
[With the RP, when you have 3, with or without compromised repository,
you get the right CRL or get denial of service due to detectable bogus
CRL or stale CRL.  THAT DOES NOT HAPPEN WITH THE SELF-SIGNED  CRL.  And
that is the basic rub.]

For a CA, case 3 is effectively added to case 2.  Unless you think that
key compromise is the only reason that people would check CA
certificates and that almost all cases of detected CA key compromise
will also result in repository compromise, checking a self-signed CRL is
hardly worthless.

[I think if key compromise reason is not covered for the root CA, the
revocation choking is like a drunk looking for the key where he DID NOT
lose it.  I will tell you the joke some time when I see you.  It is
funnier in person]

[If you feel that checking self-signed root against its own CRL is worth
it, please go ahead and file a defect report with X.509 and/or open up a
discussion on amending 3280.]

            Tom Gindin

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    "'Hallam-Baker, Phillip'" <[email-masked]>,
<[email-masked]>
Subject:    RE: CDP in self signed root CA

Tom:

The basic point is this:

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Friday, December 06, 2002 12:32 PM
To: Santosh Chokhani
Cc: 'Hallam-Baker, Phillip'; [email-masked]
Subject: RE: CDP in self signed root CA

      Santosh:

            Tom Gindin

Hi Phillip:

      -----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

              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-----

             Greetings,

             Erwan Smits

---

From: Steve Hanna <[email-masked]>
Date: Fri, 06 Dec 2002 15:45:01 -0500

Tom Gindin wrote:
> anchors.

Actually, trust anchors are always excluded from the path, even
if they are not self-signed. The text isn't quite as explicit on
this as it is about self-signed trust anchors, but it's clear.
Section 6.1 of RFC 3280 says:

   To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n
   certificates) satisfies the following conditions:

      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
      the issuer of certificate x+1;

      (b)  certificate 1 is issued by the trust anchor;

      (c)  certificate n is the certificate to be validated; and

      (d)  for all x in {1, ..., n}, the certificate was valid at the
      time in question.

As you can see, the path begins with a certificate issued by
the trust anchor. It does not begin with the trust anchor itself.
If you read through the rest of section 6.1, you'll see that
only the certificates in the path (certificates 1 through n)
are validated or checked for revocation during the process.

There's no rule against checking the revocation status of a
trust anchor. Any implementation can do whatever extra checks
it wants. But this check is not part of the standard validation
algorithm as described in RFC 3280.

-Steve

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 09 Dec 2002 15:13:26 +0100

Steve,

I agree, but see my last comment. ;-)

> algorithm as described in RFC 3280.

A copy of that last paragraph in RFC 3280 would certainly be helpful,
and would have avoided that discussion. :-)

Denis