Subject: Identifying the right CRL for a given certificate

From: "Sarbari Gupta" <[email-masked]>
Date: Wed, 2 Oct 2002 16:30:24 -0400

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>
==============================

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 2 Oct 2002 21:17:47 -0400

Sarbari:

Section 6.3.3 of 3280 does not imply anything regarding your assertions
2a and 2b.  It is not clear to me as to how you arrived at 2a and 2b.
In Section 6.3.3 of 3280, the operative item for the CRL signing key is
bullet f which states:

(f)  Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's

I agree that the RFC is missing guidance on CRL path building.  In my
mind a CRL path must be further constrained by the following rule:

1.  The trust must emanate from the same trust anchor as the
certification path for certificate for which the CRL is being sought.

2.  The DNs for the certification path for the certificate should match
the DNs for the certification path for the CRL (ignoring self-issued
certificates).  Of course, the last DN (namely the subscriber DN) will
be missing from the CRL certification path.

3.  The CRL certification path must be good for the same policy as the
subscriber.

I am not a CA product vendor and hence can not answer your other
questions.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sarbari Gupta
Sent: Wednesday, October 02, 2002 4:30 PM
To: [email-masked]
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.

	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.

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> ==============================

---

From: "Sarbari Gupta" <[email-masked]>
Date: Wed, 2 Oct 2002 23:42:03 -0400

Santosh,

I like the flavor of the new constraints on CRL validation that you have
specified.

You're also right about 2a and 2b. I should probably have expressed them as:

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

However, the point I was trying to make was that in pairing up a certificate
and CRL, 6.3.3 specifies that only the Issuer Name matches are of relevance
(ignoring delta CRLs and partitioned CRLs).

I can think of a simple case where this may be a problem in the current RFC
3280. Assume that the certificate CERT1 asserts the CDP extension with no
cRLIssuer and a single DP field which represents the address for LDAP
retrieval of the associated CRL. There happens to be a CRL CRL2 in the
Relying Party's local cache that has the same Issuer Name as CERT1; however,
CRL2 verifies under a different trust anchor than CERT1. According to RFC
3280, CRL2 is acceptable for CERT1. Intuitively, though, we know this is
incorrect - there needs to be something more than a simple name match and
the ability to verify CRL2 to one of the trust roots. The bottom line is
that pairing up certificates and CRLs based on issuer names without
constraining them to be verifiable under the same trust root, makes 6.3.3
rather weak.

AN ADDITIONAL POINT:
I also think the area of CRL usage and validation (with respect to a given
certificate) needs to be less complex and more specific. For example,
Section 6.3.3 item (2)(b)(i) states:

"If the distribution point name is present in the IDP CRL extension and the
distribution point is omitted from the DP (field of the CDP extension in the
certificate) then verify that one of the names of the IDP matches one of the
names in the cRLIssuer field of the DP."

I don't understand the reason for this complication at all. If the DP field
is not present in the CDP extension in the certificate, why does it make
sense for the CRL IDP extension to have a distribution point name, and why
does this need to match the cRLIssuer field in the certificate?

My suggestion would be to delete this portion of (2)(b)(i) altogether. A
related suggestion would be to require that is the certificate asserts the
DP field in the CDP extension, then the related CRL MUST assert the
distribution point field of the IDP extension and the two must match up in
order to be acceptable as a pair.

- Sarbari

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, October 02, 2002 9:18 PM
To: [email-masked]; [email-masked]
Subject: RE: Identifying the right CRL for a given certificate

Sarbari:

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 3 Oct 2002 20:18:48 -0400

Sarbari:

See my comments in-line in [].

-----Original Message-----
From: Sarbari Gupta [mailto:[email-masked]] 
Sent: Wednesday, October 02, 2002 11:42 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Identifying the right CRL for a given certificate

Santosh,

You're also right about 2a and 2b. I should probably have expressed them
as:

	a) If the same Issuer entity signs both the certificate and the
CRL, then the Issuer Names of both have to match
	b) If different Issuers sign the certificate and CRL,
then the Issuer Name of the CRL has to match the cRLIssuer in the CDP
extension of the certificate.

[I agree]

However, the point I was trying to make was that in pairing up a
certificate and CRL, 6.3.3 specifies that only the Issuer Name matches
are of relevance (ignoring delta CRLs and partitioned CRLs).

