RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
Tom Gindin <tgindin@us.ibm.com> Thu, 26 May 2005 03:05 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 XAA28783 for <pkix-archive@lists.ietf.org>; Wed, 25 May 2005 23:05:33 -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 j4Q2MAb6072099; Wed, 25 May 2005 19:22:10 -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 j4Q2MArH072098; Wed, 25 May 2005 19:22:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q2M95m072081 for <ietf-pkix@imc.org>; Wed, 25 May 2005 19:22:09 -0700 (PDT) (envelope-from tgindin@us.ibm.com)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q2M4hh019058 for <ietf-pkix@imc.org>; Wed, 25 May 2005 22:22:04 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4Q2M4hk090058 for <ietf-pkix@imc.org>; Wed, 25 May 2005 22:22:04 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4Q2M4Ec017753 for <ietf-pkix@imc.org>; Wed, 25 May 2005 22:22:04 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q2M3rk017750; Wed, 25 May 2005 22:22:03 -0400
In-Reply-To: <BF9309599A71984CAC5BAC5ECA6299440272BDF5@EUR-MSG-11.europe.corp.microsoft.com>
To: Stefan Santesson <stefans@microsoft.com>
Cc: Santosh Chokhani <chokhani@orionsec.com>, ietf-pkix@imc.org, Julien Stern <julien.stern@cryptolog.com>
MIME-Version: 1.0
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <tgindin@us.ibm.com>
Message-ID: <OF5E1BA903.3853E6BF-ON8525700C.00696300-8525700D.000CFDD5@us.ibm.com>
Date: Wed, 25 May 2005 22:21:59 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/25/2005 22:22:03, Serialize complete at 05/25/2005 22:22:03
Content-Type: text/plain; charset="US-ASCII"
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>
Stefan: I can't find any loop control text on this subject in 3280 or 3280-bis. I don't know what a practical validation library would do with a potential loop like this, and I doubt if anybody who hasn't written such a library knows either. One of the things it might do is note that the certificate is already being validated and assume that its validation result is sufficient. That avoids the loop, at the cost of letting this certificate through. Being sure that the library will encounter a loop depends on the library's author interpreting "Obtain and validate the certification path for the complete CRL issuer" to include calling a revocation check on each element in the path and not assuming that a bad certificate already being validated once will be caught elsewhere in the algorithm. On a related issue, the certpathbuild I-D may be just as involved in our discussions as 3280-bis. Its security considerations section on CRL signer paths is considerably more elaborate than 3280's discussion, and does not consider that terminating at the same trust anchor is good enough. Tom Gindin "Stefan Santesson" <stefans@microsoft.com> 05/25/2005 02:17 PM To: Tom Gindin/Watson/IBM@IBMUS, "Santosh Chokhani" <chokhani@orionsec.com> cc: <ietf-pkix@imc.org>, "Julien Stern" <julien.stern@cryptolog.com> Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, If the substitution would be successful the validation would go into an infinite loop and fail. Validation of S's fake CRL requires validation of C's cross certificate to S which triggers another validation of S's fake CRL and so on. I think we added some text against infinite loops but I don't have it fresh in my memory. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Tom Gindin > Sent: den 25 maj 2005 04:50 > To: Santosh Chokhani > Cc: ietf-pkix@imc.org; 'Julien Stern' > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Santosh: > > A relatively concrete example would be the following: > Assume a trust anchor called A, and CA it has issued a cross > certificate to called C. Further assume that C uses indirect CRL's, and > has issued a cross certificate without name constraints to another CA > called S. Then assume that S goes rogue and creates a CRL signing > certificate with the same name as C uses for its indirect CRL's (the key > pair in that certificate is hereinafter called the "rogue CRL signer"). > Further assume that C finds out about this and creates a CRL listing S as > revoked, but that S successfully replaces that CRL in the repository by > one signed by the rogue CRL signer. > Does RFC 3280 path validation consider S invalid? If so, which > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else > would be likely to cause S to be recognized as invalid? You could > probably patch any difficulties by adding "if the certificate whose > revocation is being checked appears in the path, reject it" to 6.3.3-f. > > Tom Gindin > > > > > > > "Santosh Chokhani" <chokhani@orionsec.com> > 05/24/2005 06:42 PM > > To: Tom Gindin/Watson/IBM@IBMUS, <ietf-pkix@imc.org> > cc: "'Julien Stern'" <julien.stern@cryptolog.com> > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > extension) > > > Tom, > > > I assume you are talking about CRL certification path solution I proposed > will not permit the scenario? I still do not see in your case, if the > Subject CA (cross certified CA) is revoked, you will verify the path to it > in the first place. May be I am not understanding your scenario properly. > How does the revoked CA gets verified? > > > Julien, > > We have defined and proven the solution for how to do this. The scenario > you proposed is not something X.509 worries about (A CA that is still > valid, > but has gone bad). > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On > Behalf Of Julien Stern > Sent: Tuesday, May 24, 2005 3:49 PM > To: Stefan Santesson > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > Tom and Julien, > > > > Since this is a repetition of the discussion we had before San Diego > > and I don't want to repeat it here. I'm not saying that this > > discussion is invalid; it is just directed towards the wrong draft. > > Stefan, > > I agree with you. Actually, I would tend to believe that a _real_ > discussion > would have to take place at some point regarding the overall security > model > of CRL validation, but I have absolutely no objection to the AIA, as soon > as > it is made clear that it's only goal is to simplify path building > implementations, and not to adress security issues. My very humble take on > the subject is that Denis and yourself have been arguing on the list on > absolutely valid but different matters. > > So, I chose not to comment expect for my last mail (and will not any more) > about AIA, but I still think that a discusssion regarding revocation > validation should take place for RFC3280bis, eventually. > > Regards, > > -- > Julien Stern > > > > > As Tom pointed out: > > > this fraudulently issued CRL will probably be validated whether it > > > contains an AIA or not. > > > > This indicates once again that this is not an issue caused by the use > > of AIA in CRLs but a generic CRL validation issue that belongs with > > RFC 3280bis and not with the CRL-AIA draft. > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > > > On Behalf Of Julien Stern > > > Sent: den 24 maj 2005 09:39 > > > To: Tom Gindin > > > Cc: ietf-pkix@imc.org > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > There is one scenario permitted by the "same trust anchor" > > rule > > > > for CRL signers which seems to me to be a serious security hole. > > Let us > > > > assume a valid CA which is a direct subordinate of one of the RP's > > trust > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > usual > > way, > > > > and issues cross certificates. After months or years of > > > > operation, > > it > > > > revokes one of its cross certificates because the subject's > > > > operator > > has > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > Signing certificate with the DN that the superior certificate has > > > > been using > > to > > > > sign ARL's, a public key which it has newly generated, and various > > > > extensions including an SKID. It then issues an updated copy of > > > > an > > old > > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > into > > the > > > > repository where the CRL is expected, this fraudulently issued CRL > > will > > > > probably be validated whether it contains an AIA or not. It will > > > > certainly pass the "same trust anchor" condition. > > > > This scenario, in which a rogue CA issues an ARL > > > > certifiying > > > that > > > > its primary certificate has not been revoked and gets the ARL > > accepted, > > > is > > > > possible under "same trust anchor" but not under "signed by path > > > member". > > > > > > I agree with the validity of this scenario. I believe this is very > > > close to the issue I attempted to bring on the list a short time > > > ago. Of course, it assumes the existence of a rogue CA at some point > > > in > > time. > > > > > > Note that the CRL could be directly inserted into a "long term" > > > signature (according to RFC3126 for example). This does not require > > > a repository break-in and makes the "attack" even more realistic. > > > > > > Regards. > > > > > > -- > > > Julien Stern > > > > > > > > > > > Tom Gindin > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > ----- > > > > > > > > > > > > Tom Gindin > > > > 05/23/2005 10:46 PM > > > > > > > > To: wpolk@nist.gov > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > kent@bbn.com, > > > > stefans@microsoft.com > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > Tim: > > > > > > > > I should probably have brought this up earlier, but are we > > > certain > > > > that "same trust anchor" is a strong enough check that the CRL > > signer is > > > > the one expected by the issuing CA? While I was not in San Diego > > when > > > > this wording was included in the 3280 series, I do not really > > > > think > > that > > > > that check is strong enough. I would suggest instead that the CRL > > > > signer's certificate needs to be directly issued by one of the > > > > CA's > > in > > > the > > > > certification path back to the trust anchor used for the > > certificate's > > > > verification, or by that anchor itself, unless people have > > > > practical experience with CA structures which that rule would > > > > prohibit. > > Forcing > > > the > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > by > > a > > > > hierarchical superior, so it is IMHO too strict. > > > > I am personally not sure, FWIW, that a CRL should be > > permitted > > > to > > > > be signed by a second-cousin certificate of the issuer's > > certificate. > > > By > > > > analogy to the use of the terms in families, "sibling" > > > > certificates > > > would > > > > have the same issuer, "first-cousin" certificates would be issued > > > > by siblings, and "second-cousin" certificates would be issued by > > > > first cousins - so they are both three levels down from the same > > > > trust > > anchor, > > > > or from the last common CA in their paths. This issue is not > > > > newly > > > caused > > > > by CRL AIA, since the same issue can arise with CRL's containing > > only > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > wrong) > > > more > > > > quickly. > > > > In any case, nothing more than a note in Security > > Considerations > > > > is appropriate in any of our RFC's other than 3280 and its > > successor. > > > > > > > > Tom Gindin > > > > P.S. - The above views are mine, and not necessarily those of my > > > employer > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk <tim.polk@nist.gov> > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > 05/10/2005 05:27 PM > > > > > > > > To: ietf-pkix@imc.org > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > housley@vigilsec.com > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > > Information > > Access > > > > CRL > > > > Extension". While some issues raised in the working group are > > > unresolved, > > > > > > > > the editors believe that rough consensus supports the current > > > > specification. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > will > > not > > > > close before May 24. > > > > > > > > Thanks, > > > > > > > > Tim Polk > > > > > > > > > > > > > > > >
- RE: CRL Issue (Was RE: WG Last Call: AIA CRL exte… Stefan Santesson
- RE: CRL Issue (Was RE: WG Last Call: AIA CRL exte… Santosh Chokhani
- RE: CRL Issue (Was RE: WG Last Call: AIA CRL exte… Stefan Santesson
- RE: CRL Issue (Was RE: WG Last Call: AIA CRL exte… Tom Gindin
- RE: CRL Issue (Was RE: WG Last Call: AIA CRL exte… Santosh Chokhani
- RE: CRL Issue (Was RE: WG Last Call: AIA CRL exte… Stefan Santesson