Subject: RE: CA Rekey and CRL Validation

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 15 Sep 2004 10:21:40 +0100

Santosh,

You miss my point.

I was expressing this generally but of course, in practice we only
discuss the case where a CA is re-keyed without changing its name.

The security vulnerability is then exposed if those 2 CA's keep issuing
CRL's without IDP with scope limited to their respective issued
certificates.

You showed this yourself in one of your examples before!

I'm not aware of any section in RFC 3280 or X.509 that declare this
practice invalid.

The RP software that doesn't enforce key match in this instance may now
validate a certificate using the wrong CRL and come to the wrong
conclusion.

If a CA and an RP deploys standards compliant configurations and the RP
end up accepting a revoked certificate, this is a vulnerability. 

Now, another FACT is that if validation of CRL without IDP requires key
match, then that would solve this vulnerability.

Do we want to fix this problem in this way? That is another question
open for debate...

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 20:58
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> If the relying party has two CA's with the same name X, but really
> represent
> different real entities, the relying party is going to have bigger
problem
> of disambiguation than correct CRL.
> 
> Similarly, if the relying party has two intermediate CAs named Y,
under
> the
> same certification path, you have bigger problem of disambiguation
than
> correct CRL.  Also, no CA I know will certify the two different CAs
with
> the
> same name.  That has to happen for this to occur.
> 
> So, I will assume that neither of these two is the case.
> 
> Then, the problem boils down of matching the certification path for
the
> certificate and the certification path for the CRL used to check the
> revocation status of the certificate.
> 
> The following rules should be used to ensure that you have the CRL
from
> the
> appropriate CA:
> 
> 1.  The DN of the root in both cases must match.
> 
> 2.  Set I = 1.  N1 = number of certificates in the "certificate
> certification path", ignoring self-issued certificates.  Set N2 =
number
> of
> certificates in the "CRL certification path", ignoring self-issued
> certificates.
> 
> 3.  If I = N1 or I = N2 exit with success
> 
> 4.  Verify that the issuer DN in certificate I in the "certificate
> certification path" matches the issuer DN in certificate I in the "CRL
> certification path", ignoring self-issued certificates.
> 
> 5.  Verify that the subject DN in  certificate I in the "certificate
> certification path" matches the subject DN in certificate I in the
"CRL
> certification path", ignoring self-issued certificates.
> 
> 6.  I = I + 1.  Go to step 3
> 
> {BTW, this has been explored and explained on this mail list couple of
> times)
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, September 14, 2004 9:52 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> Santosh.
> 
> CA1 and CA1(bis) have the same name but different keys.
> 
> They are both valid in the RPs trust configuration.
> 
> Both CAs issue CRLs without IDP (which is RFC 3280 and X.509 compliant
> practice).
> 
> Result: The RP can't determine what CRL and what CA belongs together
> resulting in false acceptance of revoked certificates.
> 
> You can call it what you want.
> I call that a security vulnerability.
> 
> /Stefan
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 14 september 2004 14:36
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Stefan:
> >
> > There is no security problem in building a certification path for
the
> CRL
> > Issuer when the same CA issues the CRL, but signs the CRL using a
> > different key (i.e., different from the one used to sign the
> > certificate being validated).
> >
> > You can build a path.  You do need to do name matching as I have
said
> in
> > several previous postings.
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Tuesday, September 14, 2004 7:09 AM
> > To: Manger, James H; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> >
> > James,
> >
> > I don't agree with your examples.
> >
> > The "simple" structure that dominates deployment today is 1 CA = 1
key
> > which has the consequences you mention.
> >
> > However, the stanards define also indirect CRLs which can be used to
> solve
> > all your issues below EVEN if you stick with the definition 1 CA = 1
> key.
> >
> > The issue at hand, previously stated to Santosh is whether a CRL
> without
> > IDP
> > can be validated with another key than the one used to validate
> > certificates issued by the CA.
> >
> > If that is allowed, then we have identified a security problem that
> ought
> > to
> > be fixed.
> >
> > /Stefan
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Manger, James H
> > > Sent: den 14 september 2004 06:36
> > > To: [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > > Same name, different key = SAME CA.
> > >
> > > Without this, if a CA's private key is destroyed no CRLs can ever
be
> > > issued again for the certs it has issued so that CA's whole PKI
> > crumbles
> > > in an instant.
> > > Without this, every CA needs to keep operating (issuing CRLs)
after
> it
> > has
> > > issued its last cert for the lifetime it was putting in certs (eg
2,
> > 5, 10
> > > years?).
> > > Without this, every certifier wanting to periodically change keys
> > (which
> > > is good practice) needs to run multiple CAs.
> > >
> > >
> > >
> > >
> > > P.S. There are ways to ensure name uniqueness for CAs -- either
> > > concatenate issuer names from a trust anchor to the CA of interest
> to
> > get
> > > that CA's "name", or just use the issuer field for that CA and
rely
> on
> > > your configured trusted anchors to name CAs in a way that avoids
> > ambiguity
> > > (which is, in fact, the primary reason for a PKI in the first
> place).
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Stefan Santesson [mailto:[email-masked]]
> > > Sent: Tuesday, 14 September 2004 8:53 AM
> > > To: Santosh Chokhani; [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > >
> > > Santosh,
> > >
> > > I realize that the standard is not crystal clear on this issue and
I
> > > suggest that you either have the wrong interpretation, or at least
> use
> > > an interpretation that ought to be wrong.
> > >
> > > The core issue is whether two CAs having the same name but
different
> > > private issuing keys, are regarded as 1 CA or 2 separate CAs.
> > >
> > > I suggest (and hope) that these are NOT defined anywhere as being
> the
> > > same CA. This is also supported by the reality fact that there is
no
> > way
> > > that you can ensure name uniqueness between CAs and therefore,
> > key-match
> > > should be a requirement.
> > >
> > > From this perspective standards states the following:
> > >
> > > X.509 Annex B states:
> > >
> > >    If the cRLIssuer field is absent from the CRL distribution
point
> > > extension of the certificate, the CRL shall be signed by the same
CA
> > > that signed the certificate; and
> > >    If the cRLIssuer field is present in the CRL distribution point
> > > extension of the certificate, the CRL shall be signed by the CRL
> > Issuer
> > > identified in the CRL distribution point extension of the
> certificate
> > > and the CRL shall contain the indirectCRL field in the issuing
> > > distribution point extension.
> > >
> > > RFC 3280 5.2.5 states:
> > >
> > >    The CRL issuer MUST assert the indirectCRL boolean, if the
scope
> of
> > >    the CRL includes certificates issued by authorities other than
> the
> > >    CRL issuer.
> > >
> > >
> > > So IF different signing keys means that CA(old) and CA(new) are
> > > different CAs (despite identical names), then in order to allow
> > CRL(new)
> > > from CA(new) to be used to validate certificates from CA(old),
then
> > > CRL(new) need to contain an IDP with indirectCRL asserted,
> > certificates
> > > from CA(old) must also contain a CDP with cRLIssuer field.
> > >
> > > I suggest therefore that a CRL without IDP with indirectCRL is
> > required
> > > to be signed with the same key that was used to sign the
certificate
> > > being validated.
> > >
> > > If that is not clear by today's standard text, then I suggest that
> it
> > > should.
> > >
> > >
> > > Stefan Santesson
> > > Microsoft Security Center of Excellence (SCOE)
> >
> >
> 
>

---

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

Stefan:

I think you are missing the point.  When the relying party matches the DNs
one for (ignoring self-issued certificates), then it know even if the CRL is
signed by different keys, it is a CRL from the same CA.  Of course, the
relying party must enforce an IDP if asserted in the CRL.  But, now, the
rekeyed CA can issue non-IDP CRL and the relying party knows that the CRL is
from the same CA, obviating the need for using the same key.  Essentially,
key match is being replaced by this algorithm.

See specific responses in-line.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Wednesday, September 15, 2004 5:22 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

You miss my point.

I was expressing this generally but of course, in practice we only discuss
the case where a CA is re-keyed without changing its name.

[This is the case (no name change) for which we need the algorithm]

[Right.  That is what I have been saying all along.  Each of the two keys
should be used to sign the full CRL for the scope of all certificates issued
by that CA under all keys.  Furthermore, the same revoked certificate list
(empty or not) should be signed with all active keys.  Active keys are
defined as those CA private keys whose companion public keys can still be
used to verify signatures on the certificates]

I'm not aware of any section in RFC 3280 or X.509 that declare this practice
invalid.

[Which practice you are talking about?  Both RFC 3280 and X.509 states it.
X.509 clearly define that absence of IDP means it is a complete for that CA.
(again delta is an orthogonal issue)  3280 may not state it clearly, but
look at section 6.3.3.b.2 in general and 6.3.3.b.2.i in particular.  You
will reach the same conclusion.]

The RP software that doesn't enforce key match in this instance may now
validate a certificate using the wrong CRL and come to the wrong conclusion.

[This is because the CA generated a partial CRL and did not tell the relying
party.  I think it is inappropriate to argue that when the CA violates the
standard and client follows the standard and security breaks, let us design
a client that also does not follow the standard.]

If a CA and an RP deploys standards compliant configurations and the RP end
up accepting a revoked certificate, this is a vulnerability. 

[If the CA employed standard compliant configuration, it will either assert
an IDP or cover all certificates (e.g., 1-200 in the example I gave few days
back), the relying party will not have a problem.  That is what I have been
saying all along.  The DN matching is simply to tighten up the situation if
the relying party trusts two CAs with the same name some place in its trust
hierarchy.]

[IDP and key match are not related.  MS CA requires that since it does not
follow the standards]

Do we want to fix this problem in this way? That is another question open
for debate...

[As I have said, I do not mind fixing the problem either the way I propose
or the MS does.  I do not have a dog in the fight except to get it right for
my customers.  If we use MS ways, it will break backward compatibility, make
other vendors change, will require a change in the standard, and will remove
a feature regarding signing CRL with different key.  In that case, we might
as well get rid of cRLSign bit.  Also, we will need to deprecate indirect
CRL or using the logic I proposed or something akin or require local policy
o ensure that the indirect issuer is the one certificate issuer recommended.
This is due to the fact that name binding does not ensure you are getting
the object (namely CRL) from the correct name since there may be name
collisions when you have multiple trust anchors or when name uniqueness of
the CAs is not guaranteed in a trust graph (e.g., across multiple tiers of a
trust hierarchy]

Stefan Santesson

> represent different real entities, the relying party is going to have 
> bigger
problem
under
than
with
the
from
number
"CRL
the
said
key
be
after
2,
rely
I
different
no
point
CA
scope
then
certificate

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 15 Sep 2004 07:27:33 -0400

Inline... 

> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> I was expressing this generally but of course, in practice we 
> only discuss the case where a CA is re-keyed without changing 
> its name.
> 
> The security vulnerability is then exposed if those 2 CA's 
> keep issuing CRL's without IDP with scope limited to their 
> respective issued certificates.

IDP is the means of limiting scope.  From 3280, "the issuing distribution
point is a critical CRL extension that identifies the CRL distribution point
and scope for a particular CRL."  If IDP is missing, how are the CAs
limiting scope?  Who is aware of this scope limitation?
 
> I'm not aware of any section in RFC 3280 or X.509 that 
> declare this practice invalid.

The following text from section 5.2.5 of 3280 declares this practice
invalid: "if the distributionPoint field is absent, the CRL MUST contain
entries for all revoked unexpired certificates issued by the CRL issuer, if
any, within the scope of the CRL."  If an IDP is missing, so too is the
distributionPoint field.  Thus, "the CRL MUST contain entries for all
revoked, unexpired certificates issued by the CRL issuer".  An instance
where a CA issues CRLs that covers only certificates issued using a
particular key but does not include an IDP is broken.  The 3280 text is
broken too because the CRL issuer need not be the issuer of the certificates
just because there is no distributionPoint field.
 
> The RP software that doesn't enforce key match in this 
> instance may now validate a certificate using the wrong CRL 
> and come to the wrong conclusion.

While this is true, the problem begins with the CA limiting scope by means
other than IDP.
 
> If a CA and an RP deploys standards compliant configurations 
> and the RP end up accepting a revoked certificate, this is a 
> vulnerability. 
> 
> Now, another FACT is that if validation of CRL without IDP 
> requires key match, then that would solve this vulnerability.

The fact is that without an IDP the CRL must be complete for all
certificates issued by the CRL issuer.  This leads back to the name problem
that is addressed elsewhere in this thread.
 
> Do we want to fix this problem in this way? That is another 
> question open for debate...

I'd vote no to fixing this with key match.  If you want key match, use a
different IDP for each key.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 15 Sep 2004 13:06:12 +0200

>CRL's without IDP with scope limited to their respective issued
I think the previous discussion made it clear that if they have the same 
name, it's not two CA, it's the same CA, and the rekeyed version must in 
the CRL it issues include the certificates that were issued before the 
rekey, whenever applicable.

Likewise, I understand that the matching mechanims Santosh describes is 
a proposed extension to the current standard (maybe more a default 
correction proposition), but one that he has already discussed quite a 
while ago on this list and maybe elsewhere, and that might already have 
achieved some stage of the process of incorporation in the standard.
And that it should be considered Best Practice right now (anyone 
disagrees with that ?).

Also sorry if you saw my previous "Microsoft employees" comment as 
attacking you in any way, it wasn't the intent, I intendend this to be 
in a lightly humorous vein.