I can think of a simple case where this may be a problem in the current
RFC 3280. Assume that the certificate CERT1 asserts the CDP extension
with no cRLIssuer and a single DP field which represents the address for
LDAP retrieval of the associated CRL. There happens to be a CRL CRL2 in
the Relying Party's local cache that has the same Issuer Name as CERT1;
however, CRL2 verifies under a different trust anchor than CERT1.
According to RFC 3280, CRL2 is acceptable for CERT1. Intuitively,
though, we know this is incorrect - there needs to be something more
than a simple name match and the ability to verify CRL2 to one of the
trust roots. The bottom line is that pairing up certificates and CRLs
based on issuer names without constraining them to be verifiable under
the same trust root, makes 6.3.3 rather weak.

[I agree.  That is why I have listed the three rules above]

AN ADDITIONAL POINT:
I also think the area of CRL usage and validation (with respect to a
given
certificate) needs to be less complex and more specific.

[I am not sure it can be made less complex]

For example, Section 6.3.3 item (2)(b)(i) states:

"If the distribution point name is present in the IDP CRL extension and
the distribution point is omitted from the DP (field of the CDP
extension in the
certificate) then verify that one of the names of the IDP matches one of
the names in the cRLIssuer field of the DP."

I don't understand the reason for this complication at all. If the DP
field is not present in the CDP extension in the certificate, why does
it make sense for the CRL IDP extension to have a distribution point
name, and why does this need to match the cRLIssuer field in the
certificate?

[RFC 3280 is correct in this regard.  Here are the answers to your
questions.  If you have a CRL that asserts a DP field in the IDP
extension, the relying party does not know whether it is a full CRL.
Thus, relying party must determine whether the CRL is relevant for the
certificate.  That is where CDP comes in.  Normally, DP in IDP should be
matched with DP in CDP.  But, in order not overload the certificate, if
CDP asserts cRLIssuer, that name is the DP by default unless a full name
or name relative to cRLIssuer is asserted.  Please look at the syntax of
the CDP extension carefully.  Thus, given that the IDP had DP and the
CDP does not, DP in IDP must match the cRLIssuer]

My suggestion would be to delete this portion of (2)(b)(i) altogether.
[That would be WRONG]

A related suggestion would be to require that is the certificate asserts
the DP field in the CDP extension, then the related CRL MUST assert the
distribution point field of the IDP extension and the two must match up
in order to be acceptable as a pair.

[Again, in the area of path processing, just because the certificate
asserts a DP, does not mean you can not use a full CRL, i.e., a CRL that
does not assert DP in IDP.  You should be able to either accept a full
CRL or a CRL whose IDP has the same DP.  I think that is what 3280 is
trying to say.  Thus, rejecting full CRL and only accepting an IDP CRL
in this case will be unnecessarily limiting.  I encourage you to review
Annex B in X.509 for CRL processing.  That may be a bit easier to follow
that 3280.  That Annex also provides some background material to make
the CRL processing more understandable.]

- Sarbari

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, October 02, 2002 9:18 PM
To: [email-masked]; [email-masked]
Subject: RE: Identifying the right CRL for a given certificate

Sarbari:

Section 6.3.3 of 3280 does not imply anything regarding your assertions
2a and 2b.  It is not clear to me as to how you arrived at 2a and 2b. In
Section 6.3.3 of 3280, the operative item for the CRL signing key is
bullet f which states:

---

From: "Sarbari Gupta" <[email-masked]>
Date: Thu, 10 Oct 2002 09:41:53 -0400

Santosh,

As you indicated, the additional constraints on CRL validation should be
added to the PKI standards. Otherwise there seems to be a security hole if
the certificate and CRL are validated up to different trust anchors, while
matching the two based only upon names.

Thanks for your explanation of 6.3.3 (2)(b)(i) related to CRL processing.
While what you wrote makes sense, (assuming that all of the prior decisions
in this portion of the standard makes sense,) it is unfortunate that the
text of the standard leaves so much to interpretation, and familiarity with
the standard's evolution.

One of the problems that I have noticed with the X.509 and PKIX specs is the
tendency to overload fields to mean different things at different times. A
case at point is the overloading of the Distribution Points (DP) field.

Within the CDP extension of a certificate,
	a) the DP field defines the "location" of the CRL regardless of whether it
is a full or partitioned CRL
	b) the Reasons field determines whether the CA issues partitioned CRLs
