Subject: Re: CRL reason codes

From: [email-masked]
Date: Sat, 02 Jan 1999 12:12:19

Peter:

You asked:
 
Another question about CRL's, what happens when a CA with a self-signed cert 
revokes its own cert?  Is the cert regarded as valid for the purposes of 
authenticating the CRL, but invalid a few microseconds later once its 
revocation is read from the CRL?  
 
Gee, when I asked that same question about 3 weeks ago on this same list, all I got was deafening silence. 

As I noted in my posting on this topic, I've seen a CA revoke its own self-signed cert in the lab on two occasions.  Some of the end-entity applications accepted the CRL as valid, and then revoked the cert;  some rejected the CRL as invalid (it was signed with a revoked certificate); and some of the applications just died.

I'm still interested in any consensus on what's "supposed" to happen in this case.

                    Al Arsenault

-- my own opinions; not representing those of my employer or any other organization; etc. etc.  Oh, and Happy New Year, too!

---------------------------------------------------------------------
This message has been posted from Mail2Web (http://www.mail2web.com/)
---------------------------------------------------------------------

---

From: Nada Kapidzic Cicovic <[email-masked]>
Date: Mon, 04 Jan 1999 11:59:45 +0100

At 12:12 1/2/99, [email-masked] wrote:
>As I noted in my posting on this topic, I've seen a CA revoke its own
self-signed cert in the lab on two occasions.  Some of the end-entity
applications accepted the CRL as valid, and then revoked the cert;  some
rejected the CRL as invalid (it was signed with a revoked certificate); and
some of the applications just died.
>I'm still interested in any consensus on what's "supposed" to happen in
this case.

I suppose you should never "trust" a self-signed certificate in the first
place. You should trust a CA's public key that you received in a trusted
way and installed in your PSE.

If the CRL was signed with the private key corresponding to your CA's
trusted public key, then you regard all of the revocations from the CRL as
valid (thus even the self-signed certificate is invalid, if you ever come
to verifying it).

You may raise the question about the way of getting the trusted CA's key.
Even if it is sent in the form of a self-signed certificate, it should not
be tested against the latest CRL, since you should trust the source of the
key and the means of the transportation (out-of-band).

So, in my opinion in this particular chicken-and-egg problem, the trusted
public key is the oldest one.

Regards,

Nada

>
>                    Al Arsenault
>
>-- my own opinions; not representing those of my employer or any other
organization; etc. etc.  Oh, and Happy New Year, too!

---

From: Al Arsenault <[email-masked]>
Date: Mon, 04 Jan 1999 08:11:38 -0500

Nada,

	I'm a little unclear as to your logic here.

At 11:59 AM 1/4/99 +0100, Nada Kapidzic Cicovic wrote:
><snip>

	That's basically the scenario I'm talking about.  I have obtained through
out of band methods the public key of a CA that I trust.  (Maybe it came on
a tamper-resistant hardware token; maybe I got it by physically going to
the CA workstation and copying it onto a floppy disk, which I hand carried
back; maybe I used some other means to get it.) That public key is also
contained in that CA's self-signed certificate.

	Then, the certificate containing the public key is listed on a CRL.  If it
makes a difference, the reason code can be "key compromise"; i.e., we
believe that the private key corresponding to the "trusted" public key has
been compromised.

	So - a certificate containing the key I trust has now been declared to be
revoked.  The declaration comes in a CRL, signed with the very private key
that is now declared to be compromised. Do I believe it?

>valid (thus even the self-signed certificate is invalid, if you ever come

	Personally, that's my preference.  I believe that if a certificate
containing a public key is revoked, and the revocation notice (e.g., the
CRL) is signed with the  private key matching that public key, then the
revocation notice should be treated as valid, and the certificate only
marked revoked AFTER the revocation notice is processed.  I'm interested in
other people's opinions, though.

>key and the means of the transportation (out-of-band).

	I think I disagree with this, although I'm not sure that I understand your
point.  If I get a new "trusted" key, I should check its revocation status
before each use.  Yes, self-signed keys should rarely if ever be revoked,
but it might happen.  (It reminds me of the old doctor joke:  "Doctor, it
hurts when I do this."  "Well, don't do that."  If it hurts when you revoke
your own self-signed certificate, in general you shouldn't do it.  But
there might be a reason - the CA's private key might really have been
compromised.)

>public key is the oldest one.
	And if that oldest trusted public key has been compromised...?

>Nada

	A variation on this occurs when that same key is used in multiple
different self-signed certificates, and only one of them is marked as
revoked.  I personally believe that using the key this way is a bad idea,
and hope that it never occurs, but I suppose that it's theoretically possible.

						Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.

---

From: Juergen Walter <[email-masked]>
Date: Mon, 04 Jan 1999 16:17:19 +0100

Al, Peter,

I have scanned the current drafts. The result is the same that Al has
already found in the lab. I refer to the variable T in the certificate
path validation chapter of the current draft. T is not specified. T is
an arbitrary date in the past:

[PKIX] "(d)  the time, T, for which the validity of the path should be
      determined.  (This may be the current date/time, or some point in
      the past.)" [PKIX]

Hence, the certiifcate path validation algorithm is not well-defined.
Actually, it depends on T. This may explain  Al´s observations. Two
additional requirements would solve the problem:
(1) CRL signing certificate _must_ be valid at least until _nextUpdate_,
and
(2) in the unlikely event that the CRL signing key is compromised the
CRL _must_ be reissued and _must_ signed with a key that certificate is
valid at least until _nextUpdate_ of the reissued CRL.
I do not know whether these requirements are (implicitly) contained in
the current drafts or not. If they are, the remaining lines may be
skipped.  

I assume that the CRL may be signed with a key that is present at the
signed CRL in the following.

Another issue is the authentication of CRLs. This depends on the key
usage on the one side and on CRL content on the other side. Al and Peter
has considered the case that the CA root key is used for both signing
certificates and signing CRLs. But a different key usage is still
allowed. Secondly, the CRL may contain _revocationDate_,
_invalidityDate_, _reasonCode_, ... information. So, the
_revocationReason_ of the root certificate comes into question.

I would like to give the following (extremal) example. The CA signs its
own CRL applying the CA´s private key. In the unlikely event that the
CA´s private key is compromised disaster handling consists of publishing
a CRL including an revocation entry for its own root key. When an
application verifies the validity of a certificate signed with the
compromised CA´s key the result must be "invalid". This result must be
independent whether this certificate is present at the issued CRL or
not. In addition, the _revocationDate_ and other information usually
provided by CRL is not authenticated. The application knows only the
latest date of revocation in this case, i. e. the date, when the CRL was
retrieved. Furthermore, the application must be aware of fake CRLs. An
attacker may issue a CRL without root certificate entry.

Other reasons of revocation result in several scenarios. They differ in
the amount of available information authenticated by the issued CRL.

I think that the revocation of the CRL signing key is a matter of
disaster management and bussiness continuity planning, respectively.
These topics should be covered by the PKIX drafts such that the error
situation described by Al no longer appears.

Juergen

> I'm still interested in any consensus on what's "supposed" to happen in this case.

Juergen

---

From: Juergen Walter <[email-masked]>
Date: Mon, 04 Jan 1999 17:38:27 +0100

Al, Nada, Peter,

Do you know an example, where it is necessary to allow the CRL signed
with  a key that is on the same CRL? 

I think that a well-done key update of CRL signing key may help that
this construction is avoidable. Apart from that I see the following
cases:

(1) CRL signing key compromise (see my last mail),
(2) CA change of affiliation (i. e. a certification domain changes to
another),
(3) cessation of CA operation (Al´s lab observation?)

I believe that the current PKIX drafts are quite silent about these
topics. 

Nada,
> way and installed in your PSE.

I agree with you. But, this is a cost-intensive initialization
procedure. Please note, that a CA´s key change is desirable unless the
initialization procedure is repeated.

> public key is the oldest one.

Surely, this is not applied, if the CRL signing key (= root key) is
compromised. In the unlikely event of CRL signing key compromise the
validation software must be aware of fake CRLs (especially additional
CRL information). Apart from this case, I believe that the current
certificate path validation algorithm does not work well.

Juergen

---

From: Juergen Walter <[email-masked]>
Date: Mon, 04 Jan 1999 18:59:42 +0100

Al,

> that is now declared to be compromised. Do I believe it?

In my opinion, you have to believe it. As a consequence, all
certificates signed with the compromised key are invalid. Furthermore,
it does not matter, whether the certificates are listed in the issued
CRL. I have serious doubts that a validation software will detect this.
The additional CRL informations (like revocation date, invalidity date,
revocation reason, ...) are not authenticated. In this sense, your
validation software must be aware of fake CRLs.

> other people's opinions, though.

What is about the following case? Your validation software has to verify
a certificate validity at T<"NOW". Supposed your software retrieves the
CRL that contains a CRL entry for the CRL signing key, then you know
that the revocation date is REV<"NOW", because the included revocation
date is not properly authenticated. Your software is not able to decide,
whether the certificate was valid at T.  Otherwise, the certificate
validation at T="NOW" would be still fine. Therefore, this handling is
appropriate at least for those communities that set T="NOW". More
sophisticated certificate validation (i.e. T<"NOW") requires additional
certificate and revocation management.

I think that the handling you described should be allowed. But, I am not
sure, whether it is compliant to the current PKIX drafts or not. I would
tend to say that it is not. 

[snip]
> and hope that it never occurs, but I suppose that it's theoretically possible.

I agree completely. This occurs when a CA operator wants to reuse the
CA`s private key. In my opinion, the certificate path validation
algorithm is quite clear. All certificates are invalid provided that one
of the self-signed certificates is revoked. I dislike this reuse.

-- 

Juergen

---

From: Al Arsenault <[email-masked]>
Date: Mon, 04 Jan 1999 13:45:44 -0500

>with  a key that is on the same CRL? 

There are two scenarios I can think of.  The first involves the compromise
of the CA's private CRL-signing key, and the second involves cessation of
CA operations.

In the compromise case, there are at least two ways to avoid having a CRL
signed with a key associated with a certificate that's on the list.  The
first involves the use of something like CRL Distribution Points and
Indirect CRLs (ICRLs), where you have a "trusted authority" who can notify
users that a CA's key has been compromised, and thus that any CRLs and/or
new certificates from that CA should not be trusted.  The second is to have
pre-placed a "replacement" key; i.e., 'the current key used by the CA is
key x, and the next key to be used by the CA will be key (x+1).'  

In the ICRL case, users have to go check a separate CRL (in addition to the
CA's regular CRL) to ensure that the CA's cert hasn't been revoked.  Other
than this performance impact/user inconvenience, though, this approach
works well as long as you can really trust the ICRL authority.  Otherwise,
you wind up with one node that can cause big-time denial of service
problems, just by revoking CAs at will.  

In the "replacement" key approach, this works as long as key (x+1) is not
compromised at the same time that key x is.  If x is compromised, but (x+1)
is not, then the CA switches to the new key, and sends out a CRL revoking
any certificate associated with x.  However, if x and (x+1) are compromised
at the same time, you're back where you were when you didn't have a
replacement key.

If you don't have one of these two strategies - ICRL or replacement key -
then I think that your only choice is to use the compromised key to sign a
CRL revoking certificates associated with that very key.

In the cessation of operations case, you can also use the ICRL approach to
avoid signing with the key associated with the certificate to be revoked,
because the ICRL Authority would outlive the CA.  I suppose you could also
use the replacement key approach, although it's not clear then how you'd
revoke the certs associated with the replacement key (or if you'd really
need to).  Otherwise, you just live with the original problem.  In this
case, it seems clear to me that the "safe" thing to do is accept the CRL as
valid, and then have applications refuse to honor the CA's key after that
point.

				Al Arsenault