[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Denis,
Reading my own e-mail I think I was not 100% clear on one point.
"Proposed resolution" should read "Denis proposed resolution".
Stefan Santesson
Program Manager, Standards Liaison
Windows Security
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Stefan Santesson
> Sent: den 12 maj 2005 13:24
> To: Denis Pinkas; Russ Housley
> Cc: pkix
> Subject: Structuring Denis issues RE: Comments on
<draft-ietf-pkix-crlaia-
> 00.txt>
>
>
> Denis,
>
> The core of your comments are spread over many emails and opinions may
> have changed on details so I'm not sure I have got the latest picture
of
> your recorded problems and what you propose as resolution.
>
> I'm thus trying to summarize the current complete picture of the last
> call comments below. Please correct me if something is wrong or
missing.
> Note that I'm not arguing here, just trying to structure the issues (I
> will argue in separate mails). Also note that agreed typos are omitted
> from the list:
>
> 1)
> Problem: There are SHOULD and MUST requirements in the security
> considerations section.
>
> Proposed resolution: Reword to make sure we don't use SHOULD or MUST
in
> this section.
>
> -----
> 2)
> Problem: The security considerations talk about "mitigation" of the
name
> collision problem but gives inadequate advice.
>
> Proposed resolution: Either delete all text talking about how to
> mitigate this problem or provide full guidance on what it takes to
> guarantee that a CRL Issuer with a matching name actually is the
> intended CRL Issuer. Also explain that this is not an issue when the
CRL
> Issuer certification path and the target certificate certification
path
> are identical.
>
>
>
>
> 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
> > >>>
> > >>
> > >>
> > >
> > >
> >
> >
> >
>