Subject: Re: Identifying the right CRL for a given certificate

From: "Tom Gindin" <[email-masked]>
Date: Thu, 3 Oct 2002 20:04:26 -0400

Sarbari:

      I have tried to produce a fairly thorough analysis of your problem
#1.  First, the certificate which signs a CRL is most often either the CA
certificate (the original one which signed the EE or a later generation one
signed by that original) or a CRL certificate issued by that same CA.  In
either of these cases, a trust path for the CRL signer could be constructed
so as to lead to the same trust anchor as was used for the EE certificate.
They might lead to different anchors, however, because of the indeterminacy
of tracing a path backward to a trust anchor.  In the simplest case,
suppose that the issuer of an EE certificate also used a CRL signing
certificate which it had issued and had received cross-certificates from 3
different CA's, C1, C2, and C3.  A user who trusted both C1 and C3 could
easily construct paths alternately between the two of them.  While the EE
certificate would be verified against a different anchor than the CRL, it
could equally easily be verified against different anchors on two
successive verifications, which is no less strange a result.  Thus, I would
not consider this case to be a problem.
      It would also be possible, to take a relatively reasonable case, for
a hierarchical subordinate CA to get a CRL signing certificate issued
directly by its hierarchical parent and for the subordinate to be directly
cross-certified by C1 as above while the parent is cross-certified by C3.
In this case, the shortest certification path for the EE certificate is
EE-CA-C1, while the shortest one for the CRL is CRL-H-C3.  The EE can, in
this case, have a path EE-CA-H-C3 as well, but the CRL has no path leading
back to C1.  Again, this is a legitimate situation.
      For an EE certificate and a CRL certificate to be validatable using
separate trust anchors but not to be validatable with any shared trust
anchor, one of two basic conditions seems to be necessary: either the CRL
certificate was issued by an authority which does not trust the issuer
whose certificates the CRL governs, or one of the two certificates violates
a constraint levied by an issuer which must be used in verifying the other
one.  The first of these conditions would seem likeliest to happen if a CRL
signing key was stolen and its certificate reused by a rogue CA, but such a
CA could avoid such difficulties by issuing his own certificate for the CRL
signer.  The second of them is probably more of an issue, since it would
most often occur through the issuance of EE certificates violating a name
or policy constraint placed by the hierarchical parent of the CA issuing
them.  In the sample above, H might place a name constraint on CA which
EE's certificate violates, while C1 would either place no name constraint
or a more permissive one on CA.
      I don't see what would be done about it, however.  Do you think we
should require in RFC 3280 6.3.3 step f that if CRL validation is being
invoked in the context of a certificate validation, the CRL's certification
path may not contain any CA certificates other than those in the base
certificate validation?  If we did that, validation using OCSP could give a
different result than using CRL's even if the OCSP server was being fed by
the same set of CRL's.

            Tom Gindin

"Sarbari Gupta" <[email-masked]>@mail.imc.org on 10/02/2002
04:30:24 PM

Please respond to <[email-masked]>

Sent by:    [email-masked]

To:    <[email-masked]>
cc:
Subject:    Identifying the right CRL for a given certificate

I have been reviewing the RFC 3280 specs to understand how to identify the
correct CRL for a given certificate, and made the following observations:

1) It appears to be possible to validate a certificate along a path that
leads to trust anchor TA1, while validating the CRL for that certificate
along a path that leads to trust anchor TA2. Intuitively, this seems like a
bad idea, however, I have not stumbled across anything in the RFC that
restricts Relying Parties from allowing this behavior.

2) Section 6.3.3 of the RFC seems to indicate that the primary means of
pairing up a certificate with the appropriate CRL are as follows:

             a) If the same key signs both the certificate and the CRL,
then the Issuer
Names of both have to match
             b) If different keys are used to sign the certificate and CRL,
then the
Issuer Name of the CRL has to match the cRLIssuer in the CDP extension of
the certificate

If this observation is coupled with observation (1) above, there seems to
be
a possible security problem in matching on name fields when the certificate
and CRL emanate from different trust roots. This is especially alarming
since most of us have a large number of preloaded trust roots in our
systems, and it is possible that the same DN is used within two different
trust domains, either intentionally or unintentionally.

3) Although it is acceptable that the same or different private keys are
used to sign certificates and CRLs for a given CA, there seems to be no
definition of conforming behavior for Relying Parties that says RPs SHOULD
be able to deal with both scenarios. The result is that certain vendor's
RPs
only support one scenario or the other, leading to non-interoperable
implementations although both are in compliance with the standard.

Am I missing something? I welcome comments.

Also, it would be very interesting to find out how the different vendors
have implemented the functionality to pair up certificates with the correct
CRLs.

==============================
Sarbari Gupta
Electrosoft Services, Inc.
Tel: (703)757-9096
Cell:(703)217-8475
FAX: (703)757-0040
Email:  [email-masked]
Web: <http://www.electrosoft-inc.com>
==============================