[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>>>
>>
>>
>
>