Subject: RE: CA Rekey and CRL Validation

From: "Dave Engberg" <[email-masked]>
Date: Mon, 13 Sep 2004 13:02:47 -0400

Santosh -

I have a question from your scenario.

Assume the following rekey without a name change:

1) Certs 1-100 (signed by name1 + key1) have one CRL DP URL (e.g.
http://myca/old.crl)

2) Certs 101-200 (signed by name1 + key2) have a different CRL DP URL (e.g.
http://myca/new.crl)

3) Neither CRL DP contains the cRLIssuer extension

4) Key1 signs CRL1 for certs 1-100.  CRL1 has no IDP extension.

5) Key2 signs CRL2 for certs 101-200.  CRL2 has no IDP extension.

6) CA cross-certs exist between the old (name1 + key1) and the new (name1 +
key2)

I think you are saying that this is not secure, since a relying party
inspecting revoked cert #10 could be convinced to accept it based on CRL2,
which will never contain information about #10.

Ideally, the relying party would reject CRL2 for cert #10 because that CRL
was not signed by the "same CA" as the one that signed the cert.  The
language in both the RFC and X.509 is a little fuzzy here.

From X.509 B.5.1.4:

   If the cRLIssuer field is absent from the CRL distribution
   point extension of the certificate, the CRL must be signed by
   the same CA that signed the certificate;

From RFC3280 6.3.3:

   (1)  If the DP includes cRLIssuer, then verify that the issuer
   field in the complete CRL matches cRLIssuer in the DP and that
   the complete CRL contains an issuing distribution point
   extension with the indrectCRL boolean asserted.  Otherwise,
   verify that the CRL issuer matches the certificate issuer.

My question:  from the perspective of a relying party application, how is
"the same CA" defined for X.509?  Obviously, two CA certs with the same name
and public keys represent the same CA, but where is the procedure for a
client to determine whether two certs with the same name and different
public keys are the "same CA"?  Obviously, I need to reject a CRL signed by
a random imposter using the same subjectName as your CA.

Ideally, relying parties would always reject a CRL signed with a different
key the target certificate, unless that CRL has a IDP extension with
indirectCRL=TRUE.  I think this is the defacto state of affairs with most
PKI software, and it would be nice if the spec supported this behavior.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Monday, September 13, 2004 10:37 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Denis:

In terms of Security Problem:

Let us say certificates 1-100 were issued by the CA using key1 and CRL1
contains their status with no IDP.

Let us say certificates 101-200 ere issued by the CA using key2 and CRL2
contains their status with no IDP.

Now when a relying party validates CRL1 or CRL2, it can build a path to the
CRL and think that it has a full CRL for the CA, but it does not.  More
specifically, let us, it want to check the status of certificate 10.  It
gets a CRL which happens to be CRL2.  It can build a path to CRL2 signature
key and validate it and will always get good status since CRL2 will never
contain certificate 10.

The way to solve the problem is as follows:

Put CRL DP = FIRST CRL in certificates 1-100 Put CRL DP = SECOND CRL in
certificates 101-200

Populate the IDP of CRL1 with DP = FIRST CRL Populate the IDP of CRL1 with
DP = SECOND CRL

For further details on CRL processing, see Annex B of X.509, which is
normative.

---

From: "Laudon Williams" <[email-masked]>
Date: Mon, 13 Sep 2004 12:09:06 -0700

Now that brings us back to the question of is a CA just a key, or is a CA a
specific name-key binding? If it is a name-key binding, does the name have
to be unique? It doesn't in end entities certificates, but maybe it should
be in CA certificates.

Actually, the main reason I wanted to chime in is this:
While there are many "standard's compliant" ways to do CA rollover, there is
only one, 100% compatible way to do CA rollover. Create and new CA key and
CA name. This removes all ambiguity. I'm personally a fan of VeriSign's use
of version at the end of the common name.

I'll now return you to the theoretical argument already in progress....

-Laudon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dave Engberg
Sent: Monday, September 13, 2004 10:03 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh -

From X.509 B.5.1.4:

From RFC3280 6.3.3:

-----Original Message-----

Denis:

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Sep 2004 17:01:37 -0400

>to be unique? It doesn't in end entities certificates, but maybe it should