based upon a subset of the reasons
	c) the cRLIssuer field indicates that the CRL issuer is different from the
certificate issuer

However, in the IDP extension of a CRL
	a) the existence of the DP field signals a partitioned CRL, AS WELL AS the
location of the CRL - WHY IS THIS OVERLOADING DONE?
	b) the onlySomeReasons field also determines whether this is a partitioned
CRL - WHY CAN'T THIS BE THE DEFINITIVE INDICATOR FOR A PARTITIONED CRL
INSTEAD OF THE DP FIELD?
	c) the indirectCRL boolean indicates that the CRL issuer is different from
the certificate issuer

As I indicated before, the CRL handling description of X.509 and PKIX could
definitely be improved in terms of simplicity and clarity.

Respectfully,

- Sarbari
-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, October 03, 2002 8:19 PM
To: [email-masked]; [email-masked]
Subject: RE: Identifying the right CRL for a given certificate

Sarbari:

-----Original Message-----
From: Sarbari Gupta [mailto:[email-masked]]
Sent: Wednesday, October 02, 2002 11:42 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Identifying the right CRL for a given certificate

Santosh,

c
[I agree]

AN ADDITIONAL POINT:

- Sarbari

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, October 02, 2002 9:18 PM
To: [email-masked]; [email-masked]
Subject: RE: Identifying the right CRL for a given certificate

Sarbari:

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 10 Oct 2002 18:43:20 -0400

Sarbari: Please see the responses in-line.

-----Original Message-----
From: Sarbari Gupta [mailto:[email-masked]] 
Sent: Thursday, October 10, 2002 9:42 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Identifying the right CRL for a given certificate

Santosh,

As you indicated, the additional constraints on CRL validation should be
added to the PKI standards. Otherwise there seems to be a security hole
if the certificate and CRL are validated up to different trust anchors,
while matching the two based only upon names.

Thanks for your explanation of 6.3.3 (2)(b)(i) related to CRL
processing. While what you wrote makes sense, (assuming that all of the
prior decisions in this portion of the standard makes sense,) it is
unfortunate that the text of the standard leaves so much to
interpretation, and familiarity with the standard's evolution.

One of the problems that I have noticed with the X.509 and PKIX specs is
the tendency to overload fields to mean different things at different
times. A case at point is the overloading of the Distribution Points
(DP) field.

Within the CDP extension of a certificate,
	a) the DP field defines the "location" of the CRL regardless of
whether it is a full or partitioned CRL
	b) the Reasons field determines whether the CA issues
partitioned CRLs based upon a subset of the reasons
	c) the cRLIssuer field indicates that the CRL issuer is
different from the certificate issuer

However, in the IDP extension of a CRL
	a) the existence of the DP field signals a partitioned CRL, AS
WELL AS the location of the CRL - WHY IS THIS OVERLOADING DONE?
[SC -- The existence of DP field in the CRL means which partition the
CRL is tied to.  Once you have the CRL, you do not need the location.
The purpose is that you have piece of unique information within the
signed envelop that lets you ensure that you have the CRL for the scope
of certificate of interest.  I can not think of a better or simpler
mechanism]
	b) the onlySomeReasons field also determines whether this is a
partitioned CRL - WHY CAN'T THIS BE THE DEFINITIVE INDICATOR FOR A
PARTITIONED CRL INSTEAD OF THE DP FIELD?
[SC -- All this determines is which reasons are covered in the CRL.
This permits you to create e.g., very fast key compromise CRL]
	c) the indirectCRL boolean indicates that the CRL issuer is
different from the certificate issuer

As I indicated before, the CRL handling description of X.509 and PKIX
could definitely be improved in terms of simplicity and clarity.
[SC -- Do you have any editorial suggestions for Annex B of X.509?  If
you do, let me know]

Respectfully,

- Sarbari
-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, October 03, 2002 8:19 PM
To: [email-masked]; [email-masked]
Subject: RE: Identifying the right CRL for a given certificate

Sarbari:

-----Original Message-----
From: Sarbari Gupta [mailto:[email-masked]]
Sent: Wednesday, October 02, 2002 11:42 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Identifying the right CRL for a given certificate

Santosh,

extension of the certificate. c [I agree]

AN ADDITIONAL POINT:

- Sarbari

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, October 02, 2002 9:18 PM
To: [email-masked]; [email-masked]
Subject: RE: Identifying the right CRL for a given certificate

Sarbari: