Stefan Santesson
Program Manager, Standards Liaison
Windows Security
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Denis Pinkas
Sent: den 12 maj 2005 11:27
To: Russ Housley
Cc: pkix
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Russ,
Since Tim has now made the call at the WG level, please consider this
message as an answer to the call: the current security considerations
section is not acceptable.
> The document already says that the CA and the CRL issuer need to
> terminate at the same trust anchor. This is the important point.
> I disagree that there is anything else that ought to be said in
the
> security considerations.
This statement still does not answer to the point I raised, but
I will nevertheless answer to your statement.
The same trust anchor is not a *sufficient* condition. The same node
in
the
certification tree is the necessary condition. This implies, of
course,
the
same trust anchor, but since two CRL issuers located at different
nodes
(i.e. certified by different CAS) might have the same CRL issuer name,
this
condition is insufficient to solve the issue.
May I recall an extract from the security considerations section of an
approved draft that will be published soon as RFC 4043 ? (this is the
permanent-identifier document):
Subject names in certificates are chosen by the issuing CA and
are
mandated to be unique for each CA; so there can be no name
collision
between subject names from the same CA. Such a name may be an
end-
entity name when the certificate is a leaf certificate, or a CA
name,
when it is a CA certificate.
Since a name is only unique towards its superior CA, unless some
naming constraints are being used, a name would only be
guaranteed
to
be globally unique when considered to include a sequence of all
the
names of the superior CAs. (...)
Additional checks need to be done, e.g., to check if the public
key
values of the two CAs which have issued the certificates to be
compared are identical or if the sequence of CA names in the
certification path from the trust anchor to the CA are
identical.
(...)
The certification of different CAs with the same DN by different
CAs
has other negative consequences in various parts of the PKI,
notably
rendering the IssuerAndSerialNumber structure in [RFC3852]
section
10.2.4 ambiguous.
It speaks for itself, as it applies to CRL Issuers as well. Some parts
of
it should indeed be copied and pasted in the security considerations
section
of the current proposed draft.
When the certification path used to validate the target certificate is
also used to validate the CRL Issuer certificate, then there is no
security
issue: this should be said in the security considerations section.
What about the other cases ? The other cases belong to the category of
indirect CRLs. Depending on the local validation policy checks done or
not
done there may be security issues.
Denis
> Russ
>
> At 02:59 AM 5/10/2005, Denis Pinkas wrote:
>
>> Russ,
>>
>> Your statement below is correct, but does not answer to any of my
>> questions/issues. In particular, the last one. I am still
awaiting
>> your responses.
>>
>> Denis
>>
>>> Denis:
>>> RFC 3280 does not tell an implementor how for locate
certificates
for
>>> any certification path construction. There are several
extensions
>>> that provide pointers that may help an implementation, but other
>>> approaches to obtaining the same certificates are always
permitted.
>>> I would fully expect an implementation to check any local cache
>>> before accessing a repository.
>>> The CRL AIA extension fits this pattern. A method for locating
a
>>> certificate is provided, but any other mechanism for locating
the
>>> same certificate is acceptable.
>>> Russ
>>>
>>>> Stefan,
>>>>
>>>> I made the e-mail shorter. Your main arguments are the
following:
>>>>
>>>>
========================================================================
==
>>>>
>>>>
>>>> [Stefan] But it has to provide a warning to something that is
>>>> introduced
>>>> by the standard. This standard does not introduce the concept
of
CRL
>>>> signature checking or CRL issuer certificate validation, so
that is
>>>> clearly out of scope. More about that below;
>>>>
>>>> [Denis] See below the last answer and also my arguments in the
>>>> soon-to-be-posted answer to Russ.
>>>>
>>>>
========================================================================
==
>>>>
>>>>
>>>>
>>>> > > RFC 3280 [PKIX1] specifies the validation of certification
paths.
>>>> > > One aspect involves the determination that a certificate
has
not
>>>> been
>>>> > > revoked, and one revocation checking mechanism is the
Certificate
>>>> > > Revocation List (CRL). CRL validation is also specified in
RFC
>>>> 3280,
>>>>
>>>> > I would love this last sentence to be true but the reality is
that:
>>>> > "CRL validation is NOT specified in RFC 3280". :-(
>>>>
>>>> [Stefan] In fact it is.
>>>>
>>>> RFC 3280, Section 6.3.3 CRL processing - on page 85:
>>>>
>>>> (f) Obtain and validate the certification path for the
complete
CRL
>>>> issuer. If a key usage extension is present in the CRL
issuer's
>>>> certificate, verify that the cRLSign bit is set.
>>>>
>>>> (g) Validate the signature on the complete CRL using the
public
key
>>>> validated in step (f).
>>>>
>>>> [Denis] The text does not say how to obtain and validate the
>>>> certification path for the complete (???) CRL issuer. The text
is
>>>> not clear enough so that two implementors only looking at this
>>>> sentence will provide interoperable implementations.
>>>>
>>>>
========================================================================
==
>>>>
>>>>
>>>> [Stefan] It is my hope that the provided responses here can
help
>>>> convince you to change your mind about that. If it doesn't I
still
>>>> argue
>>>> that the place to specify requirements and security
considerations
for
>>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL
draft.
>>>>
>>>> [Denis] I can agree with your last sentence, ... which means
that
it
>>>> should not be in the main body of the document. In the security
>>>> considerations section, text is free and we shall at the very
>>>> minimum warn implementers and we should provide some guidance.
When
>>>> the same certification path (i.e. the path used to validate the
>>>> target certificate) is used, then there is no security issue:
this
>>>> should be said. For all other cases, there MAY be problems:
this
>>>> should also be said. It is as simple as that.
>>>>
>>>> Denis
>>>
>>
>>
>
>