A CA is identified by a name, not a key. CA keys change over time, so 
the name-key binding is not forever, but it does identify an instance 
of a CA at a point in time.

>of version at the end of the common name.

This is overkill, and unless one adopts the rather restrictive (and 
not in the spirit of what a common name should be) naming approach 
with which you seem to be enamored, it is not an approach that yields 
the sort of continuity that most CAs would want.  Also, the 
convention you cite only works when a human is in the loop to make 
the connection between the old version and the next one.  Software 
will see it as two unreleated names.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 13 Sep 2004 17:13:11 -0400

Laudon:

I agree that the easiest way to deal with this mess is to change the CA DN
when you decides to use a new key for whatever reason.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Laudon Williams
Sent: Monday, September 13, 2004 3:09 PM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

-Laudon

-----Original Message-----

Santosh -

-----Original Message-----

Denis:

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 13 Sep 2004 17:47:53 -0400

David Engberg:

See responses in-line in [].

-----Original Message-----
From: Dave Engberg [mailto:[email-masked]]
Sent: Monday, September 13, 2004 1:03 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh -

2) Certs 101-200 (signed by name1 + key2) have a different CRL DP URL
(e.g.
http://myca/new.crl)

6) CA cross-certs exist between the old (name1 + key1) and the new (name1
+
key2)

[In all of the above cases, the only match done is issuer and not issuer
and key.  Thus, relying party does not have a way to distinguish between
CRL1 and CRL2]

My question:  from the perspective of a relying party application, how is
"the same CA" defined for X.509?  Obviously, two CA certs with the same
name and public keys represent the same CA, but where is the procedure for
a client to determine whether two certs with the same name and different
public keys are the "same CA"?  Obviously, I need to reject a CRL signed
by a random imposter using the same subjectName as your CA.

[A CA is defined by the name.  That is why we have a separate cRLSign bit
in key usage.  If the same key was used to sign both the certificate and
CRL, you will not need the cRLSign key usage bit or have self-issued
certificates to sign CRL.  Also, Section 5.1.1.3 of 3280 is very clear and
I quote "Applications that perform CRL
   checking MUST support certification path validation when certificates
   and CRLs are digitally signed with the same CA private key.  These
   applications SHOULD support certification path validation when
   certificates and CRLs are digitally signed with different CA private
   keys."

As to your question about how do you know the CA is not bogus, I have
explained on the list at least on three occasions that you match the
subject DN in certificate and CRL certification path, ignoring self-issued
certificates, but including trust anchor]

[Most toolkits I am familiar with are faithful to the standard in this
area.  They build and validate the path to the CRL if the CRL is signed
using a different key]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Monday, September 13, 2004 10:37 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Denis:

Now when a relying party validates CRL1 or CRL2, it can build a path to
the CRL and think that it has a full CRL for the CA, but it does not.
More specifically, let us, it want to check the status of certificate 10.
It gets a CRL which happens to be CRL2.  It can build a path to CRL2
signature key and validate it and will always get good status since CRL2
will never contain certificate 10.

---

From: "Laudon Williams" <[email-masked]>
Date: Mon, 13 Sep 2004 15:38:48 -0700

Steve,

Thanks you for your well thought-out post.

I would disagree with your statement of "overkill". Right now, today, in
2004, if you have a deployed PKI and you want to do a CA rollover, a new key
and name is 100% compatible with Microsoft OSes, RSA and Baltimore
certificate toolkits, netscape/firefox browsers, all major CAs, etc. It just
works.

Now there are lots of interesting academic arguments and, of course, finger
pointing arguments that can go on as to why other standards-compatible
methods don't work. But really, I don't think the people trying to be
successful with their PKI deployment really care about that.

On your last point, as long as the new CA issues certificates under the same
policy and practices, who cares what its name is? Name is really a factor of
local policy. If I want to name one CA "Alice" and the next version of the
CA "Bob", who cares? Why does software need to know anything more about them
other than that they both issue under the same CP?

So really, to beat the dead horse a bit, there is a standards compliant way
to do roll over that is pretty much compatible with all the
currently-deployed software that does path processing. I'm just trying to
make sure that the people who actually care about making sure that PKI works
are aware of it.

The "making stuff work today" point of view gets lost much to often in the
PKIX minutia.

-Laudon

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, September 13, 2004 2:02 PM
To: Laudon Williams
Cc: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Steve

