Re: WG Last Call: AIA CRL extension
Tom Gindin <tgindin@us.ibm.com> Tue, 24 May 2005 15:31 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 LAA10868 for <pkix-archive@lists.ietf.org>; Tue, 24 May 2005 11:31:46 -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 j4OEaRbM098522; Tue, 24 May 2005 07:36:27 -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 j4OEaRq9098521; Tue, 24 May 2005 07:36:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OEaPbW098507 for <ietf-pkix@imc.org>; Tue, 24 May 2005 07:36:26 -0700 (PDT) (envelope-from tgindin@us.ibm.com)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEaKQJ028816 for <ietf-pkix@imc.org>; Tue, 24 May 2005 10:36:20 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4OEaKLu144790 for <ietf-pkix@imc.org>; Tue, 24 May 2005 10:36:20 -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 j4OEaJtR003099 for <ietf-pkix@imc.org>; Tue, 24 May 2005 10:36:20 -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 j4OEaJgZ003087 for <ietf-pkix@imc.org>; Tue, 24 May 2005 10:36:19 -0400
To: ietf-pkix@imc.org
MIME-Version: 1.0
Subject: 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: <OFFC5CD11F.470A76B3-ON8525700B.004E1E23-8525700B.005037B6@us.ibm.com>
Date: Tue, 24 May 2005 10:36:16 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/24/2005 10:36:19, Serialize complete at 05/24/2005 10:36:19
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>
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". 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
- WG Last Call: AIA CRL extension Tim Polk
- Re: WG Last Call: AIA CRL extension Tom Gindin
- Re: WG Last Call: AIA CRL extension Tom Gindin
- Re: WG Last Call: AIA CRL extension Denis Pinkas
- Re: WG Last Call: AIA CRL extension Julien Stern
- Re: WG Last Call: AIA CRL extension Jean-Marc Desperrier
- Re: WG Last Call: AIA CRL extension Russ Housley
- RE: WG Last Call: AIA CRL extension Stefan Santesson
- Re: WG Last Call: AIA CRL extension Julien Stern
- CRL Issue (Was RE: WG Last Call: AIA CRL extensio… Santosh Chokhani
- Re: WG Last Call: AIA CRL extension Denis Pinkas
- 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: WG Last Call: AIA CRL extension Stefan Santesson
- Re: WG Last Call: AIA CRL extension Denis Pinkas
- Re: WG Last Call: AIA CRL extension Tim Polk
- 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… Tom Gindin