From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of David A. Cooper
Sent: den 20 september 2004 21:41
To: ietf-pkix@xxxxxxx
Subject: Re: CA Rekey and CRL
Validation
All,
I have been on vacation for the past couple of weeks and have just finished
reading through the messages in this thread. So, I would now like to
comment on some of the issues that have been raised.
First, as David Kemp noted, the text on page 7 is not a definition of CRL
issuer, it is simply describing one of the components depicted in figure
1. Paragraph 3 of section 5 (on page 48) clearly states:
CRL issuers issue CRLs. In general, the CRL issuer is the CA.
CAs
publish CRLs to provide status
information about the certificates
they issued. However, a CA may
delegate this responsibility to
another trusted authority.
Whenever the CRL issuer is not the CA
that issued the certificates, the CRL
is referred to as an indirect
CRL.
As to the main question on this thread, I believe that X.509 is very clear that
a CA is identified by name, not name+key. Here are a few quotes from
X.509:
1.
Section 7: "NOTE 1 – Although the CAs are unambiguously defined
by a distinguished name in the DIT, this does not imply that there is any
relationship between the organization of the CAs and the DIT." [DC: If same DN but different keys
meant different CAs, then CAs would not be unambiguously defined by a DN.]
2. Section
7: "issuer
identifies the entity that has signed and issued the certificate." [DC: note that this says that the issuer field of the certificate identifies the entity, not
issuer field in combination with key]
3. Section
7: "Self-issued certificate – This is a certificate where the issuer
and the subject are the same CA. A CA might use self-issued certificates,
for example, during a key rollover operation to provide trust from the old key
to the new key." [DC:
If CA were defined as name+key, then one would not say that a key rollover
certificate had the same CA as both issuer and subject.]
One is also required to ensure that two different
entities are not assigned the same name:
- Section 8.3.2.1 (subject alternative name
extension): "For every name form used in the GeneralName
type, there shall be a name registration system that ensures that any name
used unambiguously identifies one entity to both certificate issuer and
certificate users."
I realize that some will still argue that X.509 does not explicitly state that
same name = same CA even if it does imply that it is the case. However,
if you are going to suggest that X.509 should be interpreted based on the
assumption that different keys means different CAs, the question I would ask is
where in X.509 (or RFC 3280) is there anything that implies this is the case?
[Stefan] I don’t think anyone is suggesting this
interpretation of X.509. The issue was raised and resolved. There only remains
a suggestion that this should be more directly stated in the standards (not
only indirectly understood from the quotes above).
Some have argued that X.509 has a security vulnerability unless the assumption
is made that different keys means different CAs. However, these
arguments always start with the assumption that one is operating in a PKI in
which there are multiple, independent CAs, all of which are considered to be
valid CAs in the infrastructure and all of which have the same name.
However, in a valid PKI, two different CAs will not have the same name.
So, these people are simply noting that if one operates a PKI in a manner that
is contrary to the rules of X.509 (allowing two different CAs to share the same
name), the PKI will not provide the security assurances promised by
X.509. But, I don't see how one can argue that this indicates a flaw in
X.509.
[Stefan] This is not correct. The argument was based on the
wrong assumption that it was allowed to issue a CRL covering certificates
issued under just 1 CA key, without having IDP present in the CRL. It was
clarified however that this is not supported practice.
Santosh has proposed a restricted path validation algorithm for validating CRL
signing keys (ensuring that the certification path for the CRL signing keys is
similar to the certification path for the certificate being validated) that
mitigates that damage that would result from a PKI in which two CAs share the
same name (i.e., it provides an extra layer of protection). His proposal
mitigates the problem as well as if one required certificates and CRLs to be
signed with the same key. The main reason I agree with Santosh's
proposal, however, is that I don't see any good reason not to impose the
restriction he proposes, while imposing the restriction makes path validation
more efficient since there are fewer possibilities that need to be considered.
[Stefan] I’m OK with this restrictions which also
solves other security issues discussed in ITU (Circular trust)
Dave
Stefan Santesson wrote:
Denis,
On page 59, we have the following sentence:
If the distributionPoint field is absent, the CRL MUST contain
entries for all revoked unexpired certificates *issued* by the CRL
issuer, if any, within the scope of the CRL
This sentence is either ambiguous or incorrect: a CRL issuer does not
*issue* certificates. On page 7, the definition of a CRL issuer is:
CRL issuer: an optional system to which a CA delegates the publication of
certificate revocation lists.
I agree that the definition is not consistent with the standard text in
general. Other sections definitely suggest that the CA can be the CRL
issuer also without delegation.
From 4.2.1.14 CRL Distribution Points:
If the certificate issuer is not the CRL
issuer, then the cRLIssuer field MUST be present and contain the Name
of the CRL issuer. If the certificate issuer is also the CRL issuer,
then the cRLIssuer field MUST be omitted and the distributionPoint
field MUST be present.