---

From: David Engberg <[email-masked]>
Date: Mon, 13 Sep 2004 19:56:03 -0400

> certificates, but including trust anchor]

I agree that your interpretation is the common one.  Basically, "any 
uninterrupted chain of 'CA=true' certs with the same subjectName but 
different keys represent the same CA."  Unfortunately, this definition 
of "same CA" does not seem to be spelled out in X.509.  Just like the 
phrase "verify that the CRL issuer matches the certificate issuer" from 
RFC3280 does not come with a formal definition of "matches", since a 
simple subjectName match would obviously be insecure alone.

I agree with Stefan that life would be much easier if a CA was 
identified as a particular unique combination of name + public key. 
This exactly matches the relying party's view of the world, where all 
this "CA rekey" stuff feels like a painful kludge to a straightforward 
idea:  entity = name + key.

> area.  They build and validate the path to the CRL if the CRL is signed

I sent my email after previous folks indicated that both Microsoft CAPI 
and Netscape/Mozilla do not correctly discover or handle indirect CRL 
signers and/or IDP extensions.  By "most PKI software", I meant the 
majority of cert-enabled application copies, rather than available 
toolkit libraries.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 13 Sep 2004 23:24:50 -0400

David:

Asserting IDP does not mean it is an indirect CRL.

Also, you are reading too much in 3280 about CRL Issuer.  All it is saying
is that generally you match the CRL Issuer and Certificate Issuer, bit
when certificate has CRL Issuer field asserted in CRL DP, you match the
value with the Issuer field in the CRL.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Engberg
Sent: Monday, September 13, 2004 7:56 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh Chokhani wrote:
> My question:  from the perspective of a relying party application, how
> is "the same CA" defined for X.509?  Obviously, two CA certs with the
> same name and public keys represent the same CA, but where is the
> procedure for a client to determine whether two certs with the same
> name and different public keys are the "same CA"?  Obviously, I need
> to reject a CRL signed by a random imposter using the same subjectName
> as your CA.
>
> [A CA is defined by the name.  That is why we have a separate cRLSign
> bit in key usage.  If the same key was used to sign both the
> certificate and CRL, you will not need the cRLSign key usage bit or
> have self-issued certificates to sign CRL.  Also, Section 5.1.1.3 of
> 3280 is very clear and I quote "Applications that perform CRL
> subject DN in certificate and CRL certification path, ignoring
> self-issued certificates, but including trust anchor]

> Ideally, relying parties would always reject a CRL signed with a
> different key the target certificate, unless that CRL has a IDP
> extension with indirectCRL=TRUE.  I think this is the defacto state of
> affairs with most PKI software, and it would be nice if the spec
> supported this behavior.
>
> area.  They build and validate the path to the CRL if the CRL is
> signed using a different key]

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 14 Sep 2004 13:42:51 +0200

Laudon Williams wrote:

>[...]. Right now, today, in
>[...] as long as the new CA issues certificates under the same
This solution becomes quite less convenient when you have a CA hierarchy 
and need to rekey a CA that itself has issued other CA certificates.
Opposite to usual practice, it probably is better then to have them all 
expire at the same time.

And it doesn't solve the problem if you ever need to rekey the root CA.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 14 Sep 2004 09:08:05 -0400

Jean-Marc:

You can always start a new CA anywhere in the hierarchy and issue
certificates to the existing sub CAs or create new Sub CAs.

As to the Root, you can have a new name for the Root such as My Enterprise
Root Generation X where X = 0, 1, 2 ....  This is no more of a problem than
having multiple roots with the same name in the relying party client.

I agree with Steve Kent, that it assumes CAs are re-keyed manually and not
automatically.  But, my proposal is to et around the features of MS CA and
MS CAPI and still be standard compliant and be secure.  Isn't it great that
for once we can use COTS, be secure, and be standard compliant.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean-Marc Desperrier
Sent: Tuesday, September 14, 2004 7:43 AM
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Laudon Williams wrote:

>2004, if you have a deployed PKI and you want to do a CA rollover, a 
>new key and name is 100% compatible with Microsoft OSes, RSA and 
>Baltimore certificate toolkits, netscape/firefox browsers, all major 
>CAs, etc. It just works.
>
>[...] as long as the new CA issues certificates under the same policy 
>and practices, who cares what its name is? Name is really a factor of 
>local policy. If I want to name one CA "Alice" and the next version of 
>the CA "Bob", who cares? Why does software need to know anything more 
>about them other than that they both issue under the same CP?
>  
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Sep 2004 09:03:42 -0400

>certificate toolkits, netscape/firefox browsers, all major CAs, etc. It just

The "it just works" model is usually the starting point for a path 
that leads to failures due to a lack of forethought.

>successful with their PKI deployment really care about that.

And to the extent that these folks do not care about standards 
compliance, expect to use in their marketing literature, their 
behavior is not useful grits for a standards committee mailing list 
:-)

>other than that they both issue under the same CP?

Names are NOT a matter of local policy in X.509.  Maybe you're 
thinking of SPKI certs. Moreover, since your comments emphasize 
"practicality" phishing is a concern primarily because it relies on 
the trust people place in names of organizations.  CAs represent 
organizations, hence the names are important, except in monopolistic 
contexts.

>The "making stuff work today" point of view gets lost much to often in the

The  "making stuff work today" point of view is fine so long as it is 
consistent with the standards. Unfortunately, all too often, that 
point of view is short sighted.

Steve

---

From: "Laudon Williams" <[email-masked]>
Date: Tue, 14 Sep 2004 07:40:50 -0700

Actually, it works the exact same with a root CA. No easier or harder.

Let me be a bit more specific.

Given a CA, at lifetime - (longestLifetimeOfIssuedCerts + pad), the CA
ceases it certificate issuance function and continues issuing only CRLs for
the rest of its life. At the same time, NewCA (new name and key) begins
issuing certificates and CRLs.

Works regardless of point in the hierarchy. There may be a difference in how
many certificates you have to issue immediately after rollover though.

Regards,

-Laudon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean-Marc Desperrier
Sent: Tuesday, September 14, 2004 4:43 AM
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation

---

From: "Laudon Williams" <[email-masked]>
Date: Tue, 14 Sep 2004 08:03:34 -0700

Inline...

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2004 6:04 AM
To: Laudon Williams
Cc: [email-masked]
Subject: RE: CA Rekey and CRL Validation

[LW] Just as the "let's make this really complex" model often leads to a
path of, well, the state of PKI today. Yet you have not articulated a reason
why (1) this doesn't work, or (2) it is incompatible with the standards as
written. 

[LW] I disagree. Not that names are important, because meaningful names are,
but that they are as important as you make them out to be. Please explain to
me how the following CAs are different from a trust or "software"
perspective.

CA 1:
- Chains to trust anchor A
- Issues under CP x.x.x.x (and CPS "foo")
- Issues end entity certificates x, y, and z to group "bar"

CA 2:
- Chains to trust anchor A
- Issues under CP x.x.x.x (and CPS "foo")
- Issues end entity certificates x, y, and z to group "bar"

Oh, CA 1 is named "Alice" and issued from 2000-2002. CA 2 is named "Bob" and
issued from 2002-2004. 

I'm not seeing the difference in trust here. Or how applications get broken.
Or, how names are particularly relevant. Roots are a bit more complex, but
that is why I personally like the version convention. "Version" is very
human readable. Most people can understand the convention.

[LW] Steve, really, this is absolutely nothing personal. Really. The parent
thread is about to embark on a long, drawn out argument on CA rollover that
is going to lead to a very complex, yet standards-compliant solution. The
solution will (1) not be usable given the currently deployed software base,
(2) lead to implementation arguments, and god forbid (3) lead to the new
method being the *preferred* method of CA rollover, since it was discussed
in the group.

I see these as all bad outcomes because it really doesn't do much for the
people out there today with deployed PKI. Especially given the fact that
there is a solution that is compliant and works today.

Let's not fall into the same trap NIST always does and instead choose
something that works.

Regards,

-Laudon

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Sep 2004 11:39:51 -0400

>why (1) this doesn't work, or (2) it is incompatible with the standards as

We don't try to make complex standards; we try to make standards that 
accommodate a wide range of requirements, and that sometimes leads to 
complexity.

The standards define a CA in terms of its name.  So your suggestion 
to just move on to a new name when a CA key changes is NOT compatible 
with the standards.

	<SNIP>

