Subject: RE: CA Rekey and CRL Validation

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 15 Sep 2004 14:02:04 +0100

Santosh,

Thanks for this interesting dialogue.

I finally got what I needed to get the picture complete.

That is that the standards actually REQUIRE that a CRL without IDP MUST
contain revocation information for all certificates for all instances of
a CA representing all issuing keys. That aspect, if so, was not clear to
me.

I think the standards are in a need for some serious clarifications
around this issue. I'm prety convinced that the writers didn't have this
in mind when writing the text.

This discussion has also revealed that we have practical security and
interoperability issues in installed based of products.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 15 september 2004 13:33
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 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]
> 
> 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.
> 
> [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]
> 
> 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.
> 
> [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.]
> 
> Now, another FACT is that if validation of CRL without IDP requires
key
> match, then that would solve this vulnerability.
> 
> [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
> 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 09:16:08 -0400

Stefan:

See responses in-line.

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

Santosh,

That is that the standards actually REQUIRE that a CRL without IDP MUST
contain revocation information for all certificates for all instances of a
CA representing all issuing keys. That aspect, if so, was not clear to me.

I think the standards are in a need for some serious clarifications around
this issue. I'm prety convinced that the writers didn't have this in mind
when writing the text.

[Since I have been involved in crafting portions of X.509 and since Annex B
that is normative makes this abundantly clear, I beg to differ that it is
not clear enough or authors of the text did not have this in mind.  Any
suggestion to make it clearer in X.509 are welcome.]

[I agree.  I have been saying this since September 2002 when I found out
about it.  My only solution is to change the name when you rekey]

/Stefan

DNs
CRL
the
the
CRL
Essentially,
discuss
issuing
keys
> issued by that CA under all keys.  Furthermore, the same revoked 
> certificate
list
be
> practice invalid.
it.
that
but
You
now
> relying party.  I think it is inappropriate to argue that when the CA 
> violates
the
> design a client that also does not follow the standard.]
> 
RP
> assert an IDP or cover all certificates (e.g., 1-200 in the example I 
> gave
few
> been saying all along.  The DN matching is simply to tighten up the
situation
> trust hierarchy.]
key
not
open
propose
right
compatibility,
> remove a feature regarding signing CRL with different key.  In that 
> case, we might
indirect
> policy o ensure that the indirect issuer is the one certificate issuer
> recommended.
getting
uniqueness of
tiers of
have
"CRL
of
compliant
to
1
that
ever
(eg
keys
interest
and
least
being
is
same
point
than
that

---

From: Julien Pierre <[email-masked]>
Date: Wed, 15 Sep 2004 14:03:50 -0700

>in mind when writing the text.
I think it probably was implicit to the authors, because CRLs before the 
v2 extensions such as IDP were created were always covering the full 
scope of that CA.