[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Denis,
My main comment to this is that there is no exact definition of what is
"sufficient" in this case.
What is sufficient to you may not be sufficient to me or vice versa.
This issue is as many times when security is the issue a tradeoff. In IT
security you always have the 3 goals:
- Cheep
- Easy to use
- Secure
The sad truth is that we often discover that we can have any 2 of those
but never all 3.
The fact about name uniqueness you provide in the referenced text is a
true facts but it still does not tell me what is sufficient or not in my
environment or how I can achieve reasonable security when the trust
paths differ (in case they have to).
My basic assessment is that there is neither a single truth nor a single
solution to the problem. The chaining to a common root was the
reasonable recommendation agreed at the San Diego PKIX meeting. This is
in my mind not intended to be advertised as a "sufficient" solution,
just good practice to reduce the risk of problems.
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
> >>>
> >>
> >>
> >
> >
>
>
>