RE: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
"Stefan Santesson" <stefans@microsoft.com> Thu, 19 May 2005 16:51 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23987 for <pkix-archive@lists.ietf.org>; Thu, 19 May 2005 12:51:51 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JG1dN0098370; Thu, 19 May 2005 09:01:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JG1dfM098369; Thu, 19 May 2005 09:01:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JG1ZYG098358 for <ietf-pkix@imc.org>; Thu, 19 May 2005 09:01:35 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 May 2005 17:01:29 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Thu, 19 May 2005 17:01:19 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA6299440267C76A@EUR-MSG-11.europe.corp.microsoft.com>
Thread-Topic: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Thread-Index: AcVci0wPlQ2MVD4RSwmFNNn/d9a6+QAAEw0Q
From: Stefan Santesson <stefans@microsoft.com>
To: Denis Pinkas <Denis.Pinkas@bull.net>
Cc: pkix <ietf-pkix@imc.org>
X-OriginalArrivalTime: 19 May 2005 16:01:29.0760 (UTC) FILETIME=[04EACA00:01C55C8C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JG1aYG098364
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit
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@bull.net] > 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@bull.net] > >>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 > >>> > >>> > >>> > >>> > >> > > > > > > >
- Structuring Denis issues RE: Comments on <draft-i… Stefan Santesson
- RE: Structuring Denis issues RE: Comments on <dra… Stefan Santesson
- Re: Structuring Denis issues RE: Comments on <dra… Denis Pinkas
- RE: Structuring Denis issues RE: Comments on <dra… Stefan Santesson
- Re: Structuring Denis issues RE: Comments on <dra… Denis Pinkas
- RE: Structuring Denis issues RE: Comments on <dra… Stefan Santesson
- Re: Structuring Denis issues RE: Comments on <dra… Denis Pinkas
- RE: Structuring Denis issues RE: Comments on <dra… Stefan Santesson