[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Cert and CRL chainbuilding RE: CA Rekey and CRL Validation

To: <ietf-pkix@xxxxxxx>
Subject: RE: Cert and CRL chainbuilding RE: CA Rekey and CRL Validation
From: "Santosh Chokhani" <chokhani@xxxxxxxxxxxx>
Date: Wed, 15 Sep 2004 07:15:06 -0400
Importance: Normal
In-reply-to: <>
List-archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-id: <ietf-pkix.imc.org>
List-unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Sender: owner-ietf-pkix@xxxxxxxxxxxx
Stefan:

I have already drafted the text for X.509.

In addition, I got an agreement on this on this list and with RFC 3280
authors (specifically, Tim Polk and Russ Housley).

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Stefan Santesson
Sent: Wednesday, September 15, 2004 5:30 AM
To: Santosh Chokhani; ietf-pkix@xxxxxxx
Subject: Cert and CRL chainbuilding RE: CA Rekey and CRL Validation



Santosh,

Just for curiosity (not as part of our CRL/IDP debate)

Could help point out the section in RFC 3280 and/or X.509 where it is stated
that beyond name match of the cert and CRL issuer, the RP client must
enforce identical trust paths. 

Or is this en expression of you proposal to X.509?

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 20:58
> To: ietf-pkix@xxxxxxx
> 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: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, September 14, 2004 9:52 AM
> To: Santosh Chokhani; ietf-pkix@xxxxxxx
> 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: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> > On Behalf Of Santosh Chokhani
> > Sent: den 14 september 2004 14:36
> > To: ietf-pkix@xxxxxxx
> > 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: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Tuesday, September 14, 2004 7:09 AM
> > To: Manger, James H; ietf-pkix@xxxxxxx
> > 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: owner-ietf-pkix@xxxxxxxxxxxx
> > [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> > > On Behalf Of Manger, James H
> > > Sent: den 14 september 2004 06:36
> > > To: ietf-pkix@xxxxxxx
> > > 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:stefans@xxxxxxxxxxxxx]
> > > Sent: Tuesday, 14 September 2004 8:53 AM
> > > To: Santosh Chokhani; ietf-pkix@xxxxxxx
> > > 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)
> >
> >
> 
>
References:
- Cert and CRL chainbuilding RE: CA Rekey and CRL Validation
  - From: Stefan Santesson
Prev by Date: RE: CA Rekey and CRL Validation
Next by Date: RE: CA Rekey and CRL Validation
Previous by thread: Cert and CRL chainbuilding RE: CA Rekey and CRL Validation
Next by thread: SCVP CertReply Status
Index(es):
- Date
- Thread