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

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

I do want to understand!

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


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> 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
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> >>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:
> >>>
> >>>Problem: The security considerations talk about "mitigation" of the
> >>
> > name
> >
> >>>collision problem but gives inadequate advice.
> >>>
> >>>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
> >>>Program Manager, Standards Liaison
> >>>Windows Security
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>