>Oh, CA 1 is named "Alice" and issued from 2000-2002. CA 2 is named "Bob" and

Then they are different CAs, since there is no syntactic way for ME 
or my software to know that they are the same. BTW, there is no 
issuance of certs to a "group" so I'm not sure what you meant in your 
example in that regard.

>human readable. Most people can understand the convention.

I work for a company that used to be named "Bolt Beranek and Newman" 
and then was named "BBN" then "BBN Systems and Technologies" and now 
"BBN Technologies."  You might think these are all the same 
organization, and in some ways they were, but in other legal ways 
they were not. How about an organization named "BB&N?"  Sounds like 
the same organization as the series noted above, its located in 
Cambridge, MA like the ones noted above, but, its a school 
(Buckingham, Browne and Nichols).  So, when names change the safe 
assumption is that the entity being represented by the name is 
different, until we establish otherwise. How do we establish that the 
different names map to the same entity? Not via a syntactic check 
performed by our software!

>[LW] Steve, really, this is absolutely nothing personal. Really.

I don't take it personally. I just view it as a bad idea.

>The parent

The "solution" you cite (changing the name of the CA using a naming 
convention analogous to serial numbering) is NOT standards compliant 
unless we change the definition of a CA, and does not work 
automatically with software.

BTW, are you the same Laudon Williams who is a Microsoft program 
manager dealing with PKI? If so, then it might be more appropriate to 
use your corporate  e-mail address in these discussions, so that list 
participants are aware of potential corporate biases that may arise 
in these discussions.

Steve

---

From: "Laudon Williams" <[email-masked]>
Date: Tue, 14 Sep 2004 09:21:26 -0700

[LW] I don't think you've really made that case. You said it was the same
CA. I never did. I just said rollover. You jumped to a bunch of conclusions.
You keep trying to make it the same CA. I keep saying it is a different CA
(new name and key). It just operates under the same policies and practices
as the old one.

[LW] I've posted under this alias when I worked for CyberSafe, RSA Security,
and Microsoft because it represents my opinion, not that of my employer. In
the one case where I've posted to this list with an "official" response, I
made it clear who I was.  But, as it stands, I no longer work for Microsoft.
I'm back in the field trying to make this stuff work for the average
company. And yes Steve, I have a bias to making things work given the
current operating environment. I don't have a bias towards a particular
vendor implementation.

-Laudon

Who is not employed by Microsoft, no matter how much Steve wants to make
this political :-)

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 14 Sep 2004 19:42:28 +0200

>Who is not employed by Microsoft, no matter how much Steve wants to make
And anyway, the solution Microsoft employees favor is to use IDP 
everytime the CRL is not signed with the same key as the CA.

What you present us is what I would call the Verisign way of solving the 
problem by avoiding it all fully ...

I agree it's the only method that would work with currently deployed 
software, but a perfectly clearly defined way to correctly rekey for a 
future generation of products would be useful. And does not have to be 
that complex ...

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Sep 2004 13:35:29 -0400

>(new name and key). It just operates under the same policies and practices

Sorry if I jumped to that conclusion.  I think the other folks 
discussing this topic have focused on that aspect of the issue, based 
on the exchanges that Santosh and Stefan have had, for example.

if the new CA is not assumed to be elated to the old one, but it 
"happens" to share the same policies, then it may be very similar, 
maybe even equivalent. but, that says nothing about it's legitimacy 
to issue certs for any set of users. So, if one made a value 
judgement about accepting the old CA as an issuer for a set of users, 
one has to go back and make the same judgement for the new CA. As I 
noted, this is not an automated process, and it imposes a burden on 
users, unless we assume that the users will just ignore these details 
and hope for the best :-)

In the case of browsers, the trust anchor model is seriously broken 
anyway, so that does not provide a suitable basis for determining the 
suitability of this sort of CA rollover in general.

>current operating environment. I don't have a bias towards a particular

I too have biases, though they are not based on vendor affiliation, 
since BBN is not a product vendor.  My bias is against "making things 
work" based on non-compliant implementations. Doing so encourages 
vendors to not follow standards, i.e., it sends the wrong message.

Steve

---

From: "Laudon Williams" <[email-masked]>
Date: Tue, 14 Sep 2004 15:40:08 -0700

So just to finalize this (feel free to rebut Steve)...

