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

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

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
> >
> >
> >
> >
>