Subject: RE: CA Rekey and CRL Validation

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 14 Sep 2004 11:41:44 +0100

Santosh,

Let's not go too far in this :)

Yes, X.509 has language that implies that one CA is still one CA even if
the key change. But I haven't been able to find anywhere where it is
explicitly stated.

But lets focus on the issue.. The issue at hand however is mainly the
case when you process a CRL without an IDP.

I think we can conclude from your own example that a CRL without IDP is
a security vulnerability UNLESS it MUST be validated with the same key
used to validate the certificate checked for revocation.

Because otherwise if you have a name match but no key match, there is no
way to determine if you hold the appropriate CRL.

My take on this is that it AT LEAST should be stated that a CRL without
IDP must be validated with the same public key used to validate the
certificate being checked for revocation.

I was seeking support for this in the standard and I found so far that
you could argue that this is already supported by the standard (by
defining any CRL not issued with the certificate signing key as an
indirect CRL). 

If the conclusion is that it is NOT supported, then we have a security
defect (CRL without IDP) to deal with.

I'm curious. Is there any implementation out there that will accept a
CRL without IDP on name matching only (no key match)?

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 05:36
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> The standard is very clear in this area.  A CA is defined by the name.
> There is no requirement for a CA to use the same key to sign
certificates
> and CRL.  That is why we have a separate cRLSign bit.
> 
> Take a closer look at discussion of self-issued certificates and tell
me
> that a CA is not defined by name.
> 
> Also, read Annex B of X.509, which is normative.
> 
> Feel like those Watergate days when folks kept on asking where the
smoking
> gun is and we say the room is full of smoke.  It is written all over
X.509
> and 3280 that a CA is defined by name and can use different keys to
sign
> certificates and CRLs.
> 
> I would give you this much.  If I were to write the standard today, I
> would
> use what MS uses or something similar (in order to provide strong and
> simple
> crypto binding between the certificate signer and CRL signer).  But,
to do
> that today, we have to deal with the following:
> 
> 1.  Backward compatibility issues; and
> 2.  Other vendors; and
> 3.  Change the standards
> 
> Without all those, we atheists say that the Earth Remains Round.  Feel
> free
> to excommunicate us and declare the Earth flat.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Monday, September 13, 2004 6:53 PM
> 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)
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 13 september 2004 16:37
> > 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.
> >
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Monday, September 13, 2004 10:18 AM
> > To: Santosh Chokhani
> > Cc: [email-masked]
> > Subject: Re: CA Rekey and CRL Validation
> >
> >
> > Santosh,
> >
> > I have some difficulties to understand what you believe is insecure
> (since
> > the two CRLs do not cover the same set of certificates); and then
how
> IDP
> > would solve the issue. How would you use IDP (copied below ?) :
> >
> >     issuingDistributionPoint ::= SEQUENCE {
> >          distributionPoint          [0] DistributionPointName
> OPTIONAL,
> >          onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
> >          onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
> >          onlySomeReasons            [3] ReasonFlags OPTIONAL,
> >          indirectCRL                [4] BOOLEAN DEFAULT FALSE,
> >          onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
> >
> > Denis
> >
> > > Stefan,
> > >
> > > What is insecure is the following:
> > >
> > > 1 Rekey and no name changes; and
> > > 2 Issuance of different CRLs covering the different sets of
> > > certificates under the same Issuer DN without asserting IDP.
> > >
> > > What I have proposed here are some of the ways to close that
> security
> > > hole.
> > >
> > > -----Original Message-----
> > > From: Stefan Santesson [mailto:[email-masked]]
> > > Sent: Monday, September 13, 2004 9:05 AM
> > > To: Santosh Chokhani; [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > > Santosh,
> > >
> > > This is not necessarily true.
> > > The decision to do a name change or not is more dependent on the
> > > combination of CA software, its configuration and cryptographic
> > > library for clients.
> > >
> > > MS-CAPI is well capable of many usage scenarios where the CA is
> > > re-keyed under the same name. E.g. MS-CAPI is does enforce IDP,
CDP
> > > match.
> > >
> > > /Stefan
> > >
> > >
> > >>-----Original Message-----
> > >>From: [email-masked]
> > >
> > > [mailto:[email-masked]]
> > >
> > >>On Behalf Of Santosh Chokhani
> > >>Sent: den 11 september 2004 14:43
> > >>To: [email-masked]
> > >>Subject: RE: CA Rekey and CRL Validation
> > >>
> > >>
> > >>If your relying parties plan to use MS CAPI, when you re-key a CA,
> > >
> > > change
> > >
> > >>its name.
> > >>
> > >>If you plan to use other toolkits, make sure that they build the
> path
> > >
> > > to
> > >
> > >>CRL
> > >>and match DNs one for one and in sequence (of the certification
path
> > >
> > > to
> > >
> > >>the
> > >>certificate and certification path to the CRL signer) ignoring
> > >
> > > self-issued
> > >
> > >>certificates, but including the DN of the two trust anchors for
the
> > >
> > > two
> > >
> > >>paths.
> > >>
> > >>-----Original Message-----
> > >>From: [email-masked]
> > >
> > > [mailto:[email-masked]]
> > >
> > >>On
> > >>Behalf Of Luciano (Pessoal)
> > >>Sent: Friday, September 10, 2004 4:30 PM
> > >>To: [email-masked]
> > >>Subject: CA Rekey and CRL Validation
> > >>
> > >>
> > >>
> > >>Hi All,
> > >>
> > >>	I have found the following sentence in a Microsoft's paper
> > >>(Troubleshooting Certificate Status and Revocation) and I suppose
> that
> > >
> > > it
> > >
> > >>is
> > >>about the use of cRLIssuer on CRLs and certificates.
> > >>
> > >>"... Important: The Windows operating system family can only
verify
> a
> > >
> > > CRL
> > >
> > >>that was signed by the same private key used to sign the issued
> > >>certificate. The Windows operating system does not support CRLs
> signed
> > >>by an entity other than the CA that signed the issued certificate.
> > >>...."
> > >>
> > >>    My doubt is: What would happen  in the case of a CA Rekey?
> > >>
> > >>    I know by the item "5.1.1.3" from RFC 3280 that a CRL can be
> > >
> > > signed by
> > >
> > >>a
> > >>different key used to sign certificates.
> > >>
> > >>    But, I'm not sure how does this topic fit in the case of CA
> Rekey
> > >>where a CRL is signed with the newer key and the certificates
being
> > >>verified
> > >
> > > was
> > >
> > >>signed with the older.
> > >>
> > >>    In the item "5.1.1.3" we have the text ".....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."
> > >>
> > >>    I think Microsoft is ok considering the validation of
> certificates
> > >
> > > and
> > >
> > >>CRLS signed with different CA private keys is an OPTIONAL feature
> > >
> > > (because
> > >
> > >>of SHOULD). Once, I ask you: What about CA Rekey?
> > >>
> > >>
> > >>    Thanks in advance,
> > >>
> > >>    Luciano Coelho
> > >>
> > >>PS: I'm not concerned about this possible "limitation" on
> Microsoft's
> > >
> > > CRL
> > >
> > >>validation process. I'm interested about how a CA REKEY can
> interfere
> > >
> > > with
> > >
> > >>CRL check/validation.
> > >>
> > >
> > >
> > >
> > >
> >
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 14 Sep 2004 07:56:28 -0400

Stefan:

See responses in-line in [].

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2004 6:42 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

Yes, X.509 has language that implies that one CA is still one CA even if the
key change. But I haven't been able to find anywhere where it is explicitly
stated.

[The reason standard does not have the explicit statement is that X.509 is
very clear in this area and no one even thought that there is an ambiguity
in this area.]

But lets focus on the issue.. The issue at hand however is mainly the case
when you process a CRL without an IDP.

I think we can conclude from your own example that a CRL without IDP is a
security vulnerability UNLESS it MUST be validated with the same key used to
validate the certificate checked for revocation.

[There is no IDP related vulnerability in the CRL.  My example just says and
X.509 is very clear that when you do not assert IDP, the CRL covers all
certificates issued by the name asserted in the Issuer field of the CRL.]

Because otherwise if you have a name match but no key match, there is no way
to determine if you hold the appropriate CRL.

[No IDP means CRL is complete in scope.  Read X.509 and Annex B which is
normative]

My take on this is that it AT LEAST should be stated that a CRL without IDP
must be validated with the same public key used to validate the certificate
being checked for revocation.

[No IDP means CRL is complete in scope.  Read X.509 and Annex B which is
normative].

[Thus, the CA needs to make sure that when it does not assert IDP, the CRL
is full and complete. (We need not complicate this with Delta CRL since that
does not impact this thread).]

I was seeking support for this in the standard and I found so far that you
could argue that this is already supported by the standard (by defining any
CRL not issued with the certificate signing key as an indirect CRL). 

[The standard does not say that a CRL signed by a key other than certificate
signing key is an indirect CRL.]

[There is no security defect in the standard from my analysis.  Standard
needs to clarify how to match the certificate certification path and the CRL
certification path]

I'm curious. Is there any implementation out there that will accept a CRL
without IDP on name matching only (no key match)?

[I think Entrust will and any toolkit that passes NIST PKITS 4.5.6.  Also,
why do not you answer the question about separate cRLSign bit and discourse
on self-issued certificates in X.509 and their role, both of which are
specifically for using different keys for certificate and CRL signing]

Stefan Santesson

certificates
me
smoking
X.509
sign
> would use what MS uses or something similar (in order to provide 
> strong and simple
to do
> free to excommunicate us and declare the Earth flat.
> 
> suggest that you either have the wrong interpretation, or at least use 
> an interpretation that ought to be wrong.
> 
> private issuing keys, are regarded as 1 CA or 2 separate CAs.
> 
same
that
be
that
> extension of the certificate, the CRL shall be signed by the CRL 
> Issuer
identified
shall
extension.
different
certificates
required to
being
is
how
CDP
path
the
verify
being
private