When faced with CA expiration, you have two choices. You can either;
- Rollover the key (same name, new key), or;
- Rollover the CA (new name, new key).

Key rollover *may* work in closed systems, but as evidenced by the original
discussion on this thread, is not consistently implemented. YMMV. If a
mechanism for this is standardized, it may work more consistently at some
point in the future.

CA rollover *does* work with the large majority of relying party software in
the world today. It violates no standards, and is highly compatible. For the
majority of PKIs deployed today, it should be the preferred solution.

I would ask that if CA expiration is addressed in 3280bis, we ensure that
both mechanisms receive adequate coverage.

Regards,

-Laudon

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 15 Sep 2004 11:59:31 +0200

>mechanism for this is standardized, it may work more consistently at some
It sounds like we are very near that mechanism.
The first thing needed is that the implementers of CRL verifiers, in the 
absence of an IDP, always do a fully-qualified names to a common trust 
anchor match between the crl signer and the certificate issuer.
The other thing needed is that CA implementers fully realize that when 
they do a key rollover, it's still the same CA, so in the absence of an 
IDP the CRL *MUST* continue to cover the same set of certificates. Also 
serial number uniqueness must be preserved.

IIUC this is what is missing in the standard now and should be added 
(even if the second point is only a clarification).

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 15 Sep 2004 07:13:44 -0400

Folks:

You are misunderstanding the IDP and name matching.  IDP declares the scope
of CRL.  If you do not include IDP and only provide revocation status for a
subset of certificates (e.g., those certificates signed with a specific
key), you are fooling the relying party in thinking that this a full CRL for
the CA.

The certification path DN matching algorithm (which needs slight refinement
between I, N1, and N2) is a substitute for ensuring that you have a CRL from
the same CA when the certificate and CRL are signed with different keys.

Both rules need to be adhered to.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean-Marc Desperrier
Sent: Wednesday, September 15, 2004 6:00 AM
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Laudon Williams wrote:

>Key rollover *may* work in closed systems, but as evidenced by the 
>original discussion on this thread, is not consistently implemented. 
>YMMV. If a mechanism for this is standardized, it may work more 
>consistently at some point in the future.
>  
>
It sounds like we are very near that mechanism.
The first thing needed is that the implementers of CRL verifiers, in the 
absence of an IDP, always do a fully-qualified names to a common trust 
anchor match between the crl signer and the certificate issuer. The other
thing needed is that CA implementers fully realize that when 
they do a key rollover, it's still the same CA, so in the absence of an 
IDP the CRL *MUST* continue to cover the same set of certificates. Also 
serial number uniqueness must be preserved.

---

From: Stephen Kent <[email-masked]>
Date: Sun, 19 Sep 2004 17:22:47 -0400

>- Rollover the CA (new name, new key).

the second case is not "rollover" because the CA name changed and, 
according to X.509 and PKIX, the new name represents a new CA. the 
term "key rollover" is used to refer to a key change where the name 
of the subject stays constant, whether the context is an EE or a CA.

Steve

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 23 Sep 2004 18:11:44 +1200

>that leads to failures due to a lack of forethought.

As opposed to the other approach, where you first need to produce 
2000 pages of specifications over a period of 10 years to get to the
same point.  The main difference with the "it just works" model is 
that it just works for at least some (hopefully the large majority) 
of users, and by extension it does what most users want/expect it to
do.

Peter (OK, I held back for some time there, but I just had to say it :-).

---

From: Stephen Kent <[email-masked]>
Date: Thu, 23 Sep 2004 15:13:44 -0400

>Peter (OK, I held back for some time there, but I just had to say it :-).

if we got to the same point via a standards process your cynical 
observation would be valid, but since we don't get to the same point, 
it's merely an attempt at a humorous comment.

I can tell that you are an 80% solution kinda guy. I think such 
solutions are OK for some contexts, but not for security. I don't 
want to fly on an aircraft that has a fuel gage that, most of the 
time works well enough to allow safe passage to the destination, but 
some small fraction of the time reads a bit high and causes the plane 
to crash as it runs out of fuel. Since we develop security standards 
for use by a wide range of applications, we need to work hard to get 
it right for a very wide range of contexts, and allow different 
contexts to focus on the assurance with which the standards are 
implemented, to ensure an appropriate level of security.

Steve