Subject: RE: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 12 May 2005 13:56:29 +0100

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: [email-masked]
[mailto:[email-masked]]
> 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: [email-masked]
> [mailto:[email-masked]]
> > 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
> >   >>>
> >   >>
> >   >>
> >   >
> >   >
> >
> >
> >
>

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 19 May 2005 17:01:19 +0100

I do want to understand!

Yes, let's talk in Sophia Antipolis and save some bandwidth on this
list.

Stefan Santesson

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 19 maj 2005 08:57
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Structuring Denis issues RE: Comments on
<draft-ietf-pkix-
> crlaia-00.txt>
> 
> Stefan,
> 
> I'm afraid that you do not want to understand. Since you and me will
be in
> Sophia Antipolis in about one week from now, I propose that we stop to
> discuss on this list now and have a face to face discussion there.
> 
> Denis
> 
> > Denis,
> >
> > I'm afraid that this e-mail from you doesn't help me understand your
> > answer to my question (how your raised issues are related
specifically
> > to the use of the AIA extension in CRLs).
> >
> > The only argument I find in this context is that you fear that the
CRL
> > user would simply accept and trust the certificate they obtain
through
> > this extension.
> >
> > But this would be in violation to RFC 3280 path validation which
> > specifies what you need to do to validate a certificate. These rules
> > apply also to the certificate you obtained through the CRL AIA
extension
> > (It applies to all certificates you want to validate). Thus, an
> > implementation that follows RFC 3280 when validating the certificate
> > they obtained through CRL-AIA will not be subject to
man-in-the-middle
> > attacks and will not "simply use what they got from the pointer".
> >
> > Validation of the CRL Issuer certificate (and its path) is nothing
new.
> > The only difference introduced in this draft is an alternative way
to
> > discover/locate a certificate that can validate the CRL you already
> > picked as a candidate CRL.
> >
> > To incorporate any of your proposed amendments we still need you to
> > explain how each of your issues and proposed resolutions
specifically
> > ties to THAT particular feature introduced by this draft.
> >
> >
> >
> > Stefan Santesson
> >>From: Denis Pinkas [mailto:[email-masked]]
> >>Sent: den 19 maj 2005 08:18
> >>To: Stefan Santesson
> >>Cc: pkix
> >>Subject: Re: Structuring Denis issues RE: Comments on
> >
> > <draft-ietf-pkix-
> >
> >>crlaia-00.txt>
> >>
> >>Stefan,
> >>
> >>
> >>>Denis,
> >>
> >>>Thanks for the clarification.
> >>>Yes, we agree on issue number 1 (remove SHOULD and MUST)
> >>
> >>We also agree on a typo. :-|
> >>
> >>
> >>>So the remaining issue is:
> >>>
> >>>Your proposed resolution
> >>> a) warn the user that the CRL where this extension was found may
> >>
> > not be
> >
> >>>    the right one.
> >>
> >>The AIA extension in found in a CRL that is not yet checked to be
the
> >>right one.
> >>
> >>
> >>> b) warn the user that the CRL issuer certificate he might obtain
> >>
> > using
> >
> >>>    this extension may not be the right one.
> >>
> >>The AIA extension does not provide enough information so that the
CRL
> >>issuer
> >>  certificate that is found there is indeed the right one, since at
> >
> > this
> >
> >>time the certification path is not yet formed. There may be a
> >>man-in-the-middle attack.
> >>
> >>
> >>> c) provide guidance on how to GUARANTEE that the CRL Issuer is
> >>
> > indeed
> >
> >>>    the one nominated by the CA that has issued the target
> >>
> > certificate
> >
> >>>    (i.e. when the CRL Issuer certification path and the target
> >>>    certificate certification path are identical).
> >>
> >>This would indeed be a useful guidance given the two above
statements.
> >>
> >>
> >>> d) say that other possibilities exists, but need additional trust
> >>>    conditions (there are zillions of such possible trust
> >>
> > conditions).
> >
> >>This would indeed be a useful guidance given the previous statement.
> >>
> >>I am spending a *considerable* time on this issue and I believe that
> >
> > you
> >
> >>have now perfectly understood what the problem is.
> >>
> >>You know that I do not consider the AIA extension useful in the
> >
> > "basic"
> >
> >>case.
> >>
> >>Since the other cases (the "zillions" of other cases) rely anyway on
> >>additional local trust conditions, some local configuration values
may
> >
> > be
> >
> >>used to know where to fetch the missing CRL issuer certificates,
hence
> >
> > why
> >
> >>this extension is not really useful and may even be dangerous to be
> >
> > used
> >
> >>if
> >>people simply use what they get from the pointer.
> >>
> >>Denis
> >>
> >>
> >>>To complete the picture it would now be very helpful if you, for
> >>
> > each of
> >
> >>>these statements, could confirm or explain how these issues are a
> >>
> > result
> >
> >>>of using the AIA extension in CRLs. Or in other words, which of
> >>
> > these
> >
> >>>security considerations could you ignore (would go away) if you
were
> >>
> > NOT
> >
> >>>using the AIA extension in a CRL to locate the CRL Issuer
> >>
> > certificate.
> >
> >>>
> >>>
> >>>Stefan Santesson