From owner-ietf-pkix@mail.imc.org Wed Jun 4 07:46:12 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F5C3A6806 for ; Wed, 4 Jun 2008 07:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gzp4nfbNAS2 for ; Wed, 4 Jun 2008 07:46:06 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6ADC13A67A7 for ; Wed, 4 Jun 2008 07:46:02 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m54DrF4v025270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 06:53:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m54DrFMd025269; Wed, 4 Jun 2008 06:53:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from prospect.joyent.us (prospect.joyent.us [8.12.36.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m54DrDNh025250; Wed, 4 Jun 2008 06:53:13 -0700 (MST) (envelope-from pmhesse@geminisecurity.com) Received: from PeterVT43 (static-68-163-72-26.res.east.verizon.net [68.163.72.26]) by prospect.joyent.us (Postfix) with ESMTP id 07AF288883; Wed, 4 Jun 2008 13:53:11 +0000 (GMT) From: "Peter Hesse" To: "'pkix'" , Subject: Web-based ASN.1 decoding tool available Date: Wed, 4 Jun 2008 09:53:10 -0400 Message-ID: <50a001c8c64a$543e55b0$fcbb0110$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_50A1_01C8C628.CD2CB5B0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcjGSlK0B56RJ/K4QmuS9tqZTIyH0A== Content-Language: en-us Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_50A1_01C8C628.CD2CB5B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, We have recently made available a web-based tool for doing an ASN.1 dump. It displays the ASCII HEX and the ASN structure, and when you hover over the structure, it highlights the relevant portion of the hex. (Clicking makes the highlight stick.) Due to PHP's inefficiency and memory usage during parsing, we have limited it to files 64K and smaller. Still, it is useful for displaying smaller objects when you don't have dumpasn1 installed or available. It can be found here: http://geminisecurity.com/features-downloads/tools#fd_5 Click on "Click to try the application" under PHPdumpASN. Enjoy! Please send me any feedback. --Peter Hesse _____ Peter Hesse pmhesse@geminisecurity.com Phone: 703-378-5808 x105 Gemini Security Solutions, Inc. Visit our relaunched website! http://geminisecurity.com "A good programmer is someone who always looks both ways before crossing a one-way street." --Doug Linder ------=_NextPart_000_50A1_01C8C628.CD2CB5B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

We have recently made available a web-based tool = for doing an ASN.1 dump.  It displays the ASCII HEX and the ASN structure, = and when you hover over the structure, it highlights the relevant portion of the = hex.  (Clicking makes the highlight stick.)

 

Due to PHP’s inefficiency and memory usage = during parsing, we have limited it to files 64K and smaller.  Still, it is = useful for displaying smaller objects when you don’t have dumpasn1 installed or = available.

 

It can be found here: http://g= eminisecurity.com/features-downloads/tools#fd_5

Click on “Click to try the application” = under PHPdumpASN.

 

Enjoy!  Please send me any = feedback.

 

--Peter Hesse

 

 Peter Hesse           &n= bsp;           pmhesse@gemini= security.com

 Phone: = 703-378-5808 x105      Gemini Security Solutions, = Inc.

    Visit our relaunched website! http://geminisecurity.com

"A good programmer is someone who always looks both = ways before
 crossing a one-way street." --Doug = Linder

 

------=_NextPart_000_50A1_01C8C628.CD2CB5B0-- From owner-ietf-pkix@mail.imc.org Wed Jun 4 09:55:58 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B3A28C1E7 for ; Wed, 4 Jun 2008 09:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUHBcshEyMsY for ; Wed, 4 Jun 2008 09:55:54 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EF16828C1F1 for ; Wed, 4 Jun 2008 09:54:42 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m54G3q28053226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 09:03:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m54G3q8Z053224; Wed, 4 Jun 2008 09:03:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m54G3pg0053206 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Wed, 4 Jun 2008 09:03:52 -0700 (MST) (envelope-from aramp@qualcomm.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=aramp@qualcomm.com; q=dns/txt; s=qcdkim; t=1212595432; x=1244131432; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Perez,=20Aram"=20|To:=20PKI X=20,=20"ietf-smime@imc.org"=20|Date:=20Wed,=204=20Jun=202008=2009:03:47=20 -0700|Subject:=20Re:=20Web-based=20ASN.1=20decoding=20too l=20available|Thread-Topic:=20Web-based=20ASN.1=20decodin g=20tool=20available|Thread-Index:=20AcjGSlK0B56RJ/K4QmuS 9tqZTIyH0AAEj9f7|Message-ID:=20|In-Reply-To:=20<50a001c8c64a$543e55b0$fcbb0110$@ com>|Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C46C0AF3F950arampqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 200,2160,5309"=3B=20a=3D"3673079"; bh=AnTuq5KFYeB8xBRr15aB8mR9qciaTkpwkm7gN2kPfvM=; b=hcsaii9veicIk67RE2REQPaG/uvkRsUraHECzsRIpx6RQ+Z+2gU0PTSL 9cl681oGsRAtxuuNw+DWz5WstKzAMtEEbagdYh8IAtV90grXLXT73cAWf CqetJeMUugnnADdBKy4I1s5AKs/Bzp5SGbbWx7Qc6ttwu7hmmghRMLMF9 A=; X-IronPort-AV: E=McAfee;i="5200,2160,5309"; a="3673079" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jun 2008 09:03:51 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m54G3p6Y004910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Jun 2008 09:03:51 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m54G3oR9025029 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Jun 2008 09:03:51 -0700 Received: from nasanex01a.na.qualcomm.com (129.46.132.246) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 4 Jun 2008 09:03:50 -0700 Received: from NASANEXMB05.na.qualcomm.com ([129.46.52.178]) by nasanex01a.na.qualcomm.com ([129.46.132.246]) with mapi; Wed, 4 Jun 2008 09:03:50 -0700 From: "Perez, Aram" To: PKIX , "ietf-smime@imc.org" Date: Wed, 4 Jun 2008 09:03:47 -0700 Subject: Re: Web-based ASN.1 decoding tool available Thread-Topic: Web-based ASN.1 decoding tool available Thread-Index: AcjGSlK0B56RJ/K4QmuS9tqZTIyH0AAEj9f7 Message-ID: In-Reply-To: <50a001c8c64a$543e55b0$fcbb0110$@com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C46C0AF3F950arampqualcommcom_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_C46C0AF3F950arampqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 6/4/08 6:53 AM, Peter Hesse wrote: > All, > > We have recently made available a web-based tool for doing an ASN.1 dump.= It > displays the ASCII HEX and the ASN structure, and when you hover over the > structure, it highlights the relevant portion of the hex. (Clicking makes= the > highlight stick.) > > Due to PHP's inefficiency and memory usage during parsing, we have limite= d it > to files 64K and smaller. Still, it is useful for displaying smaller obj= ects > when you don't have dumpasn1 installed or available. > > It can be found here: http://geminisecurity.com/features-downloads/tools#= fd_5 > Click on "Click to try the application" under PHPdumpASN. For Windows, you can also try BERViewer . I haven'= t had time to remove the nag dialog box from the Mac version. Regards, Aram Perez --_000_C46C0AF3F950arampqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Web-based ASN.1 decoding tool available O= n 6/4/08 6:53 AM, Peter Hesse  wrote:

> All,
>  
> We have recently made available a web-based tool for doing an ASN.1 du= mp.  It
> displays the ASCII HEX and the ASN structure, and when you hover over = the
> structure, it highlights the relevant portion of the hex. (Clicking ma= kes the
> highlight stick.)
>  
> Due to PHP’s inefficiency and memory usage during parsing, we ha= ve limited it
> to files 64K and smaller.  Still, it is useful for displaying sma= ller objects
> when you don’t have dumpasn1 installed or available.
>  
> It can be found here: http://geminisecurity.com/features-downloads/tools#fd_5=
> Click on “Click to try the application” under PHPdumpASN.<= BR>
For Windows, you can also try BERViewer <http://homepage.mac.com/aramperez/berviewer.h= tml>. I haven’t had time to remove the nag dialog box from the= Mac version.

Regards,
Aram Perez
 --_000_C46C0AF3F950arampqualcommcom_-- From owner-ietf-pkix@mail.imc.org Thu Jun 5 07:15:11 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6083A6D25 for ; Thu, 5 Jun 2008 07:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu1xvdaj-BUH for ; Thu, 5 Jun 2008 07:15:10 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0F37D3A6844 for ; Thu, 5 Jun 2008 07:14:18 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55DNtrn059437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 06:23:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m55DNtur059436; Thu, 5 Jun 2008 06:23:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55DNqHj059413; Thu, 5 Jun 2008 06:23:53 -0700 (MST) (envelope-from rybar@nbusr.sk) Message-Id: <200806051325.m55DPCtJ009671@mail.nbusr.sk> From: "Peter Rybar" To: "'Perez, Aram'" , "'PKIX'" , ietf-smime@imc.org Subject: RE: Web-based ASN.1 decoding tool available Date: Thu, 5 Jun 2008 15:24:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcjGSlK0B56RJ/K4QmuS9tqZTIyH0AAEj9f7ACxVXxA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-NAI-Spam-Score: 0 X-NAI-Spam-Report: 2 Rules triggered * 0 -- MISSING_MSGID -- Missing Message-ID header * 0 -- RV3031 -- BODY: Version number Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Have you any free tools which are not the simple dump of asn1 DER/BER = but which also can read a data according the 1988, 93 ASN.1 Syntax?=20 Like default values from DER... Peter -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram Sent: Wednesday, June 04, 2008 6:04 PM To: PKIX; ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available On 6/4/08 6:53 AM, Peter Hesse wrote: > All, > =20 > We have recently made available a web-based tool for doing an ASN.1 = dump. It=20 > displays the ASCII HEX and the ASN structure, and when you hover over = the=20 > structure, it highlights the relevant portion of the hex. (Clicking = makes the=20 > highlight stick.) > =20 > Due to PHP=E2=80=99s inefficiency and memory usage during parsing, we = have limited it=20 > to files 64K and smaller. Still, it is useful for displaying smaller = objects=20 > when you don=E2=80=99t have dumpasn1 installed or available. > =20 > It can be found here: = http://geminisecurity.com/features-downloads/tools#fd_5 > Click on =E2=80=9CClick to try the application=E2=80=9D under = PHPdumpASN. For Windows, you can also try BERViewer = = . I haven=E2=80=99t = had time to remove the nag dialog box from the Mac version. Regards, Aram Perez From owner-ietf-pkix@mail.imc.org Thu Jun 5 07:55:53 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48A9228C252 for ; Thu, 5 Jun 2008 07:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTDY9UWSKVgT for ; Thu, 5 Jun 2008 07:55:52 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A891428C2CB for ; Thu, 5 Jun 2008 07:53:55 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55E3IHY068344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 07:03:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m55E3IZA068343; Thu, 5 Jun 2008 07:03:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.68]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55E3GL1068331; Thu, 5 Jun 2008 07:03:17 -0700 (MST) (envelope-from aramperez@mac.com) Received: from asmtp016-bge351000 (asmtp016-bge351000 [10.150.69.79]) by smtpoutm.mac.com (Xserve/smtpout005/MantshX 4.0) with ESMTP id m55E3G21024009; Thu, 5 Jun 2008 07:03:16 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ)" Received: from [192.168.1.3] ([76.88.67.30]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K1Z00M9UTPD0P20@asmtp016.mac.com>; Thu, 05 Jun 2008 07:03:16 -0700 (PDT) Message-id: <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> From: Aram Perez To: PKIX , ietf-smime@imc.org In-reply-to: <200806051325.m55DPCtJ009671@mail.nbusr.sk> Subject: Re: Web-based ASN.1 decoding tool available Date: Thu, 05 Jun 2008 07:03:12 -0700 References: <200806051325.m55DPCtJ009671@mail.nbusr.sk> X-Mailer: Apple Mail (2.924) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ) Content-type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-transfer-encoding: quoted-printable Hi Peter, > > Have you any free tools which are not the simple dump of asn1 DER/=20 > BER but which also can read a data according the 1988, 93 ASN.1 =20 > Syntax? > Like default values from DER... I'm afraid I do not and I'm not aware of any such tool. To get the =20 default values, you would need the actual ASN.1 (which provides the =20 default values) and the BER/DER data. BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others =20= similar tools just decode the BER/DER and present it in a "more" human =20= readable form. Regards, Aram > > > Peter > > > > -----Original Message----- > From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org=20 > ] On Behalf Of Perez, Aram > Sent: Wednesday, June 04, 2008 6:04 PM > To: PKIX; ietf-smime@imc.org > Subject: Re: Web-based ASN.1 decoding tool available > > On 6/4/08 6:53 AM, Peter Hesse wrote: > >> All, >> >> We have recently made available a web-based tool for doing an ASN.1 =20= >> dump. It >> displays the ASCII HEX and the ASN structure, and when you hover =20 >> over the >> structure, it highlights the relevant portion of the hex. (Clicking =20= >> makes the >> highlight stick.) >> >> Due to PHP=92s inefficiency and memory usage during parsing, we have =20= >> limited it >> to files 64K and smaller. Still, it is useful for displaying =20 >> smaller objects >> when you don=92t have dumpasn1 installed or available. >> >> It can be found here: = http://geminisecurity.com/features-downloads/tools#fd_5 >> Click on =93Click to try the application=94 under PHPdumpASN. > > For Windows, you can also try BERViewer = > . I haven=92t had = =20 > time to remove the nag dialog box from the Mac version. > > Regards, > Aram Perez > > > --Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ) Content-type: text/html; charset=WINDOWS-1252 Content-transfer-encoding: quoted-printable Hi Peter,

Have you any free tools which are not the = simple dump of asn1 DER/BER but which also can read a data according the = 1988, 93 ASN.1 Syntax?
Like default values from = DER...

I'm afraid I do not and I'm = not aware of any such tool. To get the default values, you would need = the actual ASN.1 (which provides the default values) and the BER/DER = data.

BERViewer, Peter Hesse's web tool, Peter = Gutmann's dumpasn1 and others similar tools just decode the BER/DER and = present it in a "more" human readable = form.

Regards,
Aram



Peter



-----Original= Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail= .imc.org] On Behalf Of Perez, Aram
Sent: Wednesday, June 04, 2008 = 6:04 PM
To: PKIX; ietf-smime@imc.org
Subject: = Re: Web-based ASN.1 decoding tool available

On 6/4/08 6:53 AM, = Peter Hesse  wrote:

All,

We have = recently made available a web-based tool for doing an ASN.1 dump. =  It
displays the ASCII = HEX and the ASN structure, and when you hover over the =
structure, it highlights the = relevant portion of the hex. (Clicking makes the =
highlight = stick.)

Due to PHP=92s = inefficiency and memory usage during parsing, we have limited it =
to files 64K and smaller. =  Still, it is useful for displaying smaller objects =
when you don=92t have = dumpasn1 installed or available.

It can be found = here: http://ge= minisecurity.com/features-downloads/tools#fd_5
Click on =93Click to try the application=94 under = PHPdumpASN.

For Windows, you can also try BERViewer = <http://homepage.= mac.com/aramperez/berviewer.html> <http://homepage.= mac.com/aramperez/berviewer.html> . I haven=92t had time to remove = the nag dialog box from the Mac version.

Regards,
Aram = Perez




= --Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ)-- From owner-ietf-pkix@mail.imc.org Thu Jun 5 08:35:52 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CF13A69A8 for ; Thu, 5 Jun 2008 08:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPbiskFmHO6l for ; Thu, 5 Jun 2008 08:35:46 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 435EE3A6866 for ; Thu, 5 Jun 2008 08:35:45 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55EYq2S075364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 07:34:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m55EYqBj075362; Thu, 5 Jun 2008 07:34:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55EYn7c075337; Thu, 5 Jun 2008 07:34:50 -0700 (MST) (envelope-from rybar@nbusr.sk) Message-Id: <200806051436.m55EaAf9010452@mail.nbusr.sk> From: "Peter Rybar" To: "'Aram Perez'" , "'PKIX'" , ietf-smime@imc.org Subject: RE: Web-based ASN.1 decoding tool available Date: Thu, 5 Jun 2008 16:35:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcjHGW+R09LPo1xoT+u+1UI0FfXXTQAALrmQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> X-NAI-Spam-Level: * X-NAI-Spam-Score: 1 X-NAI-Spam-Report: 3 Rules triggered * 1 -- INFO_TLD -- URI: Contains a URL in the INFO top-level domain * 0 -- MISSING_MSGID -- Missing Message-ID header * 0 -- RV3031 -- BODY: Version number Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, This one is also nice...=20 And somebody could try to use it in online PHP :-) with at least ASN.1 = modules which are described in PKIX, SMIME RFCs. http://lionet.info/asn1c/ Peter -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Aram Perez Sent: Thursday, June 05, 2008 4:03 PM To: PKIX; ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available Hi Peter, =09 Have you any free tools which are not the simple dump of asn1 DER/BER = but which also can read a data according the 1988, 93 ASN.1 Syntax?=20 Like default values from DER... I'm afraid I do not and I'm not aware of any such tool. To get the = default values, you would need the actual ASN.1 (which provides the = default values) and the BER/DER data. BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others = similar tools just decode the BER/DER and present it in a "more" human = readable form. Regards, Aram Peter =09 =09 =09 -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram Sent: Wednesday, June 04, 2008 6:04 PM To: PKIX; ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available =09 On 6/4/08 6:53 AM, Peter Hesse wrote: =09 =09 All, =09 We have recently made available a web-based tool for doing an ASN.1 = dump. It=20 =09 displays the ASCII HEX and the ASN structure, and when you hover over = the=20 =09 structure, it highlights the relevant portion of the hex. (Clicking = makes the=20 =09 highlight stick.) =09 Due to PHP=E2=80=99s inefficiency and memory usage during parsing, we = have limited it=20 =09 to files 64K and smaller. Still, it is useful for displaying smaller = objects=20 =09 when you don=E2=80=99t have dumpasn1 installed or available. =09 It can be found here: = http://geminisecurity.com/features-downloads/tools#fd_5 =09 Click on =E2=80=9CClick to try the application=E2=80=9D under = PHPdumpASN. =09 For Windows, you can also try BERViewer = = . I haven=E2=80=99t = had time to remove the nag dialog box from the Mac version. =09 Regards, Aram Perez =09 =09 =09 =09 From owner-ietf-pkix@mail.imc.org Thu Jun 5 10:51:16 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BABE28C10F for ; Thu, 5 Jun 2008 10:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5Np0jfksIaN for ; Thu, 5 Jun 2008 10:51:14 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 186E53A6D26 for ; Thu, 5 Jun 2008 10:50:38 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55HEp2D008659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 10:14:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m55HEpnC008657; Thu, 5 Jun 2008 10:14:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.multicert.com (mail.multicert.com [62.48.217.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55HEmPi008641; Thu, 5 Jun 2008 10:14:49 -0700 (MST) (envelope-from ricardo.barroso@multicert.com) Received: from 10.0.0.194 (webmail.multicert.com [10.0.0.194]) by mail.multicert.prod (Postfix) with SMTP id D7DB072E46; Thu, 5 Jun 2008 18:14:47 +0100 (WEST) X-Spambayes-Classification: unsure; 0.26 Received: from teste.multicert.com (unknown [62.48.177.165]) by mail.multicert.com (Postfix) with ESMTP id E07E272F2E; Thu, 5 Jun 2008 18:14:45 +0100 (WEST) Received: from [192.168.10.88] (unknown [192.168.10.88]) by teste.multicert.com (Postfix) with ESMTP id 1025D5B764; Thu, 5 Jun 2008 18:14:44 +0100 (WEST) Message-ID: <48481F06.5010301@multicert.com> Date: Thu, 05 Jun 2008 18:14:46 +0100 From: Ricardo Barroso User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Aram Perez Cc: PKIX , ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available References: <200806051325.m55DPCtJ009671@mail.nbusr.sk> <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> In-Reply-To: <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> Content-Type: multipart/alternative; boundary="------------020908070306050005030907" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------020908070306050005030907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi all! I would like to mention ASN.1 Editor (for Windows) which is not a web-based tool and although it can't provide default values from DER, it lets you: - inspect ASN.1 structures and encapsulate parts of the structures in a more user-friendly way than simple dump tools; - edit ASN.1 structures; - save sub-parts/structures to a new file; - etc. It also includes a simple but nice data converter between PEM, HEX and BASE64 formats. Best regards, Ricardo Barroso Aram Perez wrote: > Hi Peter, >> >> Have you any free tools which are not the simple dump of asn1 DER/BER >> but which also can read a data according the 1988, 93 ASN.1 Syntax? >> Like default values from DER... > > I'm afraid I do not and I'm not aware of any such tool. To get the > default values, you would need the actual ASN.1 (which provides the > default values) and the BER/DER data. > > BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others > similar tools just decode the BER/DER and present it in a "more" human > readable form. > > Regards, > Aram > >> >> >> Peter >> >> >> >> -----Original Message----- >> From: owner-ietf-smime@mail.imc.org >> [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram >> Sent: Wednesday, June 04, 2008 6:04 PM >> To: PKIX; ietf-smime@imc.org >> Subject: Re: Web-based ASN.1 decoding tool available >> >> On 6/4/08 6:53 AM, Peter Hesse wrote: >> >>> All, >>> >>> We have recently made available a web-based tool for doing an ASN.1 >>> dump. It >>> displays the ASCII HEX and the ASN structure, and when you hover >>> over the >>> structure, it highlights the relevant portion of the hex. (Clicking >>> makes the >>> highlight stick.) >>> >>> Due to PHP’s inefficiency and memory usage during parsing, we have >>> limited it >>> to files 64K and smaller. Still, it is useful for displaying >>> smaller objects >>> when you don’t have dumpasn1 installed or available. >>> >>> It can be found here: >>> http://geminisecurity.com/features-downloads/tools#fd_5 >>> Click on “Click to try the application” under PHPdumpASN. >> >> For Windows, you can also try BERViewer >> >> . I haven’t had >> time to remove the nag dialog box from the Mac version. >> >> Regards, >> Aram Perez >> >> >> > -- * Ricardo Barroso* *Telefone:* +351 217 123 010 *Telemóvel:* +351 968 332 327 *Fax:* +351 217 123 011 *Email:* ricardo.barroso@multicert.com *MULTICERT S.A.* Estrada do Casal do Canas, Lote 6, Alfragide 2720-092 Amadora - Portugal --------------020908070306050005030907 Content-Type: multipart/related; boundary="------------060705050402080307010006" --------------060705050402080307010006 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi all!

I would like to mention ASN.1 Editor (for Windows) which is not a web-based tool and although it can't provide default values from DER,
it lets you:
    - inspect ASN.1 structures and encapsulate parts of the structures in a more user-friendly way than simple dump tools;
    - edit ASN.1 structures;
    - save sub-parts/structures to a new file;
    - etc.

It also includes a simple but nice data converter between PEM, HEX and BASE64 formats.

Best regards,
Ricardo Barroso


Aram Perez wrote:
Hi Peter,

Have you any free tools which are not the simple dump of asn1 DER/BER but which also can read a data according the 1988, 93 ASN.1 Syntax?
Like default values from DER...

I'm afraid I do not and I'm not aware of any such tool. To get the default values, you would need the actual ASN.1 (which provides the default values) and the BER/DER data.

BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others similar tools just decode the BER/DER and present it in a "more" human readable form.

Regards,
Aram



Peter



-----Original Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram
Sent: Wednesday, June 04, 2008 6:04 PM
To: PKIX; ietf-smime@imc.org
Subject: Re: Web-based ASN.1 decoding tool available

On 6/4/08 6:53 AM, Peter Hesse  wrote:

All,

We have recently made available a web-based tool for doing an ASN.1 dump.  It
displays the ASCII HEX and the ASN structure, and when you hover over the
structure, it highlights the relevant portion of the hex. (Clicking makes the
highlight stick.)

Due to PHP’s inefficiency and memory usage during parsing, we have limited it
to files 64K and smaller.  Still, it is useful for displaying smaller objects
when you don’t have dumpasn1 installed or available.

It can be found here: http://geminisecurity.com/features-downloads/tools#fd_5
Click on “Click to try the application” under PHPdumpASN.

For Windows, you can also try BERViewer <http://homepage.mac.com/aramperez/berviewer.html> <http://homepage.mac.com/aramperez/berviewer.html> . I haven’t had time to remove the nag dialog box from the Mac version.

Regards,
Aram Perez






--
MySignatura2008
    Ricardo Barroso
Telefone: +351 217 123 010
Telemóvel: +351 968 332 327
Fax: +351 217 123 011		 Email:
ricardo.barroso@multicert.com		 MULTICERT S.A.
Estrada do Casal do Canas,
 Lote 6, Alfragide
2720-092 Amadora - Portugal

--------------060705050402080307010006 Content-Type: image/jpeg; name="MailLogoMULTICERT.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="MailLogoMULTICERT.jpg" /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CAAtAaYDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDkKdHTadHX0h8eiylTpUCVOlSzRFmOp46g jqeOoZoixHVlOgqtHVlOgrNmiJ0qzHVZKsx1mzVFiPtU8dQR9qnjqGaIsrU6VAtTpUGqLMdW EqvHVhKzZoiwnarCVXTtVhKhmqLMfap4+tQR9qnj61DNEWI6njqCOp46zZqiynSn0xOlPqDQ KKKKACiiigAooooAKKKKACimu6xozuwVFGWYnAA9a4ab4v8Ag+KZ4/ts8gU43pbsVP0OKlyU d2a06FSr/Di36Hd0VzGo+P8AQdJsrO5vpZ4TdrvihaE+bt/vFeqj61BpfxK8MavqEVjb3kiT ynbGJYigY9hk8ZrZUako86i7HPKpCMuST1OuopryJEu6R1RfVjgUoIYAggg8gisyxaKYZog5 QyoGAyV3DIFEcscoJjkVwOpU5oHYfRUfnw7ynmx7h1XcMiljmjlBMciPjrtYHFAWY+ioTd2w JBuIgR1G8Uoubds7Z4zgZOHHAoCzJaKakkcq7o3Vx0ypzTGurdSQ08QI6guKAsyWiml0Cbyy 7MZ3Z4xTFurd2CrPEzHoA4JNAWZLRUP2u2/5+Iv++xUiSxyjMbq4HdTmgLMdRUP2u2/5+If+ +xTo54pSRHKjkddrA0BZklFFFAj5Rp0dNp0dfSHx6LKVOlQJU6VLNEWY6njqCOp46hmiLEdW U6Cq0dWU6Cs2aInSrMdVkqzHWbNUWI+1Tx1BH2qeOoZoiytTpUC1OlQaosx1YSq8dWErNmiL CdqsJVdO1WEqGaosx9qnj61BH2qePrUM0RYjqeOoI6njrNmqLKdKfTE6U+oNAooooAKKKKAC iiigAooooAyfFHHhLWcf8+M//otq8X8M33h/QPh3Dqt5pFre6vJdyLaGWME5Xack+i5Fe1eJ Y3l8LavHGpZ3splVQOSShwK8H8N674Qh8KWlrrqXst7Y3EtxBHACFYttIBPTkqKmLpRrRdX4 T0KUK9TBVI4f4rotWOmx3lvN4y8Y3BkglzJbQmUKb113Zj9VHygAelGsXWk6lJ4V1TSdIi0t J7t0eKPGSUkQAkgD1NVy998QtSuNY1ic6Z4dtSDNtcmNCBjbGD1dvYd/wq9r+r6FrOreFdP8 MwSrBZzCMRGIr1dD+J4JJr0sLXrYiv7S1oK/psebj8HhsFh1RbvWbTfkd38Zv+RAf/r6i/ma 4TwD8RR4d8MarYXshd4IzNp6vzljxs+mSD9N1ei/FbTb3VfBT22n2k11ObiNvLiXc2ATk4rk tO+FLa5oHhy4vN1hcQK0d9DJGQ8iCRiB7HBxn0I9K8aal7S8ex72Fnh/qfJX2cv+D/wDiPBt xPd6/q1xcyPLPLpV67u5yWJjPNei/An/AJF7VP8Ar7X/ANAFZeieEdSPxQ1rztMubbS7lLuB J/KIQI42rg9OnSqehQeP/h5Ne2FjoP2+CVw28RNIjEcblKkEZGODUQTi035nVipQxEJU4NJt Re5T/wCav+Iv+uV9/wCiWro/gN/yDta/66w/+gtVLwv4O8R3mqa34m1qze2nmtbgRwFcPLJI hHC9gAcc+1ZXg+Xx34MguorHwrcTC5ZWcz278FQRxgj1ojeMlJruFflq0ZUoSV0orfsHxM8B 2/hiFdWiv5Z3vbxw0boAE3bm4IrVsPA0GifDrUvEUd9LLJfaKQ0LIAqbwrcH2xitb4j2Wu+J PAmhSLpM76g0qy3FvDESYiYznjqOTXQXWm3r/Bv+zltZje/2UsX2fb8+/YBtx61XIuZ2XQ53 i6nsKalLXms9tkzyaz1y90f4RPFYzPC97qzxSSIcMEESkgHtnium0b4LW2p6JZX1xrVwktzC szKkQIXcM4yeT1qnYeANa1T4XTWbWUtvqNtqTXMUE42GVTGqkDP6fSr2m+KviTpOmW+nr4Ta ZbaMRLI9s+SFGBnBwePSpil9taWOirUm1L6tNKXM76r5bmJ8R7yWLxJYeFrjUZYNI0+3giZ1 UnPyjMhUfeOMYFXfAuh+ELjxjYNpWv39xeQMZkiltNittHOTVvxx4T8RXmr6b4sstLW7mlgh a6szHv8ALlVRlSh6qemOvFXvC+peJF8SWKy+ALDTYZJNkt1DYNG0aEcndnii3v6ol1P9lSpy 6O+qWvW63PMtFsND1DWL6PXdXfTIFLGORIi+9t3TAB7Vt+HriLQfiPp1t4Y1afULK4ljilYx lBIGOGBXvgc5x2rf+HngSS48Rap/wkugSm1KEwm6iIUtv7e+KuWfhK98P/GaCfSdKuI9Gz/r VQtGitH8w3Hp81TGDsn5m1bFU5SnT5r+7tpbb77nJfETwJb+CksZIL+W6N20mRIgXbtweMfW vVvh94Dt/CqvqEV/LcNe28e5HQAL/Fxj61i/GfRNU1mDSBpmn3N4YzNv8mMttyFxnH0NelaY jxaTZxupV1gRWU9QQo4raFNKo9DzcVi6k8HBOV273276Fqiiiug8c+UadHTadHX0h8eiylTp UCVOlSzRFmOp46gjqeOoZoixHVlOgqtHVlOgrNmiJ0qzHVZKsx1mzVFiPtU8dQR9qnjqGaIs rU6VAtTpUGqLMdWEqvHVhKzZoiwnarCVXTtVhKhmqLMfap4+tQR9qnj61DNEWI6njqCOp46z ZqiynSn0xOlPqDQKKKKACiiigAooooAKKKKACsWXwh4cnlaWXQtOaRzlmNsuSfXpW1RSaT3K jOUfhdjNfw9o0thFYvpdo1pCd0cBiGxT6hemaSy8O6Lp1wLiy0qyt5gMCSOFVYfQ4rToq1KS Vk9CGk3zPcKKKKkYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH/2Q== --------------060705050402080307010006-- --------------020908070306050005030907-- From owner-ietf-pkix@mail.imc.org Mon Jun 9 10:10:59 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82A43A6784 for ; Mon, 9 Jun 2008 10:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IumnBQ12E29i for ; Mon, 9 Jun 2008 10:10:58 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D76E53A69CF for ; Mon, 9 Jun 2008 10:10:54 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59GThdq033264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 09:29:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59GThvt033263; Mon, 9 Jun 2008 09:29:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59GTgGo033247 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 09:29:42 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,613,1204531200"; d="p7s'?scan'208,217";a="39705136" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Jun 2008 09:29:39 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m59GTdMY018051 for ; Mon, 9 Jun 2008 09:29:39 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m59GTd6J007628 for ; Mon, 9 Jun 2008 16:29:39 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 09:29:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RFC 5280 Question Date: Mon, 9 Jun 2008 09:29:22 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0056_01C8CA1B.AF05A690" Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKTfmB38lAmillT8i4ZQGXFbXMEw== From: "Bob Bell (rtbell)" To: X-OriginalArrivalTime: 09 Jun 2008 16:29:26.0268 (UTC) FILETIME=[FB9C5BC0:01C8CA4D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7493; t=1213028979; x=1213892979; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RFC=205280=20Question |Sender:=20; bh=lSTTNSd2mSQOINEUa3f6edRDqLsT+VzuMd9085vqgNw=; b=WE6NGyCePC4Yy6t807w5PmyxSPWnPLlWu8KZZRRe8XRyvsJGp8j0QFNy1s H6p5z/241yUaGYcUQaN8mZChY1cbZd/6s9RQNZDhNk2EG9MK8THZdXJ2Y1ba +zDubsi68M; Authentication-Results: sj-dkim-3; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0056_01C8CA1B.AF05A690 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0057_01C8CA1B.AF05A690" ------=_NextPart_001_0057_01C8CA1B.AF05A690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks- I am hoping someone can give me the answer to this. Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented cert as authoritative and then the cert is subsequently presented (in a later access to the site). There should be no path search, since the presented cert is in the trust anchor list. So, where is it defined to accept the end-entity cert? Thanks ---- Bob Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com ------=_NextPart_001_0057_01C8CA1B.AF05A690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks-
 
I am = hoping someone=20 can give me the answer to this. Does RFC 5280 adress the case where an=20 end-entity certificate (not a CA cert) is installed in the trust anchor = list by=20 the user accepting the presented cert as authoritative and then the cert = is=20 subsequently presented (in a later access to the site). There should be = no path=20 search, since the presented cert is in the trust anchor list. So, where = is it=20 defined to accept the end-entity cert?
 
Thanks = ----=20 Bob
 
Bob Bell
Cisco Systems, = Inc.
576 S. Brentwood = Ln.
Bountiful, UT = 84010
801-294-3034 = (v)
801-294-3023 = (f)
801-971-4200 = (c)
rtbell@cisco.com
 
------=_NextPart_001_0057_01C8CA1B.AF05A690-- ------=_NextPart_000_0056_01C8CA1B.AF05A690 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MDkxNjI5MjJaMCMGCSqGSIb3DQEJBDEWBBRFBsF6iPhkj1wj9bvM HlHeInflJDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYAWSkhwhUboKVHR7p26LmBteH3bxcLMU9lJISmrO0pwxRO5RyuQX6KzQBMYwjr0WovWazeq Rg2jh/1LKjOeZah5y2YJUDDixp4ZRtRBc7opqjb3XheCy7HKGnpw1A7v9PJf97M8ackLx6XEpm/W x5mMTHIRL26Phy16Ira4RZFHdgAAAAAAAA== ------=_NextPart_000_0056_01C8CA1B.AF05A690-- From owner-ietf-pkix@mail.imc.org Mon Jun 9 11:25:10 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6093A69D0 for ; Mon, 9 Jun 2008 11:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPXf1ChwreEe for ; Mon, 9 Jun 2008 11:25:07 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D55B328C1A2 for ; Mon, 9 Jun 2008 11:25:04 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59HgOfs048778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 10:42:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59HgNXC048777; Mon, 9 Jun 2008 10:42:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m59HgMip048759 for ; Mon, 9 Jun 2008 10:42:22 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 21702 invoked from network); 9 Jun 2008 17:32:08 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;09 Jun 2008 17:32:08 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 9 Jun 2008 17:32:06 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA58.2A730FE7" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 13:42:19 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKTfmB38lAmillT8i4ZQGXFbXMEwACJDbA References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA58.2A730FE7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, =20 Neither X.509 nor 5280 explicitly address this. =20 But, one can safely assume that the standards imply that if a trusted certificate public key is required, there is no need for path development and validation. =20 That said, trusting an end certificate could invite security trouble depending on how this trusted certificate is handled. =20 As mentioned below "trust anchor list" could be problematic. X.509 and 5280 do not require any checks on trust anchors and hence this end certificate could spawn a bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy. _____ =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Bob Bell (rtbell) Sent: Monday, June 09, 2008 12:29 PM To: ietf-pkix@imc.org Subject: RFC 5280 Question =20 Folks- =20 I am hoping someone can give me the answer to this. Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented cert as authoritative and then the cert is subsequently presented (in a later access to the site). There should be no path search, since the presented cert is in the trust anchor list. So, where is it defined to accept the end-entity cert? =20 Thanks ---- Bob =20 Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com =20 ------_=_NextPart_001_01C8CA58.2A730FE7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

Neither X.509 nor 5280 explicitly = address this.

 

But, one can safely assume that the standards imply that if a trusted certificate public key is required, = there is no need for path development and = validation.

 

That said, trusting an end = certificate could invite security trouble depending on how this trusted certificate = is handled.

 

As mentioned below “trust = anchor list” could be problematic.  X.509 and 5280 do not require = any checks on trust anchors and hence this end certificate could spawn a = bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Bob Bell (rtbell)
Sent: Monday, June 09, = 2008 12:29 PM
To: ietf-pkix@imc.org
Subject: RFC 5280 = Question

 

Folks-

 

I am hoping someone can give me the answer to this. = Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented = cert as authoritative and then the cert is subsequently presented (in a later = access to the site). There should be no path search, since the presented cert is = in the trust anchor list. So, where is it defined to accept the end-entity = cert?

 

Thanks ---- Bob

 

Bob Bell

Cisco Systems, Inc.

576 S. = Brentwood Ln.

Bountiful, UT 84010

801-294-3034 (v)

801-294-3023 (f)

801-971-4200 (c)

rtbell@cisco.com

 

------_=_NextPart_001_01C8CA58.2A730FE7-- From owner-ietf-pkix@mail.imc.org Mon Jun 9 13:10:57 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6BF3A6840 for ; Mon, 9 Jun 2008 13:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbpR6SZcMiVO for ; Mon, 9 Jun 2008 13:10:52 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6315628C19F for ; Mon, 9 Jun 2008 13:09:58 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59JWPD0073626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 12:32:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59JWPFf073625; Mon, 9 Jun 2008 12:32:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59JWOf5073611 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 12:32:24 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,613,1204531200"; d="p7s'?scan'208,217";a="110842563" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2008 12:32:11 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m59JWB8r009792; Mon, 9 Jun 2008 12:32:11 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m59JWBil004898; Mon, 9 Jun 2008 19:32:11 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 12:32:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 12:32:08 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B6_01C8CA35.36D6BFA0" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKTfmB38lAmillT8i4ZQGXFbXMEwACJDbAAAQiEgA= References: From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , X-OriginalArrivalTime: 09 Jun 2008 19:32:11.0522 (UTC) FILETIME=[83695620:01C8CA67] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18093; t=1213039931; x=1213903931; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=FRKmjLOTUX9EgeJxkW1ETWL+IZFvXqAXEHSzeCHMXqo=; b=uQO8lhBLIdlrISQhWcb4vXjzwNkRHwx98Q8ef7Rj0qR7uUvUf1S0VeIHfE ossEmXw2qdEAymVd4M5hJbRWECFkoJeJW/wFDcf7ThivYbd0R7cP3DnlbV6h LFPXWGYNOX4plOo58t4MlYdHJdOFtHE59D+mbQekI6MqZZBy4WwtI=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00B6_01C8CA35.36D6BFA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00B7_01C8CA35.36D6BFA0" ------=_NextPart_001_00B7_01C8CA35.36D6BFA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh, et al - I appreciate your response. I agree that there is a potential to have a problem if the acceptance/provisioning of trusted certs is not done securely. However, in this case, we are being very careful with that issue. As to the "spawning a bogus hierarchy", if the cert in the trust list does not have the CA bit set in the usage, then it cannot be used to sign other certs, and thus cannot create this false hierarchy. Is that correct? Bob _____ From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] Sent: Monday, 09 June, 2008 11:42 To: Bob Bell (rtbell); ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, Neither X.509 nor 5280 explicitly address this. But, one can safely assume that the standards imply that if a trusted certificate public key is required, there is no need for path development and validation. That said, trusting an end certificate could invite security trouble depending on how this trusted certificate is handled. As mentioned below "trust anchor list" could be problematic. X.509 and 5280 do not require any checks on trust anchors and hence this end certificate could spawn a bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy. _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Bob Bell (rtbell) Sent: Monday, June 09, 2008 12:29 PM To: ietf-pkix@imc.org Subject: RFC 5280 Question Folks- I am hoping someone can give me the answer to this. Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented cert as authoritative and then the cert is subsequently presented (in a later access to the site). There should be no path search, since the presented cert is in the trust anchor list. So, where is it defined to accept the end-entity cert? Thanks ---- Bob Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com ------=_NextPart_001_00B7_01C8CA35.36D6BFA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Santosh, et al -
 
I appreciate your response. I agree that there = is a=20 potential to have a problem if the acceptance/provisioning of trusted = certs is=20 not done securely. However, in this case, we are being very careful with = that=20 issue.
 
As to the "spawning a bogus hierarchy", if the = cert in the=20 trust list does not have the CA bit set in the usage, then it cannot be = used to=20 sign other certs, and thus cannot create this false hierarchy. Is that=20 correct?
 
Bob

From: Santosh Chokhani=20 [mailto:SChokhani@cygnacom.com]
Sent: Monday, 09 June, 2008 = 11:42
To: Bob Bell (rtbell); = ietf-pkix@imc.org
Subject:=20 RE: RFC 5280 Question

Bob,

 

Neither = X.509 nor=20 5280 explicitly address this.

 

But, one = can safely=20 assume that the standards imply that if a trusted certificate public = key is=20 required, there is no need for path development and=20 validation.

 

That said, = trusting=20 an end certificate could invite security trouble depending on how this = trusted=20 certificate is handled.

 

As = mentioned below=20 “trust anchor list” could be problematic.  X.509 and = 5280 do not require=20 any checks on trust anchors and hence this end certificate could spawn = a bogus=20 hierarchy and the PK enabled applications could legitimately accept = that=20 hierarchy.

From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Bob Bell=20 (rtbell)
Sent: = Monday, June=20 09, 2008 12:29 PM
To:=20 ietf-pkix@imc.org
Subject:=20 RFC 5280 Question

 

Folks-

 

I am hoping someone can = give me=20 the answer to this. Does RFC 5280 adress the case where an end-entity=20 certificate (not a CA cert) is installed in the trust anchor list by = the user=20 accepting the presented cert as authoritative and then the cert is=20 subsequently presented (in a later access to the site). There should = be no=20 path search, since the presented cert is in the trust anchor list. So, = where=20 is it defined to accept the end-entity=20 cert?

 

Thanks ----=20 Bob

 

Bob=20 Bell

Cisco Systems,=20 Inc.

576 S.=20 Brentwood Ln.

Bountiful,=20 UT 84010

801-294-3034=20 (v)

801-294-3023=20 (f)

801-971-4200=20 (c)

rtbell@cisco.com

 

= ------=_NextPart_001_00B7_01C8CA35.36D6BFA0-- ------=_NextPart_000_00B6_01C8CA35.36D6BFA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MDkxOTMyMDhaMCMGCSqGSIb3DQEJBDEWBBS7faxlPD0FLsQ2MKFn jCVEDoY8OTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYAId6ZMTW5W6vPjRaD+FjJxCaJCmSqm1NjJNITo72/taZh16+XsrNCrOR7lU7Om4/Wu9UHg arZ/i5OxVyEDz8HK1PyNAhHE10DcyI96C/FAT1Zdh31RPaKwW1i/vPcmwjcF6ZItUcFt/ex1/FGK xMRKtgZ/QMV28k4TJOtQQmCtDgAAAAAAAA== ------=_NextPart_000_00B6_01C8CA35.36D6BFA0-- From owner-ietf-pkix@mail.imc.org Mon Jun 9 14:11:48 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CDB3A6ACC for ; Mon, 9 Jun 2008 14:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4szOWvWl63sy for ; Mon, 9 Jun 2008 14:11:42 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 99E743A6979 for ; Mon, 9 Jun 2008 14:11:38 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59KcNwH086448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 13:38:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59KcN8S086447; Mon, 9 Jun 2008 13:38:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m59KcLMX086439 for ; Mon, 9 Jun 2008 13:38:22 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 23239 invoked from network); 9 Jun 2008 20:28:08 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;09 Jun 2008 20:28:08 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 9 Jun 2008 20:28:07 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA70.C14CA875" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 16:38:20 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKTfmB38lAmillT8i4ZQGXFbXMEwACJDbAAAQiEgAAAkE+MA== References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA70.C14CA875 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, =20 My primary concern in terms of being very careful is that subscriber keys are not as well protected as CA and undetected compromise becomes a problem. So, it is not a matter of trusting the subscriber; subscriber could be very trustworthy, but the environment is not likely to be as protected as the CA. =20 On the issue of basic constraints (a.k.a. cA bit), while many of the client may make that check, there is no requirement in X.509 and 5280 to make that check on a trust anchor. =20 _____ =20 From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 3:32 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: RFC 5280 Question =20 Santosh, et al - =20 I appreciate your response. I agree that there is a potential to have a problem if the acceptance/provisioning of trusted certs is not done securely. However, in this case, we are being very careful with that issue. =20 As to the "spawning a bogus hierarchy", if the cert in the trust list does not have the CA bit set in the usage, then it cannot be used to sign other certs, and thus cannot create this false hierarchy. Is that correct? =20 Bob =20 _____ =20 From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 Sent: Monday, 09 June, 2008 11:42 To: Bob Bell (rtbell); ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, =20 Neither X.509 nor 5280 explicitly address this. =20 But, one can safely assume that the standards imply that if a trusted certificate public key is required, there is no need for path development and validation. =20 That said, trusting an end certificate could invite security trouble depending on how this trusted certificate is handled. =20 As mentioned below "trust anchor list" could be problematic. X.509 and 5280 do not require any checks on trust anchors and hence this end certificate could spawn a bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy. _____ =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Bob Bell (rtbell) Sent: Monday, June 09, 2008 12:29 PM To: ietf-pkix@imc.org Subject: RFC 5280 Question =20 Folks- =20 I am hoping someone can give me the answer to this. Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented cert as authoritative and then the cert is subsequently presented (in a later access to the site). There should be no path search, since the presented cert is in the trust anchor list. So, where is it defined to accept the end-entity cert? =20 Thanks ---- Bob =20 Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com =20 ------_=_NextPart_001_01C8CA70.C14CA875 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

My primary concern in terms of = being very careful is that subscriber keys are not as well protected as CA and = undetected compromise becomes a problem.  So, it is not a matter of trusting = the subscriber; subscriber could be very trustworthy, but the environment is not likely = to be as protected as the CA.

 

On the issue of basic constraints = (a.k.a. cA bit), while many of the client may make that check, there is no = requirement in X.509 and 5280 to make that check on a trust = anchor.

 

From: Bob = Bell (rtbell) [mailto:rtbell@cisco.com]
Sent: Monday, June 09, = 2008 3:32 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: RFC 5280 = Question

 

Santosh, et al = -

 

I appreciate your response. I agree = that there is a potential to have a problem if the acceptance/provisioning of trusted certs is not done securely. However, in this case, we are being = very careful with that issue.

 

As to the "spawning a bogus hierarchy", if the cert in the trust list does not have the CA bit = set in the usage, then it cannot be used to sign other certs, and thus cannot = create this false hierarchy. Is that correct?

 

Bob

 

From: Santosh Chokhani = [mailto:SChokhani@cygnacom.com]
Sent: Monday, 09 June, = 2008 11:42
To: Bob Bell (rtbell); ietf-pkix@imc.org
Subject: RE: RFC 5280 = Question

Bob,

 

Neither X.509 nor 5280 explicitly = address this.

 

But, one can safely assume that the standards imply that if a trusted certificate public key is required, = there is no need for path development and = validation.

 

That said, trusting an end = certificate could invite security trouble depending on how this trusted certificate = is handled.

 

As mentioned below “trust = anchor list” could be problematic.  X.509 and 5280 do not require = any checks on trust anchors and hence this end certificate could spawn a = bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Bob Bell (rtbell)
Sent: Monday, June 09, = 2008 12:29 PM
To: ietf-pkix@imc.org
Subject: RFC 5280 = Question

 

Folks-

 

I am hoping someone can give me the answer to this. = Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented = cert as authoritative and then the cert is subsequently presented (in a later = access to the site). There should be no path search, since the presented cert is = in the trust anchor list. So, where is it defined to accept the end-entity = cert?

 

Thanks ---- Bob

 

Bob Bell

Cisco Systems, Inc.

576 S. = Brentwood Ln.

Bountiful, UT 84010

801-294-3034 (v)

801-294-3023 (f)

801-971-4200 (c)

rtbell@cisco.com

 

------_=_NextPart_001_01C8CA70.C14CA875-- From owner-ietf-pkix@mail.imc.org Mon Jun 9 14:18:15 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63D43A6CAF for ; Mon, 9 Jun 2008 14:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlX3sOxPGQqj for ; Mon, 9 Jun 2008 14:18:09 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 081B03A6BC8 for ; Mon, 9 Jun 2008 14:18:07 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59Kq9HH088985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 13:52:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59Kq9Nd088984; Mon, 9 Jun 2008 13:52:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m59Kq8o3088978 for ; Mon, 9 Jun 2008 13:52:08 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 23386 invoked from network); 9 Jun 2008 20:41:54 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;09 Jun 2008 20:41:54 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 9 Jun 2008 20:41:53 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA72.AD924D4C" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 16:52:06 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKTfmB38lAmillT8i4ZQGXFbXMEwACJDbAAAQiEgAAAkE+MAAAlFhw References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA72.AD924D4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, =20 Let me add, that in situations where all the applications on the client platform that installs the user certificate as a trusted certificate, if the basic constraints check is made, most of my concerns are neutralized. =20 The only concern is that any revocation or compromise of that user certificate requires some out of band means to delete the trust anchor. ________________________________ From: Santosh Chokhani=20 Sent: Monday, June 09, 2008 4:38 PM To: 'Bob Bell (rtbell)'; ietf-pkix@imc.org Subject: RE: RFC 5280 Question =20 Bob, =20 My primary concern in terms of being very careful is that subscriber keys are not as well protected as CA and undetected compromise becomes a problem. So, it is not a matter of trusting the subscriber; subscriber could be very trustworthy, but the environment is not likely to be as protected as the CA. =20 On the issue of basic constraints (a.k.a. cA bit), while many of the client may make that check, there is no requirement in X.509 and 5280 to make that check on a trust anchor. =20 ________________________________ From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 3:32 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: RFC 5280 Question =20 Santosh, et al - =20 I appreciate your response. I agree that there is a potential to have a problem if the acceptance/provisioning of trusted certs is not done securely. However, in this case, we are being very careful with that issue. =20 As to the "spawning a bogus hierarchy", if the cert in the trust list does not have the CA bit set in the usage, then it cannot be used to sign other certs, and thus cannot create this false hierarchy. Is that correct? =20 Bob =20 =09 ________________________________ From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 Sent: Monday, 09 June, 2008 11:42 To: Bob Bell (rtbell); ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, =20 Neither X.509 nor 5280 explicitly address this. =20 But, one can safely assume that the standards imply that if a trusted certificate public key is required, there is no need for path development and validation. =20 That said, trusting an end certificate could invite security trouble depending on how this trusted certificate is handled. =20 As mentioned below "trust anchor list" could be problematic. X.509 and 5280 do not require any checks on trust anchors and hence this end certificate could spawn a bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy. =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Bob Bell (rtbell) Sent: Monday, June 09, 2008 12:29 PM To: ietf-pkix@imc.org Subject: RFC 5280 Question =20 Folks- =20 I am hoping someone can give me the answer to this. Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented cert as authoritative and then the cert is subsequently presented (in a later access to the site). There should be no path search, since the presented cert is in the trust anchor list. So, where is it defined to accept the end-entity cert? =20 Thanks ---- Bob =20 Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com =20 ------_=_NextPart_001_01C8CA72.AD924D4C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

Let me add, that in situations = where all the applications on the client platform that installs the user = certificate as a trusted certificate, if the basic constraints check is made, most of my concerns are neutralized.

 

The only concern is that any = revocation or compromise of that user certificate requires some out of band means to = delete the trust anchor.

From: = Santosh Chokhani
Sent: Monday, June 09, = 2008 4:38 PM
To: 'Bob Bell (rtbell)'; ietf-pkix@imc.org
Subject: RE: RFC 5280 = Question

 

Bob,

 

My primary concern in terms of = being very careful is that subscriber keys are not as well protected as CA and = undetected compromise becomes a problem.  So, it is not a matter of trusting the = subscriber; subscriber could be very trustworthy, but the environment is not likely = to be as protected as the CA.

 

On the issue of basic constraints = (a.k.a. cA bit), while many of the client may make that check, there is no = requirement in X.509 and 5280 to make that check on a trust = anchor.

 

From: Bob = Bell (rtbell) [mailto:rtbell@cisco.com]
Sent: Monday, June 09, = 2008 3:32 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: RFC 5280 = Question

 

Santosh, et al = -

 

I appreciate your response. I agree = that there is a potential to have a problem if the acceptance/provisioning of trusted certs is not done securely. However, in this case, we are being = very careful with that issue.

 

As to the "spawning a bogus hierarchy", if the cert in the trust list does not have the CA bit = set in the usage, then it cannot be used to sign other certs, and thus cannot = create this false hierarchy. Is that correct?

 

Bob

 

From: Santosh Chokhani = [mailto:SChokhani@cygnacom.com]
Sent: Monday, 09 June, = 2008 11:42
To: Bob Bell (rtbell); ietf-pkix@imc.org
Subject: RE: RFC 5280 = Question

Bob,

 

Neither X.509 nor 5280 explicitly = address this.

 

But, one can safely assume that the standards imply that if a trusted certificate public key is required, = there is no need for path development and = validation.

 

That said, trusting an end = certificate could invite security trouble depending on how this trusted certificate = is handled.

 

As mentioned below “trust = anchor list” could be problematic.  X.509 and 5280 do not require = any checks on trust anchors and hence this end certificate could spawn a = bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Bob Bell (rtbell)
Sent: Monday, June 09, = 2008 12:29 PM
To: ietf-pkix@imc.org
Subject: RFC 5280 = Question

 

Folks-

 

I am hoping someone can give me the answer to this. = Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented = cert as authoritative and then the cert is subsequently presented (in a later = access to the site). There should be no path search, since the presented cert is = in the trust anchor list. So, where is it defined to accept the end-entity = cert?

 

Thanks ---- Bob

 

Bob Bell

Cisco Systems, Inc.

576 S. = Brentwood Ln.

Bountiful, UT 84010

801-294-3034 (v)

801-294-3023 (f)

801-971-4200 (c)

rtbell@cisco.com

 

------_=_NextPart_001_01C8CA72.AD924D4C-- From owner-ietf-pkix@mail.imc.org Mon Jun 9 15:41:16 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F413A680D for ; Mon, 9 Jun 2008 15:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl80KqD01DD4 for ; Mon, 9 Jun 2008 15:41:08 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 20BC83A67AD for ; Mon, 9 Jun 2008 15:41:06 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59M7sOq007842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 15:07:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59M7saE007841; Mon, 9 Jun 2008 15:07:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59M7p34007824 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 15:07:52 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,614,1204531200"; d="p7s'?scan'208,217";a="110909665" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2008 15:07:51 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m59M7pKu004712; Mon, 9 Jun 2008 15:07:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m59M7pht006219; Mon, 9 Jun 2008 22:07:51 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 15:07:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 15:07:47 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0102_01C8CA4A.F5962E70" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKTfmB38lAmillT8i4ZQGXFbXMEwACJDbAAAQiEgAAAkE+MAAAlFhwAAKQXRA= References: From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , X-OriginalArrivalTime: 09 Jun 2008 22:07:51.0351 (UTC) FILETIME=[42622470:01C8CA7D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=28685; t=1213049271; x=1213913271; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=C6ofhElB0VXfNFek41/2H8vp+EPRW9q+cUPzToCPawk=; b=iVUm784M1w7Nqwn3Hb9DU3ZRTSKHA2dL4qZ9YqVIpU4uPz+bW5QbFaH999 dNH+BQskK6XYWKwO59C5EpZJytoCOnxvIYLaHHwcrcaUIVGCage+vDX+bPbD 9lyggj1H4h8u7dNbvTKU/GGBMBAZ1K0LnVwYZIlKtUaKQ6pD4AG+k=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0102_01C8CA4A.F5962E70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0103_01C8CA4A.F5962E70" ------=_NextPart_001_0103_01C8CA4A.F5962E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - Thanks for your replys. First comment, we do enforce the checking of the CA bit in our application. That application is the only one that would use this cert as it is specific to the application and would have no meaning elsewhere. Also it requires a Systems Administrator approval to install the cert, and end user cannot do it. Secondly, revocation is simply having the SysAdmin remove it from the trust store. Since they are the sole arbiters of whether a cert is valid for this purpose, and because the certs in question are typically self-signed anyway, this is the mechanism we evolved to handle deapproval of a device. These are device certs rather than user certs also. Bob _____ From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] Sent: Monday, 09 June, 2008 14:52 To: Bob Bell (rtbell); ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, Let me add, that in situations where all the applications on the client platform that installs the user certificate as a trusted certificate, if the basic constraints check is made, most of my concerns are neutralized. The only concern is that any revocation or compromise of that user certificate requires some out of band means to delete the trust anchor. _____ From: Santosh Chokhani Sent: Monday, June 09, 2008 4:38 PM To: 'Bob Bell (rtbell)'; ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, My primary concern in terms of being very careful is that subscriber keys are not as well protected as CA and undetected compromise becomes a problem. So, it is not a matter of trusting the subscriber; subscriber could be very trustworthy, but the environment is not likely to be as protected as the CA. On the issue of basic constraints (a.k.a. cA bit), while many of the client may make that check, there is no requirement in X.509 and 5280 to make that check on a trust anchor. _____ From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] Sent: Monday, June 09, 2008 3:32 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: RFC 5280 Question Santosh, et al - I appreciate your response. I agree that there is a potential to have a problem if the acceptance/provisioning of trusted certs is not done securely. However, in this case, we are being very careful with that issue. As to the "spawning a bogus hierarchy", if the cert in the trust list does not have the CA bit set in the usage, then it cannot be used to sign other certs, and thus cannot create this false hierarchy. Is that correct? Bob _____ From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] Sent: Monday, 09 June, 2008 11:42 To: Bob Bell (rtbell); ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, Neither X.509 nor 5280 explicitly address this. But, one can safely assume that the standards imply that if a trusted certificate public key is required, there is no need for path development and validation. That said, trusting an end certificate could invite security trouble depending on how this trusted certificate is handled. As mentioned below "trust anchor list" could be problematic. X.509 and 5280 do not require any checks on trust anchors and hence this end certificate could spawn a bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy. _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Bob Bell (rtbell) Sent: Monday, June 09, 2008 12:29 PM To: ietf-pkix@imc.org Subject: RFC 5280 Question Folks- I am hoping someone can give me the answer to this. Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented cert as authoritative and then the cert is subsequently presented (in a later access to the site). There should be no path search, since the presented cert is in the trust anchor list. So, where is it defined to accept the end-entity cert? Thanks ---- Bob Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com ------=_NextPart_001_0103_01C8CA4A.F5962E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Santosh -
 
Thanks for your replys. First comment, we do = enforce the=20 checking of the CA bit in our application. That application is the only = one that=20 would use this cert as it is specific to the application and would have = no=20 meaning elsewhere. Also it requires a Systems Administrator approval to = install=20 the cert, and end user cannot do it. Secondly, revocation is simply = having the=20 SysAdmin remove it from the trust store. Since they are the sole = arbiters of=20 whether a cert is valid for this purpose, and because the certs in = question are=20 typically self-signed anyway, this is the mechanism we evolved to handle = deapproval of a device. These are device certs rather than user certs=20 also.
 
Bob

From: Santosh Chokhani=20 [mailto:SChokhani@cygnacom.com]
Sent: Monday, 09 June, 2008 = 14:52
To: Bob Bell (rtbell); = ietf-pkix@imc.org
Subject:=20 RE: RFC 5280 Question

Bob,

 

Let me add, = that in=20 situations where all the applications on the client platform that = installs the=20 user certificate as a trusted certificate, if the basic constraints = check is=20 made, most of my concerns are = neutralized.

 

The only = concern is=20 that any revocation or compromise of that user certificate requires = some out=20 of band means to delete the trust anchor.

From:=20 Santosh Chokhani =
Sent: Monday, June 09, 2008 = 4:38=20 PM
To: 'Bob Bell = (rtbell)';=20 ietf-pkix@imc.org
Subject:=20 RE: RFC 5280 Question

 

Bob,

 

My primary = concern in=20 terms of being very careful is that subscriber keys are not as well = protected=20 as CA and undetected compromise becomes a problem.  So, it is not = a=20 matter of trusting the subscriber; subscriber could be very = trustworthy, but=20 the environment is not likely to be as protected as the=20 CA.

 

On the = issue of basic=20 constraints (a.k.a. cA bit), while many of the client may make that = check,=20 there is no requirement in X.509 and 5280 to make that check on a = trust=20 anchor.

 

From: Bob=20 Bell (rtbell) [mailto:rtbell@cisco.com]
Sent: Monday, June 09, 2008 = 3:32=20 PM
To: = Santosh Chokhani; = ietf-pkix@imc.org
Subject: RE: RFC 5280=20 Question

 

Santosh, et = al=20 -

 

I = appreciate your=20 response. I agree that there is a potential to have a problem if the=20 acceptance/provisioning of trusted certs is not done securely. = However, in=20 this case, we are being very careful with that=20 issue.

 

As to the = "spawning a=20 bogus hierarchy", if the cert in the trust list does not have the CA = bit set=20 in the usage, then it cannot be used to sign other certs, and thus = cannot=20 create this false hierarchy. Is that = correct?

 

Bob

 

From:=20 Santosh Chokhani=20 [mailto:SChokhani@cygnacom.com]
Sent: Monday, 09 June, 2008=20 11:42
To: Bob = Bell=20 (rtbell); ietf-pkix@imc.org
Subject: RE: RFC 5280=20 Question

Bob,

 

Neither = X.509 nor=20 5280 explicitly address this.

 

But, one = can safely=20 assume that the standards imply that if a trusted certificate public = key is=20 required, there is no need for path development and=20 validation.

 

That = said, trusting=20 an end certificate could invite security trouble depending on how = this=20 trusted certificate is handled.

 

As = mentioned below=20 “trust anchor list” could be problematic.  X.509 = and 5280 do not=20 require any checks on trust anchors and hence this end certificate = could=20 spawn a bogus hierarchy and the PK enabled applications could = legitimately=20 accept that hierarchy.

From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Bob Bell=20 (rtbell)
Sent: = Monday, June=20 09, 2008 12:29 PM
To:=20 ietf-pkix@imc.org
Subject:=20 RFC 5280 Question

 

Folks-

 

I am hoping someone = can give me=20 the answer to this. Does RFC 5280 adress the case where an = end-entity=20 certificate (not a CA cert) is installed in the trust anchor list by = the=20 user accepting the presented cert as authoritative and then the cert = is=20 subsequently presented (in a later access to the site). There should = be no=20 path search, since the presented cert is in the trust anchor list. = So, where=20 is it defined to accept the end-entity=20 cert?

 

Thanks ----=20 Bob

 

Bob=20 Bell

Cisco Systems,=20 Inc.

576 S.=20 Brentwood = Ln.

Bountiful,=20 UT 84010

801-294-3034=20 (v)

801-294-3023=20 (f)

801-971-4200=20 (c)

rtbell@cisco.com

 

------=_NextPart_001_0103_01C8CA4A.F5962E70-- ------=_NextPart_000_0102_01C8CA4A.F5962E70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MDkyMjA3NDdaMCMGCSqGSIb3DQEJBDEWBBQEv+UOs3Q+8HggaIbo qrCE59HW4zBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYAEah7HmEO2QfbNxQFs7gScJobyv2NmiIE4RNzDw+HrgjyXxaNFNr12fG67mZgOVX0OsCbB pSRv+0B+VOyMKYCqfMvlzU1mcoT+Xqbrdq63X5bNGSIkSxCf82M821qY4FSr5AVAsYGVRzC4bs0A Gpma2qmzAXyGSYrjrxjNVUpRPQAAAAAAAA== ------=_NextPart_000_0102_01C8CA4A.F5962E70-- From owner-ietf-pkix@mail.imc.org Mon Jun 9 16:47:06 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98E73A67D4 for ; Mon, 9 Jun 2008 16:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZUBnemTTp05 for ; Mon, 9 Jun 2008 16:47:03 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 29FBC3A67E4 for ; Mon, 9 Jun 2008 16:47:01 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59N3411023747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 16:03:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59N34iu023742; Mon, 9 Jun 2008 16:03:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59N31j8023678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Jun 2008 16:03:03 -0700 (MST) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m59N2w3I020828 for ; Mon, 9 Jun 2008 19:02:58 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m59N2wQV194008 for ; Mon, 9 Jun 2008 19:02:58 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m59N2wla010435 for ; Mon, 9 Jun 2008 19:02:58 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m59N2wiU010432; Mon, 9 Jun 2008 19:02:58 -0400 In-Reply-To: To: "Bob Bell (rtbell)" Cc: ietf-pkix@imc.org, "Santosh Chokhani" MIME-Version: 1.0 Subject: RE: RFC 5280 Question X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Tom Gindin Message-ID: Date: Mon, 9 Jun 2008 19:02:56 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 7.0.2FP2 IGS702FP2HF8|March 12, 2008) at 06/09/2008 19:02:58, Serialize complete at 06/09/2008 19:02:58 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob: It looks to me as if RFC 5280 section 6 presumes that a trust=20 anchor represents an issuer, rather than permitting EE's. If you consider = the fields in 6.1.1, they include an issuer name but no subject name. One = of the conditions which basic path validation is expected to verify is=20 "certificate 1 is issued by the trust anchor". When the EE certificate is = directly trusted, this condition will never be true, since no certificate=20 exists which was issued by the trust anchor. While no certificate which contains keyUsage with keyCertSign not=20 set can be used as an intermediate CA certificate (see 6.1.4-n), section=20 6.1.4 doesn't execute against the trust anchor so verification isn't=20 expected to reject the use of a directly trusted certificate as a CA=20 certificate. Section 6 isn't designed to handle a directly=20 trusted EE certificate. I think that you could tweak this by defining a=20 trust anchor using the CA's certificate, with a name constraint which=20 permits your EE's DN and no other using initial-permitted-subtrees,=20 although you'd be trusting the CA to reserve that DN for the entity you=20 want. That way you'd get revocation check as well. Alternatively, you=20 could write your own algorithm for directly trusting EE certificates. Tom Gindin "Bob Bell (rtbell)" =20 Sent by: owner-ietf-pkix@mail.imc.org 06/09/2008 03:32 PM To "Santosh Chokhani" , cc Subject RE: RFC 5280 Question Santosh, et al - =20 I appreciate your response. I agree that there is a potential to have a=20 problem if the acceptance/provisioning of trusted certs is not done=20 securely. However, in this case, we are being very careful with that=20 issue. =20 As to the "spawning a bogus hierarchy", if the cert in the trust list does = not have the CA bit set in the usage, then it cannot be used to sign other = certs, and thus cannot create this false hierarchy. Is that correct? =20 Bob From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 Sent: Monday, 09 June, 2008 11:42 To: Bob Bell (rtbell); ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, =20 Neither X.509 nor 5280 explicitly address this. =20 But, one can safely assume that the standards imply that if a trusted=20 certificate public key is required, there is no need for path development=20 and validation. =20 That said, trusting an end certificate could invite security trouble=20 depending on how this trusted certificate is handled. =20 As mentioned below ?trust anchor list? could be problematic. X.509 and=20 5280 do not require any checks on trust anchors and hence this end=20 certificate could spawn a bogus hierarchy and the PK enabled applications=20 could legitimately accept that hierarchy. From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]=20 On Behalf Of Bob Bell (rtbell) Sent: Monday, June 09, 2008 12:29 PM To: ietf-pkix@imc.org Subject: RFC 5280 Question =20 Folks- =20 I am hoping someone can give me the answer to this. Does RFC 5280 adress=20 the case where an end-entity certificate (not a CA cert) is installed in=20 the trust anchor list by the user accepting the presented cert as=20 authoritative and then the cert is subsequently presented (in a later=20 access to the site). There should be no path search, since the presented=20 cert is in the trust anchor list. So, where is it defined to accept the=20 end-entity cert? =20 Thanks ---- Bob =20 Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com =20 From owner-ietf-pkix@mail.imc.org Mon Jun 9 16:50:29 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7EC93A67E4 for ; Mon, 9 Jun 2008 16:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNLqF8O9aEkz for ; Mon, 9 Jun 2008 16:50:27 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EC0D93A67D8 for ; Mon, 9 Jun 2008 16:50:26 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59NOL81030048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 16:24:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59NOLeq030047; Mon, 9 Jun 2008 16:24:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59NOJBS030033 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 16:24:19 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,614,1204531200"; d="p7s'?scan'208";a="110938271" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2008 16:24:13 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m59NODGM012877; Mon, 9 Jun 2008 16:24:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m59NODK9011473; Mon, 9 Jun 2008 23:24:13 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 16:24:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 16:24:10 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0141_01C8CA55.A13B0610" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKhPrpQbIEMXPvS1iaKmqpo/XJpgAAs4FQ References: From: "Bob Bell (rtbell)" To: "Tom Gindin" Cc: , "Santosh Chokhani" X-OriginalArrivalTime: 09 Jun 2008 23:24:13.0553 (UTC) FILETIME=[ED96AE10:01C8CA87] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8884; t=1213053853; x=1213917853; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=8m7jSHdHCoQ1a2JpZWo78/BARgQAPwjZj+BKjQBNp3Q=; b=Qh+J/NdweLlYuZ4W9+qY0JY8sTqlbXe46OJP8lL0OIu1y14A/55jD0jBUF UcvNf+iOeJjd7+N3kjBskY0Haau2HLdjlUtaUcN77M/7WQg4G+BA7WaskXQR Ah0Erdpdld; Authentication-Results: sj-dkim-3; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0141_01C8CA55.A13B0610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom - Actually, in our case, the cert is self-signed so the issuer and the subject are the same. Bob > -----Original Message----- > From: Tom Gindin [mailto:tgindin@us.ibm.com] > Sent: Monday, 09 June, 2008 17:03 > To: Bob Bell (rtbell) > Cc: ietf-pkix@imc.org; Santosh Chokhani > Subject: RE: RFC 5280 Question > > Bob: > > It looks to me as if RFC 5280 section 6 presumes that > a trust anchor represents an issuer, rather than permitting > EE's. If you consider the fields in 6.1.1, they include an > issuer name but no subject name. One of the conditions which > basic path validation is expected to verify is "certificate 1 > is issued by the trust anchor". When the EE certificate is > directly trusted, this condition will never be true, since no > certificate exists which was issued by the trust anchor. > While no certificate which contains keyUsage with > keyCertSign not set can be used as an intermediate CA > certificate (see 6.1.4-n), section > 6.1.4 doesn't execute against the trust anchor so > verification isn't expected to reject the use of a directly > trusted certificate as a CA > certificate. Section 6 isn't designed to handle a directly > trusted EE certificate. I think that you could tweak this by > defining a trust anchor using the CA's certificate, with a > name constraint which permits your EE's DN and no other using > initial-permitted-subtrees, although you'd be trusting the CA > to reserve that DN for the entity you want. That way you'd > get revocation check as well. Alternatively, you could write > your own algorithm for directly trusting EE certificates. > > Tom Gindin > > > > > > "Bob Bell (rtbell)" > Sent by: owner-ietf-pkix@mail.imc.org > 06/09/2008 03:32 PM > > To > "Santosh Chokhani" , cc > > Subject > RE: RFC 5280 Question > > > > > > > Santosh, et al - > > I appreciate your response. I agree that there is a potential > to have a problem if the acceptance/provisioning of trusted > certs is not done securely. However, in this case, we are > being very careful with that issue. > > As to the "spawning a bogus hierarchy", if the cert in the > trust list does not have the CA bit set in the usage, then it > cannot be used to sign other certs, and thus cannot create > this false hierarchy. Is that correct? > > Bob > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > Sent: Monday, 09 June, 2008 11:42 > To: Bob Bell (rtbell); ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Bob, > > Neither X.509 nor 5280 explicitly address this. > > But, one can safely assume that the standards imply that if a > trusted certificate public key is required, there is no need > for path development and validation. > > That said, trusting an end certificate could invite security > trouble depending on how this trusted certificate is handled. > > As mentioned below ?trust anchor list? could be problematic. > X.509 and 5280 do not require any checks on trust anchors and > hence this end certificate could spawn a bogus hierarchy and > the PK enabled applications could legitimately accept that hierarchy. > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Bob Bell (rtbell) > Sent: Monday, June 09, 2008 12:29 PM > To: ietf-pkix@imc.org > Subject: RFC 5280 Question > > Folks- > > I am hoping someone can give me the answer to this. Does RFC > 5280 adress the case where an end-entity certificate (not a > CA cert) is installed in the trust anchor list by the user > accepting the presented cert as authoritative and then the > cert is subsequently presented (in a later access to the > site). There should be no path search, since the presented > cert is in the trust anchor list. So, where is it defined to > accept the end-entity cert? > > Thanks ---- Bob > > Bob Bell > Cisco Systems, Inc. > 576 S. Brentwood Ln. > Bountiful, UT 84010 > 801-294-3034 (v) > 801-294-3023 (f) > 801-971-4200 (c) > rtbell@cisco.com > > > ------=_NextPart_000_0141_01C8CA55.A13B0610 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MDkyMzI0MTBaMCMGCSqGSIb3DQEJBDEWBBTOX2aXJIs0KDGOy1yJ uIZuyH9lxjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYB5+kWH0OkSqws7JzDu/8xyqv/jtv2AveukG+KqyMO4ym8gzRVHH9HTCUbnp/NpFKgUL+YX LlLEuz948jrkg58Q6xvoTSTsracfEy/tUxplPCsRfY6+w2qpqxuOs7/vvwKLTLMLoAkjoZUlnaqV NR3U7CpkNli7QP9TpGZzXSTclQAAAAAAAA== ------=_NextPart_000_0141_01C8CA55.A13B0610-- From owner-ietf-pkix@mail.imc.org Mon Jun 9 17:21:29 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E478E3A6A3F for ; Mon, 9 Jun 2008 17:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mig96b1NW5XG for ; Mon, 9 Jun 2008 17:21:26 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BDCE33A6875 for ; Mon, 9 Jun 2008 17:21:25 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59NvE1B036109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 16:57:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59NvEOx036108; Mon, 9 Jun 2008 16:57:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m59NvDdt036093 for ; Mon, 9 Jun 2008 16:57:13 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 24752 invoked from network); 9 Jun 2008 23:46:58 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;09 Jun 2008 23:46:58 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 9 Jun 2008 23:46:58 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 19:57:10 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKhPrpQbIEMXPvS1iaKmqpo/XJpgAAs4FQAAEiLIA= References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , "Tom Gindin" Cc: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Issuer name topic is a digression. You can probably find some e-mail exchange on PKIX on it. A Trust Anchor always has a subject name, otherwise name chaining will not work. I recall editor of 5280 (Dave Cooper) agreeing to that fact on this mail thread. -----Original Message----- From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 7:24 PM To: Tom Gindin Cc: ietf-pkix@imc.org; Santosh Chokhani Subject: RE: RFC 5280 Question Tom -=20 Actually, in our case, the cert is self-signed so the issuer and the subject are the same. Bob=20 > -----Original Message----- > From: Tom Gindin [mailto:tgindin@us.ibm.com]=20 > Sent: Monday, 09 June, 2008 17:03 > To: Bob Bell (rtbell) > Cc: ietf-pkix@imc.org; Santosh Chokhani > Subject: RE: RFC 5280 Question >=20 > Bob: >=20 > It looks to me as if RFC 5280 section 6 presumes that=20 > a trust anchor represents an issuer, rather than permitting=20 > EE's. If you consider the fields in 6.1.1, they include an=20 > issuer name but no subject name. One of the conditions which=20 > basic path validation is expected to verify is "certificate 1=20 > is issued by the trust anchor". When the EE certificate is=20 > directly trusted, this condition will never be true, since no=20 > certificate exists which was issued by the trust anchor. > While no certificate which contains keyUsage with=20 > keyCertSign not set can be used as an intermediate CA=20 > certificate (see 6.1.4-n), section > 6.1.4 doesn't execute against the trust anchor so=20 > verification isn't expected to reject the use of a directly=20 > trusted certificate as a CA=20 > certificate. Section 6 isn't designed to handle a directly=20 > trusted EE certificate. I think that you could tweak this by=20 > defining a trust anchor using the CA's certificate, with a=20 > name constraint which permits your EE's DN and no other using=20 > initial-permitted-subtrees, although you'd be trusting the CA=20 > to reserve that DN for the entity you want. That way you'd=20 > get revocation check as well. Alternatively, you could write=20 > your own algorithm for directly trusting EE certificates. >=20 > Tom Gindin >=20 >=20 >=20 >=20 >=20 > "Bob Bell (rtbell)" > Sent by: owner-ietf-pkix@mail.imc.org > 06/09/2008 03:32 PM >=20 > To > "Santosh Chokhani" , cc >=20 > Subject > RE: RFC 5280 Question >=20 >=20 >=20 >=20 >=20 >=20 > Santosh, et al - > =20 > I appreciate your response. I agree that there is a potential=20 > to have a problem if the acceptance/provisioning of trusted=20 > certs is not done securely. However, in this case, we are=20 > being very careful with that issue. > =20 > As to the "spawning a bogus hierarchy", if the cert in the=20 > trust list does not have the CA bit set in the usage, then it=20 > cannot be used to sign other certs, and thus cannot create=20 > this false hierarchy. Is that correct? > =20 > Bob >=20 > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > Sent: Monday, 09 June, 2008 11:42 > To: Bob Bell (rtbell); ietf-pkix@imc.org > Subject: RE: RFC 5280 Question >=20 > Bob, > =20 > Neither X.509 nor 5280 explicitly address this. > =20 > But, one can safely assume that the standards imply that if a=20 > trusted certificate public key is required, there is no need=20 > for path development and validation. > =20 > That said, trusting an end certificate could invite security=20 > trouble depending on how this trusted certificate is handled. > =20 > As mentioned below ?trust anchor list? could be problematic. =20 > X.509 and 5280 do not require any checks on trust anchors and=20 > hence this end certificate could spawn a bogus hierarchy and=20 > the PK enabled applications could legitimately accept that hierarchy. >=20 > From: owner-ietf-pkix@mail.imc.org=20 > [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Bob Bell (rtbell) > Sent: Monday, June 09, 2008 12:29 PM > To: ietf-pkix@imc.org > Subject: RFC 5280 Question > =20 > Folks- > =20 > I am hoping someone can give me the answer to this. Does RFC=20 > 5280 adress the case where an end-entity certificate (not a=20 > CA cert) is installed in the trust anchor list by the user=20 > accepting the presented cert as authoritative and then the=20 > cert is subsequently presented (in a later access to the=20 > site). There should be no path search, since the presented=20 > cert is in the trust anchor list. So, where is it defined to=20 > accept the end-entity cert? > =20 > Thanks ---- Bob > =20 > Bob Bell > Cisco Systems, Inc. > 576 S. Brentwood Ln. > Bountiful, UT 84010 > 801-294-3034 (v) > 801-294-3023 (f) > 801-971-4200 (c) > rtbell@cisco.com > =20 >=20 >=20 From owner-ietf-pkix@mail.imc.org Mon Jun 9 17:31:53 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6928C3A6A49 for ; Mon, 9 Jun 2008 17:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxE99YIbuLVK for ; Mon, 9 Jun 2008 17:31:52 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5C25E3A6A0C for ; Mon, 9 Jun 2008 17:31:52 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A02DF0037421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 17:02:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A02DO9037420; Mon, 9 Jun 2008 17:02:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A02Ca4037411 for ; Mon, 9 Jun 2008 17:02:13 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.28.172.170]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1K5rJT-0003an-4E; Mon, 09 Jun 2008 20:02:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 9 Jun 2008 20:02:19 -0400 To: "Bob Bell (rtbell)" From: Stephen Kent Subject: RE: RFC 5280 Question Cc: "Tom Gindin" , , "Santosh Chokhani" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: >Tom - > >Actually, in our case, the cert is self-signed so the issuer and the subject >are the same. > >Bob Bob, An EE is not an issuer, so there seems to be a contradiction between what you describe and 5280, 3280, ... Steve From owner-ietf-pkix@mail.imc.org Mon Jun 9 17:40:07 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC3D3A6765 for ; Mon, 9 Jun 2008 17:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEybcYjzLYPN for ; Mon, 9 Jun 2008 17:40:06 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1D56E3A69DF for ; Mon, 9 Jun 2008 17:40:05 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A0BCdN039601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 17:11:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A0BBLT039599; Mon, 9 Jun 2008 17:11:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A0B9T9039583 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 17:11:10 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,614,1204531200"; d="p7s'?scan'208";a="31319227" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 09 Jun 2008 17:11:08 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5A0B8KW029824; Mon, 9 Jun 2008 17:11:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5A0B80M018761; Tue, 10 Jun 2008 00:11:08 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 17:11:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 17:11:05 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0152_01C8CA5C.2F236570" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxA References: From: "Bob Bell (rtbell)" To: "Stephen Kent" Cc: "Tom Gindin" , , "Santosh Chokhani" X-OriginalArrivalTime: 10 Jun 2008 00:11:08.0715 (UTC) FILETIME=[7B8E4FB0:01C8CA8E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5469; t=1213056669; x=1213920669; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=cW/T0SlrIVIv3eDuJ8nd4V5yqEWZvupKzMXKpek2Bf4=; b=ELcK+Sv/XgSymOVuuDcO8+LChAdu6xImcD8oWgTVcCbf7n3xghQ+C+Udc0 KZaxvyTc8/v1X1nFMwpXlrlA5b0wWmgnnn0F74X8dkkgpfc4aut6cJogeLQA Ung+C4myBq3YxvGeQMJTgVT3YodaMz+H72H6UgqADIQ52mdqBjuWo=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0152_01C8CA5C.2F236570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Steve - Ok, but a selfsigned certificate (such as that from IIS) is a end-entity cert in that it does not have the CA bit set in basic constraints, but still has both the issuer and the subject the same. I guess I am at a loss to figure out what to call it. Bob > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Monday, 09 June, 2008 18:02 > To: Bob Bell (rtbell) > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > Subject: RE: RFC 5280 Question > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > >Tom - > > > >Actually, in our case, the cert is self-signed so the issuer and the > >subject are the same. > > > >Bob > > Bob, > > An EE is not an issuer, so there seems to be a contradiction > between what you describe and 5280, 3280, ... > > > Steve > ------=_NextPart_000_0152_01C8CA5C.2F236570 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTAwMDExMDVaMCMGCSqGSIb3DQEJBDEWBBRlmA/MYWfslIBUEC47 U0QbJmqzPzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYBcJ5t3wxBKBv7rpRE0BuPDRVYH5FD6smhr5wpS51SKLMbkHnBxOxaAAFA19q2l3fL8lNHE vrR8ybC++JYpftR+qVnmEwtqIT7HyH5asYElxDWf9/cklKhHwB1ZVisNY+LSzIUQ+XTh2UZ7oJt8 GKXz1RK89pt3c8lLG3HAXQrZsQAAAAAAAA== ------=_NextPart_000_0152_01C8CA5C.2F236570-- From owner-ietf-pkix@mail.imc.org Mon Jun 9 18:26:32 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32243A68C7 for ; Mon, 9 Jun 2008 18:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMc1nVlFLR83 for ; Mon, 9 Jun 2008 18:26:32 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9333D3A688D for ; Mon, 9 Jun 2008 18:26:31 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A0vKW4050062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 17:57:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A0vKWn050061; Mon, 9 Jun 2008 17:57:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5A0vJAx050052 for ; Mon, 9 Jun 2008 17:57:19 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 25100 invoked from network); 10 Jun 2008 00:47:05 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 00:47:05 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 00:47:05 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 20:57:17 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeA= References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , "Stephen Kent" Cc: "Tom Gindin" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In any certificate whose public key is used, the subject DN represents the holder of the companion private. This is true for self-signed certificates and other trust anchor formats also. -----Original Message----- From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 8:11 PM To: Stephen Kent Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani Subject: RE: RFC 5280 Question Steve - Ok, but a selfsigned certificate (such as that from IIS) is a end-entity cert in that it does not have the CA bit set in basic constraints, but still has both the issuer and the subject the same. I guess I am at a loss to figure out what to call it. Bob=20 > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com]=20 > Sent: Monday, 09 June, 2008 18:02 > To: Bob Bell (rtbell) > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > Subject: RE: RFC 5280 Question >=20 > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > >Tom - > > > >Actually, in our case, the cert is self-signed so the issuer and the=20 > >subject are the same. > > > >Bob >=20 > Bob, >=20 > An EE is not an issuer, so there seems to be a contradiction=20 > between what you describe and 5280, 3280, ... >=20 >=20 > Steve >=20 From owner-ietf-pkix@mail.imc.org Mon Jun 9 18:29:13 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E513A68F2 for ; Mon, 9 Jun 2008 18:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iE-hv1mOTwR0 for ; Mon, 9 Jun 2008 18:29:11 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 57DF33A68D5 for ; Mon, 9 Jun 2008 18:29:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A10T1u050505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 18:00:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A10T4C050504; Mon, 9 Jun 2008 18:00:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A10RfT050488 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 18:00:28 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,615,1204531200"; d="p7s'?scan'208";a="110973072" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2008 18:00:27 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5A10Qgb027077; Mon, 9 Jun 2008 18:00:26 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5A10Qnh008568; Tue, 10 Jun 2008 01:00:26 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 18:00:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 18:00:23 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_015C_01C8CA63.1247FD60" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeAAAGjVwA== References: From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , "Stephen Kent" Cc: "Tom Gindin" , X-OriginalArrivalTime: 10 Jun 2008 01:00:26.0781 (UTC) FILETIME=[5EB35CD0:01C8CA95] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6599; t=1213059626; x=1213923626; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=scO/61m2IILOyNGogUtx7eEoMxPjsnWuSsqpwn1HrFw=; b=mB3EognUDPQ98OOnr78w6ejSGVP7BJR5Q0/R5i1xDzy44ext9rCFPPXfbL fkigw59+HcIHnPk6K+lPvPYkcF3T9DmiUiQuazK+OfyRd+YktWflqxmja50P TfjEU+XctY; Authentication-Results: sj-dkim-4; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_015C_01C8CA63.1247FD60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - That is my understanding as well. If the issuer name and the subject name are the same, then the only real thing that it indicates is that there is no higher authority vouching for the association between the name and private key. Hence, if you do not trust the cert as it stands, there is no where else to go to get any other confirmation. Bob > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > Sent: Monday, 09 June, 2008 18:57 > To: Bob Bell (rtbell); Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > In any certificate whose public key is used, the subject DN > represents the holder of the companion private. This is true > for self-signed certificates and other trust anchor formats also. > > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 8:11 PM > To: Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > Subject: RE: RFC 5280 Question > > Steve - > > Ok, but a selfsigned certificate (such as that from IIS) is a > end-entity cert in that it does not have the CA bit set in > basic constraints, but still has both the issuer and the > subject the same. I guess I am at a loss to figure out what > to call it. > > Bob > > > -----Original Message----- > > From: Stephen Kent [mailto:kent@bbn.com] > > Sent: Monday, 09 June, 2008 18:02 > > To: Bob Bell (rtbell) > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > Subject: RE: RFC 5280 Question > > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > > >Tom - > > > > > >Actually, in our case, the cert is self-signed so the > issuer and the > > >subject are the same. > > > > > >Bob > > > > Bob, > > > > An EE is not an issuer, so there seems to be a > contradiction between > > what you describe and 5280, 3280, ... > > > > > > Steve > > > ------=_NextPart_000_015C_01C8CA63.1247FD60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTAwMTAwMjNaMCMGCSqGSIb3DQEJBDEWBBRtu+7+wHQ6S/mbtyT3 Aom9RfeEcjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYADociCJd5RcOXqFmOzlcdSUFersz4kiY1Is7ZkSC5MPFl5oGgB9Fv7uoqYEEMO7G6K1tzj uJrex+nIwClgBZsviLnC65DeEArxnvQGPVHq/gmgRi0duHEv9f2dMTuwh8q9TGBAERpqHHw18XIY RehLCJp3MGPFPabQGHMlnjGSigAAAAAAAA== ------=_NextPart_000_015C_01C8CA63.1247FD60-- From owner-ietf-pkix@mail.imc.org Mon Jun 9 20:01:56 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8213A6A2A for ; Mon, 9 Jun 2008 20:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upHRDlynSwGO for ; Mon, 9 Jun 2008 20:01:55 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id CBBF53A6980 for ; Mon, 9 Jun 2008 20:01:54 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A2Rwlo070298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 19:27:58 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A2RwIi070297; Mon, 9 Jun 2008 19:27:58 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5A2RuW3070282 for ; Mon, 9 Jun 2008 19:27:57 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 25722 invoked from network); 10 Jun 2008 02:17:42 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 02:17:42 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 02:17:42 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 22:27:55 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeAAAGjVwAACjncg References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , "Stephen Kent" Cc: "Tom Gindin" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, I hate to drag precision into this. Having the issuer and subject name the same does not mean that there is no higher authority. This can be a self-issued certificate and need not be self-signed. When a self-issued certificate is not self-signed, there can and should and needs to be a trust anchor or chain of certificates emanating from a trust anchor that verifies the self-issued certificate. Security or lack thereof for self-issued certificate is another matter outside the scope of this thread. -----Original Message----- From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 9:00 PM To: Santosh Chokhani; Stephen Kent Cc: Tom Gindin; ietf-pkix@imc.org Subject: RE: RFC 5280 Question Santosh -=20 That is my understanding as well. If the issuer name and the subject name are the same, then the only real thing that it indicates is that there is no higher authority vouching for the association between the name and private key. Hence, if you do not trust the cert as it stands, there is no where else to go to get any other confirmation. Bob=20 > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 > Sent: Monday, 09 June, 2008 18:57 > To: Bob Bell (rtbell); Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question >=20 > In any certificate whose public key is used, the subject DN=20 > represents the holder of the companion private. This is true=20 > for self-signed certificates and other trust anchor formats also. >=20 > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 8:11 PM > To: Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > Subject: RE: RFC 5280 Question >=20 > Steve - >=20 > Ok, but a selfsigned certificate (such as that from IIS) is a=20 > end-entity cert in that it does not have the CA bit set in=20 > basic constraints, but still has both the issuer and the=20 > subject the same. I guess I am at a loss to figure out what=20 > to call it. >=20 > Bob=20 >=20 > > -----Original Message----- > > From: Stephen Kent [mailto:kent@bbn.com] > > Sent: Monday, 09 June, 2008 18:02 > > To: Bob Bell (rtbell) > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > Subject: RE: RFC 5280 Question > >=20 > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > > >Tom - > > > > > >Actually, in our case, the cert is self-signed so the=20 > issuer and the=20 > > >subject are the same. > > > > > >Bob > >=20 > > Bob, > >=20 > > An EE is not an issuer, so there seems to be a=20 > contradiction between=20 > > what you describe and 5280, 3280, ... > >=20 > >=20 > > Steve > >=20 >=20 From owner-ietf-pkix@mail.imc.org Mon Jun 9 20:12:59 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554AC3A6A34 for ; Mon, 9 Jun 2008 20:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcpZ4QCUFb8o for ; Mon, 9 Jun 2008 20:12:57 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2AFC33A6A33 for ; Mon, 9 Jun 2008 20:12:56 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A2iOW5074573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 19:44:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A2iOMv074572; Mon, 9 Jun 2008 19:44:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A2iNBa074556 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 19:44:23 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,615,1204531200"; d="p7s'?scan'208";a="55127054" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Jun 2008 19:44:10 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5A2iAsp021602; Mon, 9 Jun 2008 19:44:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5A2iArF029238; Tue, 10 Jun 2008 02:44:10 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 19:44:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 19:44:07 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0172_01C8CA71.8FC44920" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeAAAGjVwAACjncgAACm82A= References: From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , "Stephen Kent" Cc: "Tom Gindin" , X-OriginalArrivalTime: 10 Jun 2008 02:44:10.0674 (UTC) FILETIME=[DC6E1120:01C8CAA3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8720; t=1213065850; x=1213929850; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=D/7N812G86HATRMYKbgPGSbdgOlgeJIgZ+wq1Nazs2A=; b=aGJKh8JiQF4s9J0+WnK+LARB8jTBpDTDqXmwPz8/NuguRdwO3c4PiHGV5/ d4toL4vmqVOFafnGynraut67YI2U3j9crmtK0PD+5eB6EDr1DeKWFxSF/nQR +LAU8JhSSba/ewlBx9YVGM2pTveUQZmwtWCs2bO0jPi3w51CU/jhI=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0172_01C8CA71.8FC44920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - Ok. I guess I have never heard of a difference between self-signed and self-issued. In the case of self-signed, the issuer and subject is the same and there is no chain to go up to verify a higher authority (unless you speak of some form of the CRL list source or the OCSP source, in which case, unless you have a pre-existent trust anchor for that, there is no way to verify the signature of the CRL/OCSP response). Since I had not heard of a self-issued cert, I went to google and looked. I came across this url for a message thread discussing the various types of self-issued certificates. http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html As I read the various definitions and discussion points, it seems to me that my End-Entity certificate is a type D self-issued certificate as opposed to a self-signed certificate as I understood it. Does this email thread represent a correct opinion??? Bob > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > Sent: Monday, 09 June, 2008 20:28 > To: Bob Bell (rtbell); Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Bob, > > I hate to drag precision into this. > > Having the issuer and subject name the same does not mean > that there is no higher authority. This can be a self-issued > certificate and need not be self-signed. > > When a self-issued certificate is not self-signed, there can > and should and needs to be a trust anchor or chain of > certificates emanating from a trust anchor that verifies the > self-issued certificate. > > Security or lack thereof for self-issued certificate is > another matter outside the scope of this thread. > > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 9:00 PM > To: Santosh Chokhani; Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Santosh - > > That is my understanding as well. If the issuer name and the > subject name are the same, then the only real thing that it > indicates is that there is no higher authority vouching for > the association between the name and private key. Hence, if > you do not trust the cert as it stands, there is no where > else to go to get any other confirmation. > > Bob > > > -----Original Message----- > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > > Sent: Monday, 09 June, 2008 18:57 > > To: Bob Bell (rtbell); Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > > > > In any certificate whose public key is used, the subject DN > represents > > the holder of the companion private. This is true for self-signed > > certificates and other trust anchor formats also. > > > > -----Original Message----- > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > > Sent: Monday, June 09, 2008 8:11 PM > > To: Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > Subject: RE: RFC 5280 Question > > > > Steve - > > > > Ok, but a selfsigned certificate (such as that from IIS) is a > > end-entity cert in that it does not have the CA bit set in basic > > constraints, but still has both the issuer and the subject > the same. I > > guess I am at a loss to figure out what to call it. > > > > Bob > > > > > -----Original Message----- > > > From: Stephen Kent [mailto:kent@bbn.com] > > > Sent: Monday, 09 June, 2008 18:02 > > > To: Bob Bell (rtbell) > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > > Subject: RE: RFC 5280 Question > > > > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > > > >Tom - > > > > > > > >Actually, in our case, the cert is self-signed so the > > issuer and the > > > >subject are the same. > > > > > > > >Bob > > > > > > Bob, > > > > > > An EE is not an issuer, so there seems to be a > > contradiction between > > > what you describe and 5280, 3280, ... > > > > > > > > > Steve > > > > > > ------=_NextPart_000_0172_01C8CA71.8FC44920 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTAwMjQ0MDdaMCMGCSqGSIb3DQEJBDEWBBSLiBGsoBVU6FVpD65w VGrusSF/EjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYA8arFJlEQEpFh4ldi0X6gQEQN/eBXHaGyK6VJdMHc30f+bkhzDJkzwGDWEciE8BXnAoQVO T8jNesuc/gWHXfO+LubpN9Agoq3HtTHouhIwLgSRo261A98ZGPiYbdgD6Z3SP61iCPdBut6784mG CECZXq0AJ8GYhCr9Hv05Q8YN+QAAAAAAAA== ------=_NextPart_000_0172_01C8CA71.8FC44920-- From owner-ietf-pkix@mail.imc.org Mon Jun 9 20:31:30 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D04F3A68D2 for ; Mon, 9 Jun 2008 20:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcfuN512LD9q for ; Mon, 9 Jun 2008 20:31:28 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D24FA3A67EC for ; Mon, 9 Jun 2008 20:31:27 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A37d95080290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 20:07:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A37dW0080288; Mon, 9 Jun 2008 20:07:39 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A37a13080268 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 20:07:36 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,615,1204531200"; d="p7s'?scan'208";a="111015961" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2008 20:07:35 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5A37Zak011984; Mon, 9 Jun 2008 20:07:35 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5A37Zpl022180; Tue, 10 Jun 2008 03:07:35 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 20:07:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 20:03:40 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_018D_01C8CA74.4B0A9160" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeAAAGjVwAACjncgAACm82AAAOYWIAAAO5nQ References: From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , "Stephen Kent" Cc: "Tom Gindin" , X-OriginalArrivalTime: 10 Jun 2008 03:07:35.0719 (UTC) FILETIME=[21E6EB70:01C8CAA7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10001; t=1213067255; x=1213931255; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=maWwlvrni7WCC3UgxSzBb3UyW8H3gvy3yz7UconnEFo=; b=cBmDXtMnbNpv1jffqPQt+M8maOMUF5zCejn9Ie+jVg3OmSBDIAeMUjzech TvQn82cRAYYZqhLK9HO4mlZmnlXQlU1yyoZUgyAEH90gN5w5SqoULWB99kfX rhTyOhMkEDiqyQfyFf+10gUJnBdsBdLk3l7MZPem9brhoiOrlI/6w=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_018D_01C8CA74.4B0A9160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - So, my cert is in fact a self-signed cert (self-issued type A). Is that correct? Bob > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > Sent: Monday, 09 June, 2008 21:01 > To: Bob Bell (rtbell); Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Bob, > > A self-signed certificate is a self-issued certificate whose > signature can be verified by using the subject public key in > the certificate itself. > > From what you described before, it was an end entity > certificate which you explicitly trusted. Thus, it need not > be a self-issued certificate. > > If the CA issued itself an end entity certificate, it would > be Type D as you noted. > > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 10:44 PM > To: Santosh Chokhani; Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Santosh - > > Ok. I guess I have never heard of a difference between > self-signed and self-issued. In the case of self-signed, the > issuer and subject is the same and there is no chain to go up > to verify a higher authority (unless you speak of some form > of the CRL list source or the OCSP source, in which case, > unless you have a pre-existent trust anchor for that, there > is no way to verify the signature of the CRL/OCSP response). > Since I had not heard of a self-issued cert, I went to google > and looked. I came across this url for a message thread > discussing the various types of self-issued certificates. > > http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html > > As I read the various definitions and discussion points, it > seems to me that my End-Entity certificate is a type D > self-issued certificate as opposed to a self-signed > certificate as I understood it. Does this email thread > represent a correct opinion??? > > Bob > > > -----Original Message----- > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > > Sent: Monday, 09 June, 2008 20:28 > > To: Bob Bell (rtbell); Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > > > > Bob, > > > > I hate to drag precision into this. > > > > Having the issuer and subject name the same does not mean > that there > > is no higher authority. This can be a self-issued certificate and > > need not be self-signed. > > > > When a self-issued certificate is not self-signed, there can and > > should and needs to be a trust anchor or chain of certificates > > emanating from a trust anchor that verifies the self-issued > > certificate. > > > > Security or lack thereof for self-issued certificate is > another matter > > outside the scope of this thread. > > > > -----Original Message----- > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > > Sent: Monday, June 09, 2008 9:00 PM > > To: Santosh Chokhani; Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > > > > Santosh - > > > > That is my understanding as well. If the issuer name and > the subject > > name are the same, then the only real thing that it > indicates is that > > there is no higher authority vouching for the association > between the > > name and private key. Hence, if you do not trust the cert as it > > stands, there is no where else to go to get any other confirmation. > > > > Bob > > > > > -----Original Message----- > > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > > > Sent: Monday, 09 June, 2008 18:57 > > > To: Bob Bell (rtbell); Stephen Kent > > > Cc: Tom Gindin; ietf-pkix@imc.org > > > Subject: RE: RFC 5280 Question > > > > > > In any certificate whose public key is used, the subject DN > > represents > > > the holder of the companion private. This is true for > self-signed > > > certificates and other trust anchor formats also. > > > > > > -----Original Message----- > > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > > > Sent: Monday, June 09, 2008 8:11 PM > > > To: Stephen Kent > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > > Subject: RE: RFC 5280 Question > > > > > > Steve - > > > > > > Ok, but a selfsigned certificate (such as that from IIS) is a > > > end-entity cert in that it does not have the CA bit set in basic > > > constraints, but still has both the issuer and the subject > > the same. I > > > guess I am at a loss to figure out what to call it. > > > > > > Bob > > > > > > > -----Original Message----- > > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sent: Monday, 09 June, 2008 18:02 > > > > To: Bob Bell (rtbell) > > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > > > Subject: RE: RFC 5280 Question > > > > > > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > > > > >Tom - > > > > > > > > > >Actually, in our case, the cert is self-signed so the > > > issuer and the > > > > >subject are the same. > > > > > > > > > >Bob > > > > > > > > Bob, > > > > > > > > An EE is not an issuer, so there seems to be a > > > contradiction between > > > > what you describe and 5280, 3280, ... > > > > > > > > > > > > Steve > > > > > > > > > > ------=_NextPart_000_018D_01C8CA74.4B0A9160 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTAwMzAzNDBaMCMGCSqGSIb3DQEJBDEWBBRjEi9f8PANJhZytCqg Q24IqFjM3jBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYAitptNQiZpi4K+v2zfj/2oDj3qi2Cbb4V9p2repawlwcU7sLXVH6474S11WPKA0E5JTO09 QC1kZAgGdFYxv42wG2Bev2nXjNmbTKwkYT+4+KOllmABnVA/Arr2eweZiziY/SD6TycPknngVL/f X7qkSgDkL6zD4OD8gstjEnviRgAAAAAAAA== ------=_NextPart_000_018D_01C8CA74.4B0A9160-- From owner-ietf-pkix@mail.imc.org Mon Jun 9 21:15:00 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B2828B56A for ; Mon, 9 Jun 2008 21:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfA9Xlvog+DL for ; Mon, 9 Jun 2008 21:14:59 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id CD3F03A6A7D for ; Mon, 9 Jun 2008 21:14:58 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A30sZS078774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 20:00:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A30s2s078773; Mon, 9 Jun 2008 20:00:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5A30p2h078752 for ; Mon, 9 Jun 2008 20:00:52 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 25920 invoked from network); 10 Jun 2008 02:50:37 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 02:50:37 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 02:50:37 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 23:00:50 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeAAAGjVwAACjncgAACm82AAAOYWIA== References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , "Stephen Kent" Cc: "Tom Gindin" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, A self-signed certificate is a self-issued certificate whose signature can be verified by using the subject public key in the certificate itself. >From what you described before, it was an end entity certificate which you explicitly trusted. Thus, it need not be a self-issued certificate. If the CA issued itself an end entity certificate, it would be Type D as you noted. -----Original Message----- From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 10:44 PM To: Santosh Chokhani; Stephen Kent Cc: Tom Gindin; ietf-pkix@imc.org Subject: RE: RFC 5280 Question Santosh - Ok. I guess I have never heard of a difference between self-signed and self-issued. In the case of self-signed, the issuer and subject is the same and there is no chain to go up to verify a higher authority (unless you speak of some form of the CRL list source or the OCSP source, in which case, unless you have a pre-existent trust anchor for that, there is no way to verify the signature of the CRL/OCSP response). Since I had not heard of a self-issued cert, I went to google and looked. I came across this url for a message thread discussing the various types of self-issued certificates. http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html As I read the various definitions and discussion points, it seems to me that my End-Entity certificate is a type D self-issued certificate as opposed to a self-signed certificate as I understood it. Does this email thread represent a correct opinion??? Bob > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 > Sent: Monday, 09 June, 2008 20:28 > To: Bob Bell (rtbell); Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question >=20 > Bob, >=20 > I hate to drag precision into this. >=20 > Having the issuer and subject name the same does not mean=20 > that there is no higher authority. This can be a self-issued=20 > certificate and need not be self-signed. >=20 > When a self-issued certificate is not self-signed, there can=20 > and should and needs to be a trust anchor or chain of=20 > certificates emanating from a trust anchor that verifies the=20 > self-issued certificate. >=20 > Security or lack thereof for self-issued certificate is=20 > another matter outside the scope of this thread. >=20 > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 9:00 PM > To: Santosh Chokhani; Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question >=20 > Santosh -=20 >=20 > That is my understanding as well. If the issuer name and the=20 > subject name are the same, then the only real thing that it=20 > indicates is that there is no higher authority vouching for=20 > the association between the name and private key. Hence, if=20 > you do not trust the cert as it stands, there is no where=20 > else to go to get any other confirmation. >=20 > Bob=20 >=20 > > -----Original Message----- > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > > Sent: Monday, 09 June, 2008 18:57 > > To: Bob Bell (rtbell); Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > >=20 > > In any certificate whose public key is used, the subject DN=20 > represents=20 > > the holder of the companion private. This is true for self-signed=20 > > certificates and other trust anchor formats also. > >=20 > > -----Original Message----- > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > > Sent: Monday, June 09, 2008 8:11 PM > > To: Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > Subject: RE: RFC 5280 Question > >=20 > > Steve - > >=20 > > Ok, but a selfsigned certificate (such as that from IIS) is a=20 > > end-entity cert in that it does not have the CA bit set in basic=20 > > constraints, but still has both the issuer and the subject=20 > the same. I=20 > > guess I am at a loss to figure out what to call it. > >=20 > > Bob > >=20 > > > -----Original Message----- > > > From: Stephen Kent [mailto:kent@bbn.com] > > > Sent: Monday, 09 June, 2008 18:02 > > > To: Bob Bell (rtbell) > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > > Subject: RE: RFC 5280 Question > > >=20 > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > > > >Tom - > > > > > > > >Actually, in our case, the cert is self-signed so the > > issuer and the > > > >subject are the same. > > > > > > > >Bob > > >=20 > > > Bob, > > >=20 > > > An EE is not an issuer, so there seems to be a > > contradiction between > > > what you describe and 5280, 3280, ... > > >=20 > > >=20 > > > Steve > > >=20 > >=20 >=20 From owner-ietf-pkix@mail.imc.org Tue Jun 10 04:16:14 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCAF23A69CF for ; Tue, 10 Jun 2008 04:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_TW=1.335, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLl5NBSbDI29 for ; Tue, 10 Jun 2008 04:16:13 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DBF583A6829 for ; Tue, 10 Jun 2008 04:16:12 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AAa23d090146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 03:36:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AAa2V1090145; Tue, 10 Jun 2008 03:36:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scan2.cht.com.tw (scan2.cht.com.tw [202.39.168.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AAa0vO090126 for ; Tue, 10 Jun 2008 03:36:01 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from scan2.cht.com.tw (unknown [127.0.0.1]) by scan2.cht.com.tw (Symantec Mail Security) with ESMTP id 3703B1544B5; Tue, 10 Jun 2008 18:35:59 +0800 (CST) X-AuditID: 0aa00267-a819dba000000b57-af-484e590e4f67 Received: from wcwang (unknown [10.144.133.6]) by scan2.cht.com.tw (Symantec Mail Security) with SMTP id E62721544AB; Tue, 10 Jun 2008 18:35:58 +0800 (CST) Message-ID: <00c901c8cae5$c57e00f0$0685900a@wcwang> From: "Wen-Cheng Wang" To: "Bob Bell \(rtbell\)" Cc: References: Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 18:35:53 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, Since it is a certificate which you decide to directly trust, it does not matter whether it is self-signed, self-issued, or issued by any other entity. It even does not matter whether it is an EE certificate or a CA certificate. You do not even need to check the signature of the certificate. This directly trusted certificate can be viewed simply as a container to convey the public key and subject DN (as well as other useful information of the subject) to your applications. Since you directly trust the binding between the public key and certificate subject (which I guess it will be a device in your case), you can use the certificate as if it has passed a full certificate path validation. However, if you directly trust a certificate in that fashion, the validation of the certificate is outside of the scope of the validation algorithm of RFC 5280 (or RFC 3280). That means you have to have an out-of-band mechanism to verify and track the trustworthiness of the certificate, otherwise your applications will be fragile under man-in-the-middle attacks. Another issue you have to take into consideration is that it will be hard for the sys admin to correctly verify and track the trustworthiness of certificates if their amount becomes large. Wen-Cheng Wang ----- Original Message ----- From: "Bob Bell (rtbell)" To: "Santosh Chokhani" ; "Stephen Kent" Cc: "Tom Gindin" ; Sent: Tuesday, June 10, 2008 11:03 AM Subject: RE: RFC 5280 Question > Santosh - > > So, my cert is in fact a self-signed cert (self-issued type A). Is that > correct? > > Bob > >> -----Original Message----- >> From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >> Sent: Monday, 09 June, 2008 21:01 >> To: Bob Bell (rtbell); Stephen Kent >> Cc: Tom Gindin; ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> Bob, >> >> A self-signed certificate is a self-issued certificate whose >> signature can be verified by using the subject public key in >> the certificate itself. >> >> From what you described before, it was an end entity >> certificate which you explicitly trusted. Thus, it need not >> be a self-issued certificate. >> >> If the CA issued itself an end entity certificate, it would >> be Type D as you noted. >> >> -----Original Message----- >> From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] >> Sent: Monday, June 09, 2008 10:44 PM >> To: Santosh Chokhani; Stephen Kent >> Cc: Tom Gindin; ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> Santosh - >> >> Ok. I guess I have never heard of a difference between >> self-signed and self-issued. In the case of self-signed, the >> issuer and subject is the same and there is no chain to go up >> to verify a higher authority (unless you speak of some form >> of the CRL list source or the OCSP source, in which case, >> unless you have a pre-existent trust anchor for that, there >> is no way to verify the signature of the CRL/OCSP response). >> Since I had not heard of a self-issued cert, I went to google >> and looked. I came across this url for a message thread >> discussing the various types of self-issued certificates. >> >> http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html >> >> As I read the various definitions and discussion points, it >> seems to me that my End-Entity certificate is a type D >> self-issued certificate as opposed to a self-signed >> certificate as I understood it. Does this email thread >> represent a correct opinion??? >> >> Bob >> >> > -----Original Message----- >> > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >> > Sent: Monday, 09 June, 2008 20:28 >> > To: Bob Bell (rtbell); Stephen Kent >> > Cc: Tom Gindin; ietf-pkix@imc.org >> > Subject: RE: RFC 5280 Question >> > >> > Bob, >> > >> > I hate to drag precision into this. >> > >> > Having the issuer and subject name the same does not mean >> that there >> > is no higher authority. This can be a self-issued certificate and >> > need not be self-signed. >> > >> > When a self-issued certificate is not self-signed, there can and >> > should and needs to be a trust anchor or chain of certificates >> > emanating from a trust anchor that verifies the self-issued >> > certificate. >> > >> > Security or lack thereof for self-issued certificate is >> another matter >> > outside the scope of this thread. >> > >> > -----Original Message----- >> > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] >> > Sent: Monday, June 09, 2008 9:00 PM >> > To: Santosh Chokhani; Stephen Kent >> > Cc: Tom Gindin; ietf-pkix@imc.org >> > Subject: RE: RFC 5280 Question >> > >> > Santosh - >> > >> > That is my understanding as well. If the issuer name and >> the subject >> > name are the same, then the only real thing that it >> indicates is that >> > there is no higher authority vouching for the association >> between the >> > name and private key. Hence, if you do not trust the cert as it >> > stands, there is no where else to go to get any other confirmation. >> > >> > Bob >> > >> > > -----Original Message----- >> > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >> > > Sent: Monday, 09 June, 2008 18:57 >> > > To: Bob Bell (rtbell); Stephen Kent >> > > Cc: Tom Gindin; ietf-pkix@imc.org >> > > Subject: RE: RFC 5280 Question >> > > >> > > In any certificate whose public key is used, the subject DN >> > represents >> > > the holder of the companion private. This is true for >> self-signed >> > > certificates and other trust anchor formats also. >> > > >> > > -----Original Message----- >> > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] >> > > Sent: Monday, June 09, 2008 8:11 PM >> > > To: Stephen Kent >> > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani >> > > Subject: RE: RFC 5280 Question >> > > >> > > Steve - >> > > >> > > Ok, but a selfsigned certificate (such as that from IIS) is a >> > > end-entity cert in that it does not have the CA bit set in basic >> > > constraints, but still has both the issuer and the subject >> > the same. I >> > > guess I am at a loss to figure out what to call it. >> > > >> > > Bob >> > > >> > > > -----Original Message----- >> > > > From: Stephen Kent [mailto:kent@bbn.com] >> > > > Sent: Monday, 09 June, 2008 18:02 >> > > > To: Bob Bell (rtbell) >> > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani >> > > > Subject: RE: RFC 5280 Question >> > > > >> > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: >> > > > >Tom - >> > > > > >> > > > >Actually, in our case, the cert is self-signed so the >> > > issuer and the >> > > > >subject are the same. >> > > > > >> > > > >Bob >> > > > >> > > > Bob, >> > > > >> > > > An EE is not an issuer, so there seems to be a >> > > contradiction between >> > > > what you describe and 5280, 3280, ... >> > > > >> > > > >> > > > Steve >> > > > >> > > >> > >> > From owner-ietf-pkix@mail.imc.org Tue Jun 10 07:03:50 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFEF3A69C9 for ; Tue, 10 Jun 2008 07:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSGGsUnG177T for ; Tue, 10 Jun 2008 07:03:46 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2D9673A6874 for ; Tue, 10 Jun 2008 07:03:45 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5ADQHkB034611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 06:26:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5ADQHkU034610; Tue, 10 Jun 2008 06:26:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5ADQFfm034603 for ; Tue, 10 Jun 2008 06:26:16 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 31777 invoked from network); 10 Jun 2008 13:16:01 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 13:16:01 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 13:15:59 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Tue, 10 Jun 2008 09:26:12 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeAAAGjVwAACjncgAACm82AAAOYWIAAAO5nQABW9MLA= References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , "Stephen Kent" Cc: "Tom Gindin" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, Why do not you send me the cert as a zip file (do not post it to the list) and I will tell you. -----Original Message----- From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 11:04 PM To: Santosh Chokhani; Stephen Kent Cc: Tom Gindin; ietf-pkix@imc.org Subject: RE: RFC 5280 Question Santosh -=20 So, my cert is in fact a self-signed cert (self-issued type A). Is that correct? Bob=20 > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 > Sent: Monday, 09 June, 2008 21:01 > To: Bob Bell (rtbell); Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question >=20 > Bob, >=20 > A self-signed certificate is a self-issued certificate whose=20 > signature can be verified by using the subject public key in=20 > the certificate itself. >=20 > From what you described before, it was an end entity=20 > certificate which you explicitly trusted. Thus, it need not=20 > be a self-issued certificate. >=20 > If the CA issued itself an end entity certificate, it would=20 > be Type D as you noted. >=20 > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 10:44 PM > To: Santosh Chokhani; Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question >=20 > Santosh - >=20 > Ok. I guess I have never heard of a difference between=20 > self-signed and self-issued. In the case of self-signed, the=20 > issuer and subject is the same and there is no chain to go up=20 > to verify a higher authority (unless you speak of some form=20 > of the CRL list source or the OCSP source, in which case,=20 > unless you have a pre-existent trust anchor for that, there=20 > is no way to verify the signature of the CRL/OCSP response).=20 > Since I had not heard of a self-issued cert, I went to google=20 > and looked. I came across this url for a message thread=20 > discussing the various types of self-issued certificates. >=20 > http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html >=20 > As I read the various definitions and discussion points, it=20 > seems to me that my End-Entity certificate is a type D=20 > self-issued certificate as opposed to a self-signed=20 > certificate as I understood it. Does this email thread=20 > represent a correct opinion??? >=20 > Bob >=20 > > -----Original Message----- > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > > Sent: Monday, 09 June, 2008 20:28 > > To: Bob Bell (rtbell); Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > >=20 > > Bob, > >=20 > > I hate to drag precision into this. > >=20 > > Having the issuer and subject name the same does not mean=20 > that there=20 > > is no higher authority. This can be a self-issued certificate and=20 > > need not be self-signed. > >=20 > > When a self-issued certificate is not self-signed, there can and=20 > > should and needs to be a trust anchor or chain of certificates=20 > > emanating from a trust anchor that verifies the self-issued=20 > > certificate. > >=20 > > Security or lack thereof for self-issued certificate is=20 > another matter=20 > > outside the scope of this thread. > >=20 > > -----Original Message----- > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > > Sent: Monday, June 09, 2008 9:00 PM > > To: Santosh Chokhani; Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > >=20 > > Santosh - > >=20 > > That is my understanding as well. If the issuer name and=20 > the subject=20 > > name are the same, then the only real thing that it=20 > indicates is that=20 > > there is no higher authority vouching for the association=20 > between the=20 > > name and private key. Hence, if you do not trust the cert as it=20 > > stands, there is no where else to go to get any other confirmation. > >=20 > > Bob > >=20 > > > -----Original Message----- > > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > > > Sent: Monday, 09 June, 2008 18:57 > > > To: Bob Bell (rtbell); Stephen Kent > > > Cc: Tom Gindin; ietf-pkix@imc.org > > > Subject: RE: RFC 5280 Question > > >=20 > > > In any certificate whose public key is used, the subject DN > > represents > > > the holder of the companion private. This is true for=20 > self-signed=20 > > > certificates and other trust anchor formats also. > > >=20 > > > -----Original Message----- > > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > > > Sent: Monday, June 09, 2008 8:11 PM > > > To: Stephen Kent > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > > Subject: RE: RFC 5280 Question > > >=20 > > > Steve - > > >=20 > > > Ok, but a selfsigned certificate (such as that from IIS) is a=20 > > > end-entity cert in that it does not have the CA bit set in basic=20 > > > constraints, but still has both the issuer and the subject > > the same. I > > > guess I am at a loss to figure out what to call it. > > >=20 > > > Bob > > >=20 > > > > -----Original Message----- > > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sent: Monday, 09 June, 2008 18:02 > > > > To: Bob Bell (rtbell) > > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > > > Subject: RE: RFC 5280 Question > > > >=20 > > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > > > > >Tom - > > > > > > > > > >Actually, in our case, the cert is self-signed so the > > > issuer and the > > > > >subject are the same. > > > > > > > > > >Bob > > > >=20 > > > > Bob, > > > >=20 > > > > An EE is not an issuer, so there seems to be a > > > contradiction between > > > > what you describe and 5280, 3280, ... > > > >=20 > > > >=20 > > > > Steve > > > >=20 > > >=20 > >=20 >=20 From owner-ietf-pkix@mail.imc.org Tue Jun 10 11:08:27 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07243A6873 for ; Tue, 10 Jun 2008 11:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMVvNWA6G0Os for ; Tue, 10 Jun 2008 11:08:26 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 91FDC3A68BD for ; Tue, 10 Jun 2008 11:08:24 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AHTsrs087570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 10:29:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AHTsJv087568; Tue, 10 Jun 2008 10:29:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AHTpWK087544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jun 2008 10:29:53 -0700 (MST) (envelope-from tim.polk@nist.gov) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5AHRghf025464; Tue, 10 Jun 2008 13:27:42 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Content-Transfer-Encoding: 7bit From: Tim Polk Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 13:27:44 -0400 To: Bob Bell (rtbell) X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, [I realize I am late to the party, and that Santosh, Steve, and Wen- Chen Wang have already provided a lot of good feedback. I decided to respond to the original message because I would like to go back to the perceived requirement.] It sounds like you want to construct a list of directly trusted EE certificates, but are trying to satisfy this requirement using the application's trust anchor store. There is nothing inherently wrong with direct trust (and RFC 5280 does not preclude directly trusting an EE certificate), but you really need a different - and far simpler - mechanism. The trust anchor store is implicitly linked to path discovery and validation, which are not relevant here since a directly trusted certificate cannot be validated. With a directly trusted certificate, there is also no mechanism to validate status information. To further complicate matters, storing the certificate you wish to directly trust in the trust anchor store implies that it is trusted to issue certificates as well. The path validation inputs specified in 6.1.1 (d) consider only four aspects of a trust anchor (name, public key algorithm, public key, and parameters if needed). The assumption is that the trust anchor's authority to issue certificates was verified based on an out-of-band trust mechanism (which is out of scope for 5280). This makes sense since a trust anchor might have distributed a v1 certificate (which does not include extensions). As others have noted, direct trust also implies an out-of-band trust mechanism. I received the EE certificate from a trusted source so I can trust the binding between the subject name and the key; issuer name and the signature are irrelevant. If the certificate status matters, I am also depending on an out-of-band mechanism to inform me! The out-of-band mechanism(s) in combination with protected local storage provide the basis for security in this system... Trying to combine these two mechanisms using a single certificate store probably requires an additional flag on every entry to differentiate between directly trusted certificates and trust anchors. Two separate stores might be cleaner in the long run. Thanks, Tim Polk On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > Folks- > > I am hoping someone can give me the answer to this. Does RFC 5280 > adress the case where an end-entity certificate (not a CA cert) is > installed in the trust anchor list by the user accepting the > presented cert as authoritative and then the cert is subsequently > presented (in a later access to the site). There should be no path > search, since the presented cert is in the trust anchor list. So, > where is it defined to accept the end-entity cert? > > Thanks ---- Bob > > Bob Bell > Cisco Systems, Inc. > 576 S. Brentwood Ln. > Bountiful, UT 84010 > 801-294-3034 (v) > 801-294-3023 (f) > 801-971-4200 (c) > rtbell@cisco.com > From owner-ietf-pkix@mail.imc.org Tue Jun 10 12:04:11 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E1A3A69F5 for ; Tue, 10 Jun 2008 12:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2iB7h+TPK2A for ; Tue, 10 Jun 2008 12:04:10 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C9AD63A6B21 for ; Tue, 10 Jun 2008 12:03:51 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AHbnV2089396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 10:37:49 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AHbn2V089395; Tue, 10 Jun 2008 10:37:49 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AHbl0n089388 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2008 10:37:48 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,618,1204531200"; d="p7s'?scan'208";a="55423491" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2008 10:37:47 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5AHblg5005175; Tue, 10 Jun 2008 10:37:47 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5AHblts027257; Tue, 10 Jun 2008 17:37:47 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 10:37:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Tue, 10 Jun 2008 10:37:44 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0020_01C8CAEE.65D4C810" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLH5o/QJYmHcoTTI+9xl3zcjOBuAAALHkA References: From: "Bob Bell (rtbell)" To: "Tim Polk" Cc: X-OriginalArrivalTime: 10 Jun 2008 17:37:46.0990 (UTC) FILETIME=[B23EA0E0:01C8CB20] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8591; t=1213119467; x=1213983467; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=2HLDEKsu9O296AXaZlh+39bRaE286WR8LDAdQPBSw/s=; b=ndnrLHF02tnFEzM/xF5rYgVeGzqCIYrll6dBHDYi6Z5Fzq0Sik/3M+ip47 c0XzskMBj9gaV8bIQXKOqc0r1rdtWl5pkGeTF9lvkqz7mmDNWHfG/ViwwK0N CPek1iToFP; Authentication-Results: sj-dkim-4; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C8CAEE.65D4C810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tim - I agree with your comments. The way we are using these certs is that if they do not have the CA bit set in basic constraints, then they cannot be used as a CA (i.e. they cannot vouch for additional certificates). According to everything I have read, if the CA bit is false, then it is an EE cert by definition. Two cert stores would be conceptually easier, but the constraints of openSSL make that a lot harder. I know that I am probably boring the world to death with these issues, I am simply trying to validate what is going one. Bob > -----Original Message----- > From: Tim Polk [mailto:tim.polk@nist.gov] > Sent: Tuesday, 10 June, 2008 11:28 > To: Bob Bell (rtbell) > Cc: ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > Bob, > > [I realize I am late to the party, and that Santosh, Steve, > and Wen- Chen Wang have already provided a lot of good > feedback. I decided to respond to the original message > because I would like to go back to the perceived requirement.] > > It sounds like you want to construct a list of directly > trusted EE certificates, but are trying to satisfy this > requirement using the application's trust anchor store. > There is nothing inherently wrong with direct trust (and RFC > 5280 does not preclude directly trusting an EE certificate), > but you really need a different - and far simpler > - mechanism. The trust anchor store is implicitly linked to > path discovery and validation, which are not relevant here > since a directly trusted certificate cannot be validated. > With a directly trusted certificate, there is also no > mechanism to validate status information. > > To further complicate matters, storing the certificate you > wish to directly trust in the trust anchor store implies that > it is trusted to issue certificates as well. The path > validation inputs specified in 6.1.1 (d) consider only four > aspects of a trust anchor (name, public key algorithm, public > key, and parameters if needed). The assumption is that the > trust anchor's authority to issue certificates was verified > based on an out-of-band trust mechanism (which is out of > scope for 5280). This makes sense since a trust anchor might > have distributed a v1 certificate (which does not include extensions). > > As others have noted, direct trust also implies an > out-of-band trust mechanism. I received the EE certificate > from a trusted source so I can trust the binding between the > subject name and the key; issuer > name and the signature are irrelevant. If the certificate status > matters, I am also depending on an out-of-band mechanism to > inform me! The out-of-band mechanism(s) in combination with > protected local storage provide the basis for security in > this system... > > Trying to combine these two mechanisms using a single > certificate store probably requires an additional flag on > every entry to differentiate between directly trusted > certificates and trust anchors. Two separate stores might be > cleaner in the long run. > > Thanks, > > Tim Polk > > On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > > > Folks- > > > > I am hoping someone can give me the answer to this. Does RFC 5280 > > adress the case where an end-entity certificate (not a CA cert) is > > installed in the trust anchor list by the user accepting > the presented > > cert as authoritative and then the cert is subsequently > presented (in > > a later access to the site). There should be no path > search, since the > > presented cert is in the trust anchor list. So, where is it > defined to > > accept the end-entity cert? > > > > Thanks ---- Bob > > > > Bob Bell > > Cisco Systems, Inc. > > 576 S. Brentwood Ln. > > Bountiful, UT 84010 > > 801-294-3034 (v) > > 801-294-3023 (f) > > 801-971-4200 (c) > > rtbell@cisco.com > > > > ------=_NextPart_000_0020_01C8CAEE.65D4C810 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTAxNzM3NDNaMCMGCSqGSIb3DQEJBDEWBBQ20DnsBkcgikU/MNpg dQlsEfqPFDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYCaky6DcZIa3/+YD8pzEFNwFtxaX+1ye4nzfkGi83FBCGE8YTW72mqhX4VTLoU87/Kj2qwY WbQ0pvsmNodgungngZVXEt75Kxcr7I2DrCLIU0IEyeD/mQ0pTEUeNsLAnQXpWAFVejSseEOYgNn1 1CTuBJPjiESaV5HPpXkCKMZreAAAAAAAAA== ------=_NextPart_000_0020_01C8CAEE.65D4C810-- From owner-ietf-pkix@mail.imc.org Tue Jun 10 12:23:32 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46AD83A6AA7 for ; Tue, 10 Jun 2008 12:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqiJ4RzhZ8Yc for ; Tue, 10 Jun 2008 12:23:29 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 851D13A6AFC for ; Tue, 10 Jun 2008 12:23:07 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AIZReU002334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 11:35:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AIZRuo002333; Tue, 10 Jun 2008 11:35:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AIZPGC002317 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2008 11:35:26 -0700 (MST) (envelope-from pritikin@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,618,1204531200"; d="scan'208";a="40137513" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2008 11:35:12 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id m5AIZCJC027617; Tue, 10 Jun 2008 11:35:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5AIZC2I028599; Tue, 10 Jun 2008 18:35:12 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 11:35:12 -0700 Received: from [10.0.1.200] ([10.32.244.67]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 11:35:11 -0700 Cc: Bob Bell (rtbell) , Message-Id: From: max pritikin To: Tim Polk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 13:35:10 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 18:35:11.0633 (UTC) FILETIME=[B7697010:01C8CB28] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4108; t=1213122912; x=1213986912; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20RFC=205280=20Question |Sender:=20; bh=MHZISWEiCpaSCbA8DJPCSqzvhtFyrLawBcGea/gUMfo=; b=Jbrmk2kGXYtYlprXB3VXvSq1ee75djfwNFdX63p78YgtzzyNR7/I+JPpuV GJJovN5zB1YeXZjyz58/P2eSafzSekxxbrIrGIVR/yPLP1qrWVd2OOfnWRcd PkH4hzWl0P; Authentication-Results: sj-dkim-8; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A few comments on this thread: 1) Any entry in the trust anchor store would seem to be "directly trusted". If so an additional flag isn't needed so much as a statement about how path validation proceeds if, during path discovery, it turns out the certificate being validated is already directly trusted. 2) Inclusion into the trust anchor store doesn't imply that a cert is trusted to issue certificates -- that is directly controlled by the values within the certificate (chain). 3) The out-of-band mechanism is out of scope for 5280/3280 but has been the subject of recent BoF work (and more?). It would nice if that work also addressed this question. Issues related to this come up on a regular basis. Look at the various ways browser deal with caching EE certificates to "trust this site always" etc. I think Bob has raised a good point. - max On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > > Bob, > > [I realize I am late to the party, and that Santosh, Steve, and Wen- > Chen Wang have already provided a lot of good feedback. I decided > to respond to the original message because I would like to go back > to the perceived requirement.] > > It sounds like you want to construct a list of directly trusted EE > certificates, but are trying to satisfy this requirement using the > application's trust anchor store. There is nothing inherently wrong > with direct trust (and RFC 5280 does not preclude directly trusting > an EE certificate), but you really need a different - and far > simpler - mechanism. The trust anchor store is implicitly linked to > path discovery and validation, which are not relevant here since a > directly trusted certificate cannot be validated. With a directly > trusted certificate, there is also no mechanism to validate status > information. > > To further complicate matters, storing the certificate you wish to > directly trust in the trust anchor store implies that it is trusted > to issue certificates as well. The path validation inputs specified > in 6.1.1 (d) consider only four aspects of a trust anchor (name, > public key algorithm, public key, and parameters if needed). The > assumption is that the trust anchor's authority to issue > certificates was verified based on an out-of-band trust mechanism > (which is out of scope for 5280). This makes sense since a trust > anchor might have distributed a v1 certificate (which does not > include extensions). > > As others have noted, direct trust also implies an out-of-band trust > mechanism. I received the EE certificate from a trusted source so I > can trust the binding between the subject name and the key; issuer > name and the signature are irrelevant. If the certificate status > matters, I am also depending on an out-of-band mechanism to inform > me! The out-of-band mechanism(s) in combination with protected > local storage provide the basis for security in this system... > > Trying to combine these two mechanisms using a single certificate > store probably requires an additional flag on every entry to > differentiate between directly trusted certificates and trust > anchors. Two separate stores might be cleaner in the long run. > > Thanks, > > Tim Polk > > On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > >> Folks- >> >> I am hoping someone can give me the answer to this. Does RFC 5280 >> adress the case where an end-entity certificate (not a CA cert) is >> installed in the trust anchor list by the user accepting the >> presented cert as authoritative and then the cert is subsequently >> presented (in a later access to the site). There should be no path >> search, since the presented cert is in the trust anchor list. So, >> where is it defined to accept the end-entity cert? >> >> Thanks ---- Bob >> >> Bob Bell >> Cisco Systems, Inc. >> 576 S. Brentwood Ln. >> Bountiful, UT 84010 >> 801-294-3034 (v) >> 801-294-3023 (f) >> 801-971-4200 (c) >> rtbell@cisco.com >> > From owner-ietf-pkix@mail.imc.org Tue Jun 10 12:55:43 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E773A6913 for ; Tue, 10 Jun 2008 12:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbpKgMMhdk0h for ; Tue, 10 Jun 2008 12:55:42 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DB5D23A692E for ; Tue, 10 Jun 2008 12:55:38 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AJ7HMd007978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 12:07:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AJ7Hsi007977; Tue, 10 Jun 2008 12:07:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5AJ7E1V007970 for ; Tue, 10 Jun 2008 12:07:15 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 2517 invoked from network); 10 Jun 2008 18:56:59 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 18:56:59 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 18:56:58 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Tue, 10 Jun 2008 15:07:12 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLK2Y+MLoyzThUQ1CKUG5yZuLDwQAAYdNA References: From: "Santosh Chokhani" To: "max pritikin" , "Tim Polk" Cc: "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, I do not agree with your point on item 2. Once a certificate is a trust anchor, neither X.509 not 5280 have any constraints on it from being a issuer. Furthermore, path length constraint if present in the self-signed certificate can be ignored by relying parties. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of max pritikin Sent: Tuesday, June 10, 2008 2:35 PM To: Tim Polk Cc: Bob Bell (rtbell); ietf-pkix@imc.org Subject: Re: RFC 5280 Question A few comments on this thread: 1) Any entry in the trust anchor store would seem to be "directly =20 trusted". If so an additional flag isn't needed so much as a statement =20 about how path validation proceeds if, during path discovery, it turns =20 out the certificate being validated is already directly trusted. 2) Inclusion into the trust anchor store doesn't imply that a cert is =20 trusted to issue certificates -- that is directly controlled by the =20 values within the certificate (chain). 3) The out-of-band mechanism is out of scope for 5280/3280 but has =20 been the subject of recent BoF work (and more?). It would nice if that =20 work also addressed this question. Issues related to this come up on a regular basis. Look at the various =20 ways browser deal with caching EE certificates to "trust this site =20 always" etc. I think Bob has raised a good point. - max On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > > Bob, > > [I realize I am late to the party, and that Santosh, Steve, and Wen-=20 > Chen Wang have already provided a lot of good feedback. I decided =20 > to respond to the original message because I would like to go back =20 > to the perceived requirement.] > > It sounds like you want to construct a list of directly trusted EE =20 > certificates, but are trying to satisfy this requirement using the =20 > application's trust anchor store. There is nothing inherently wrong =20 > with direct trust (and RFC 5280 does not preclude directly trusting =20 > an EE certificate), but you really need a different - and far =20 > simpler - mechanism. The trust anchor store is implicitly linked to =20 > path discovery and validation, which are not relevant here since a =20 > directly trusted certificate cannot be validated. With a directly =20 > trusted certificate, there is also no mechanism to validate status =20 > information. > > To further complicate matters, storing the certificate you wish to =20 > directly trust in the trust anchor store implies that it is trusted =20 > to issue certificates as well. The path validation inputs specified =20 > in 6.1.1 (d) consider only four aspects of a trust anchor (name, =20 > public key algorithm, public key, and parameters if needed). The =20 > assumption is that the trust anchor's authority to issue =20 > certificates was verified based on an out-of-band trust mechanism =20 > (which is out of scope for 5280). This makes sense since a trust =20 > anchor might have distributed a v1 certificate (which does not =20 > include extensions). > > As others have noted, direct trust also implies an out-of-band trust =20 > mechanism. I received the EE certificate from a trusted source so I =20 > can trust the binding between the subject name and the key; issuer =20 > name and the signature are irrelevant. If the certificate status =20 > matters, I am also depending on an out-of-band mechanism to inform =20 > me! The out-of-band mechanism(s) in combination with protected =20 > local storage provide the basis for security in this system... > > Trying to combine these two mechanisms using a single certificate =20 > store probably requires an additional flag on every entry to =20 > differentiate between directly trusted certificates and trust =20 > anchors. Two separate stores might be cleaner in the long run. > > Thanks, > > Tim Polk > > On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > >> Folks- >> >> I am hoping someone can give me the answer to this. Does RFC 5280 =20 >> adress the case where an end-entity certificate (not a CA cert) is =20 >> installed in the trust anchor list by the user accepting the =20 >> presented cert as authoritative and then the cert is subsequently =20 >> presented (in a later access to the site). There should be no path =20 >> search, since the presented cert is in the trust anchor list. So, =20 >> where is it defined to accept the end-entity cert? >> >> Thanks ---- Bob >> >> Bob Bell >> Cisco Systems, Inc. >> 576 S. Brentwood Ln. >> Bountiful, UT 84010 >> 801-294-3034 (v) >> 801-294-3023 (f) >> 801-971-4200 (c) >> rtbell@cisco.com >> > From owner-ietf-pkix@mail.imc.org Tue Jun 10 13:24:51 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5E93A6ABB for ; Tue, 10 Jun 2008 13:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhT-+NWmVIiA for ; Tue, 10 Jun 2008 13:24:50 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8FB7A3A6AA2 for ; Tue, 10 Jun 2008 13:24:49 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AJnHQU016536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 12:49:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AJnHnc016535; Tue, 10 Jun 2008 12:49:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ssc.lt (mail.ssc.lt [195.43.64.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AJnEeg016518 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jun 2008 12:49:15 -0700 (MST) (envelope-from md@e-net.lt) Received: from localhost ([127.0.0.1] helo=mail.ssc.lt) by mail.ssc.lt with esmtp (Exim 4.50) id 1K69pK-0008Ry-Hg; Tue, 10 Jun 2008 22:48:18 +0300 Received: from 213.226.190.190 (SquirrelMail authenticated user md@e-net.lt) by mail.ssc.lt with HTTP; Tue, 10 Jun 2008 22:48:18 +0300 (EEST) Message-ID: <27400.213.226.190.190.1213127298.squirrel@mail.ssc.lt> In-Reply-To: References: Date: Tue, 10 Jun 2008 22:48:18 +0300 (EEST) Subject: RE: RFC 5280 Question From: "Moudrick M. Dadashov" To: "Santosh Chokhani" Cc: "Bob Bell" , "Stephen Kent" , "Tom Gindin" , ietf-pkix@imc.org Reply-To: md@e-net.lt User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, can you please cc me a copy? Thanks. M.D. cell: +370-699-26662 On Tue, June 10, 2008 16:26, Santosh Chokhani wrote: > > Bob, > > Why do not you send me the cert as a zip file (do not post it to the > list) and I will tell you. > > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 11:04 PM > To: Santosh Chokhani; Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Santosh - > > So, my cert is in fact a self-signed cert (self-issued type A). Is that > correct? > > Bob > >> -----Original Message----- >> From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >> Sent: Monday, 09 June, 2008 21:01 >> To: Bob Bell (rtbell); Stephen Kent >> Cc: Tom Gindin; ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> Bob, >> >> A self-signed certificate is a self-issued certificate whose >> signature can be verified by using the subject public key in >> the certificate itself. >> >> From what you described before, it was an end entity >> certificate which you explicitly trusted. Thus, it need not >> be a self-issued certificate. >> >> If the CA issued itself an end entity certificate, it would >> be Type D as you noted. >> >> -----Original Message----- >> From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] >> Sent: Monday, June 09, 2008 10:44 PM >> To: Santosh Chokhani; Stephen Kent >> Cc: Tom Gindin; ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> Santosh - >> >> Ok. I guess I have never heard of a difference between >> self-signed and self-issued. In the case of self-signed, the >> issuer and subject is the same and there is no chain to go up >> to verify a higher authority (unless you speak of some form >> of the CRL list source or the OCSP source, in which case, >> unless you have a pre-existent trust anchor for that, there >> is no way to verify the signature of the CRL/OCSP response). >> Since I had not heard of a self-issued cert, I went to google >> and looked. I came across this url for a message thread >> discussing the various types of self-issued certificates. >> >> http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html >> >> As I read the various definitions and discussion points, it >> seems to me that my End-Entity certificate is a type D >> self-issued certificate as opposed to a self-signed >> certificate as I understood it. Does this email thread >> represent a correct opinion??? >> >> Bob >> >> > -----Original Message----- >> > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >> > Sent: Monday, 09 June, 2008 20:28 >> > To: Bob Bell (rtbell); Stephen Kent >> > Cc: Tom Gindin; ietf-pkix@imc.org >> > Subject: RE: RFC 5280 Question >> > >> > Bob, >> > >> > I hate to drag precision into this. >> > >> > Having the issuer and subject name the same does not mean >> that there >> > is no higher authority. This can be a self-issued certificate and >> > need not be self-signed. >> > >> > When a self-issued certificate is not self-signed, there can and >> > should and needs to be a trust anchor or chain of certificates >> > emanating from a trust anchor that verifies the self-issued >> > certificate. >> > >> > Security or lack thereof for self-issued certificate is >> another matter >> > outside the scope of this thread. >> > >> > -----Original Message----- >> > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] >> > Sent: Monday, June 09, 2008 9:00 PM >> > To: Santosh Chokhani; Stephen Kent >> > Cc: Tom Gindin; ietf-pkix@imc.org >> > Subject: RE: RFC 5280 Question >> > >> > Santosh - >> > >> > That is my understanding as well. If the issuer name and >> the subject >> > name are the same, then the only real thing that it >> indicates is that >> > there is no higher authority vouching for the association >> between the >> > name and private key. Hence, if you do not trust the cert as it >> > stands, there is no where else to go to get any other confirmation. >> > >> > Bob >> > >> > > -----Original Message----- >> > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >> > > Sent: Monday, 09 June, 2008 18:57 >> > > To: Bob Bell (rtbell); Stephen Kent >> > > Cc: Tom Gindin; ietf-pkix@imc.org >> > > Subject: RE: RFC 5280 Question >> > > >> > > In any certificate whose public key is used, the subject DN >> > represents >> > > the holder of the companion private. This is true for >> self-signed >> > > certificates and other trust anchor formats also. >> > > >> > > -----Original Message----- >> > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] >> > > Sent: Monday, June 09, 2008 8:11 PM >> > > To: Stephen Kent >> > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani >> > > Subject: RE: RFC 5280 Question >> > > >> > > Steve - >> > > >> > > Ok, but a selfsigned certificate (such as that from IIS) is a >> > > end-entity cert in that it does not have the CA bit set in basic >> > > constraints, but still has both the issuer and the subject >> > the same. I >> > > guess I am at a loss to figure out what to call it. >> > > >> > > Bob >> > > >> > > > -----Original Message----- >> > > > From: Stephen Kent [mailto:kent@bbn.com] >> > > > Sent: Monday, 09 June, 2008 18:02 >> > > > To: Bob Bell (rtbell) >> > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani >> > > > Subject: RE: RFC 5280 Question >> > > > >> > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: >> > > > >Tom - >> > > > > >> > > > >Actually, in our case, the cert is self-signed so the >> > > issuer and the >> > > > >subject are the same. >> > > > > >> > > > >Bob >> > > > >> > > > Bob, >> > > > >> > > > An EE is not an issuer, so there seems to be a >> > > contradiction between >> > > > what you describe and 5280, 3280, ... >> > > > >> > > > >> > > > Steve >> > > > >> > > >> > >> > > From owner-ietf-pkix@mail.imc.org Tue Jun 10 14:14:44 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035023A681B for ; Tue, 10 Jun 2008 14:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zucTFqD9lIZb for ; Tue, 10 Jun 2008 14:14:42 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2DE563A6806 for ; Tue, 10 Jun 2008 14:14:41 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AKkgxo028097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 13:46:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AKkgPt028096; Tue, 10 Jun 2008 13:46:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AKke9J028079 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2008 13:46:41 -0700 (MST) (envelope-from pritikin@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,619,1204531200"; d="scan'208";a="78242301" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2008 13:46:40 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5AKkeZI031964; Tue, 10 Jun 2008 13:46:40 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5AKkeRh029295; Tue, 10 Jun 2008 20:46:40 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 13:46:39 -0700 Received: from [10.0.1.200] ([10.32.244.67]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 13:46:39 -0700 Cc: "Tim Polk" , "Bob Bell (rtbell)" , Message-Id: From: max pritikin To: "Santosh Chokhani" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 15:46:38 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 20:46:39.0539 (UTC) FILETIME=[14F86030:01C8CB3B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5429; t=1213130800; x=1213994800; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20RFC=205280=20Question |Sender:=20; bh=LfOXYd/w3JtKcrbizn6bXjOydJ8AkfnuROKEelxi5FA=; b=YhWyiPpHYD51tfCbi+Oq1F8PyQdlFme6eDTPEIvX3SUqyiKESlX7tD+SsA wvMz3E9p511diSydTEFmlt8t9qfJ2MaqSFUmLJlEqRRqG5lsAaUmjk3qiCvs Yx7lyKaPbw; Authentication-Results: sj-dkim-3; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh, RFC5280 section 4.2.1.9 (Basic Constraints) says: > The cA boolean indicates whether the certified public key may be > used > to verify certificate signatures. If the cA boolean is not > asserted, > then the keyCertSign bit in the key usage extension MUST NOT be > asserted. If the basic constraints extension is not present in a > version 3 certificate, or the extension is present but the cA > boolean > is not asserted, then the certified public key MUST NOT be used to > verify certificate signatures. An EE certificate being in the trust store would not cause confusion about this. - max On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > Max, > > I do not agree with your point on item 2. Once a certificate is a > trust > anchor, neither X.509 not 5280 have any constraints on it from being a > issuer. > > Furthermore, path length constraint if present in the self-signed > certificate can be ignored by relying parties. > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org > ] > On Behalf Of max pritikin > Sent: Tuesday, June 10, 2008 2:35 PM > To: Tim Polk > Cc: Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > > A few comments on this thread: > > 1) Any entry in the trust anchor store would seem to be "directly > trusted". If so an additional flag isn't needed so much as a statement > about how path validation proceeds if, during path discovery, it turns > out the certificate being validated is already directly trusted. > > 2) Inclusion into the trust anchor store doesn't imply that a cert is > trusted to issue certificates -- that is directly controlled by the > values within the certificate (chain). > > 3) The out-of-band mechanism is out of scope for 5280/3280 but has > been the subject of recent BoF work (and more?). It would nice if that > work also addressed this question. > > Issues related to this come up on a regular basis. Look at the various > ways browser deal with caching EE certificates to "trust this site > always" etc. I think Bob has raised a good point. > > - max > > On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > >> >> Bob, >> >> [I realize I am late to the party, and that Santosh, Steve, and Wen- >> Chen Wang have already provided a lot of good feedback. I decided >> to respond to the original message because I would like to go back >> to the perceived requirement.] >> >> It sounds like you want to construct a list of directly trusted EE >> certificates, but are trying to satisfy this requirement using the >> application's trust anchor store. There is nothing inherently wrong >> with direct trust (and RFC 5280 does not preclude directly trusting >> an EE certificate), but you really need a different - and far >> simpler - mechanism. The trust anchor store is implicitly linked to >> path discovery and validation, which are not relevant here since a >> directly trusted certificate cannot be validated. With a directly >> trusted certificate, there is also no mechanism to validate status >> information. >> >> To further complicate matters, storing the certificate you wish to >> directly trust in the trust anchor store implies that it is trusted >> to issue certificates as well. The path validation inputs specified >> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >> public key algorithm, public key, and parameters if needed). The >> assumption is that the trust anchor's authority to issue >> certificates was verified based on an out-of-band trust mechanism >> (which is out of scope for 5280). This makes sense since a trust >> anchor might have distributed a v1 certificate (which does not >> include extensions). >> >> As others have noted, direct trust also implies an out-of-band trust >> mechanism. I received the EE certificate from a trusted source so I >> can trust the binding between the subject name and the key; issuer >> name and the signature are irrelevant. If the certificate status >> matters, I am also depending on an out-of-band mechanism to inform >> me! The out-of-band mechanism(s) in combination with protected >> local storage provide the basis for security in this system... >> >> Trying to combine these two mechanisms using a single certificate >> store probably requires an additional flag on every entry to >> differentiate between directly trusted certificates and trust >> anchors. Two separate stores might be cleaner in the long run. >> >> Thanks, >> >> Tim Polk >> >> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >> >>> Folks- >>> >>> I am hoping someone can give me the answer to this. Does RFC 5280 >>> adress the case where an end-entity certificate (not a CA cert) is >>> installed in the trust anchor list by the user accepting the >>> presented cert as authoritative and then the cert is subsequently >>> presented (in a later access to the site). There should be no path >>> search, since the presented cert is in the trust anchor list. So, >>> where is it defined to accept the end-entity cert? >>> >>> Thanks ---- Bob >>> >>> Bob Bell >>> Cisco Systems, Inc. >>> 576 S. Brentwood Ln. >>> Bountiful, UT 84010 >>> 801-294-3034 (v) >>> 801-294-3023 (f) >>> 801-971-4200 (c) >>> rtbell@cisco.com >>> >> > From owner-ietf-pkix@mail.imc.org Tue Jun 10 15:05:33 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03EFE3A6AA7 for ; Tue, 10 Jun 2008 15:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB-LtujXcUO3 for ; Tue, 10 Jun 2008 15:05:32 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6B8173A68A6 for ; Tue, 10 Jun 2008 15:05:30 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5ALaa5V038120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 14:36:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5ALaaSP038119; Tue, 10 Jun 2008 14:36:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5ALaY6Z038104 for ; Tue, 10 Jun 2008 14:36:35 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 3716 invoked from network); 10 Jun 2008 21:26:19 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 21:26:19 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 21:26:19 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Tue, 10 Jun 2008 17:36:33 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLOxZ2JF3RnRVqRGKPdcJq9azznAABsV0g References: From: "Santosh Chokhani" To: "max pritikin" Cc: "Tim Polk" , "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, The text you cite does not apply to trust anchor. Please see X.509 and RFC 5280 path validation text. Nothing needs to be verified from a trust anchor. -----Original Message----- From: max pritikin [mailto:pritikin@cisco.com]=20 Sent: Tuesday, June 10, 2008 4:47 PM To: Santosh Chokhani Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org Subject: Re: RFC 5280 Question Santosh, RFC5280 section 4.2.1.9 (Basic Constraints) says: > The cA boolean indicates whether the certified public key may be =20 > used > to verify certificate signatures. If the cA boolean is not =20 > asserted, > then the keyCertSign bit in the key usage extension MUST NOT be > asserted. If the basic constraints extension is not present in a > version 3 certificate, or the extension is present but the cA =20 > boolean > is not asserted, then the certified public key MUST NOT be used to > verify certificate signatures. An EE certificate being in the trust store would not cause confusion =20 about this. - max On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > Max, > > I do not agree with your point on item 2. Once a certificate is a =20 > trust > anchor, neither X.509 not 5280 have any constraints on it from being a > issuer. > > Furthermore, path length constraint if present in the self-signed > certificate can be ignored by relying parties. > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org=20 > ] > On Behalf Of max pritikin > Sent: Tuesday, June 10, 2008 2:35 PM > To: Tim Polk > Cc: Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > > A few comments on this thread: > > 1) Any entry in the trust anchor store would seem to be "directly > trusted". If so an additional flag isn't needed so much as a statement > about how path validation proceeds if, during path discovery, it turns > out the certificate being validated is already directly trusted. > > 2) Inclusion into the trust anchor store doesn't imply that a cert is > trusted to issue certificates -- that is directly controlled by the > values within the certificate (chain). > > 3) The out-of-band mechanism is out of scope for 5280/3280 but has > been the subject of recent BoF work (and more?). It would nice if that > work also addressed this question. > > Issues related to this come up on a regular basis. Look at the various > ways browser deal with caching EE certificates to "trust this site > always" etc. I think Bob has raised a good point. > > - max > > On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > >> >> Bob, >> >> [I realize I am late to the party, and that Santosh, Steve, and Wen- >> Chen Wang have already provided a lot of good feedback. I decided >> to respond to the original message because I would like to go back >> to the perceived requirement.] >> >> It sounds like you want to construct a list of directly trusted EE >> certificates, but are trying to satisfy this requirement using the >> application's trust anchor store. There is nothing inherently wrong >> with direct trust (and RFC 5280 does not preclude directly trusting >> an EE certificate), but you really need a different - and far >> simpler - mechanism. The trust anchor store is implicitly linked to >> path discovery and validation, which are not relevant here since a >> directly trusted certificate cannot be validated. With a directly >> trusted certificate, there is also no mechanism to validate status >> information. >> >> To further complicate matters, storing the certificate you wish to >> directly trust in the trust anchor store implies that it is trusted >> to issue certificates as well. The path validation inputs specified >> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >> public key algorithm, public key, and parameters if needed). The >> assumption is that the trust anchor's authority to issue >> certificates was verified based on an out-of-band trust mechanism >> (which is out of scope for 5280). This makes sense since a trust >> anchor might have distributed a v1 certificate (which does not >> include extensions). >> >> As others have noted, direct trust also implies an out-of-band trust >> mechanism. I received the EE certificate from a trusted source so I >> can trust the binding between the subject name and the key; issuer >> name and the signature are irrelevant. If the certificate status >> matters, I am also depending on an out-of-band mechanism to inform >> me! The out-of-band mechanism(s) in combination with protected >> local storage provide the basis for security in this system... >> >> Trying to combine these two mechanisms using a single certificate >> store probably requires an additional flag on every entry to >> differentiate between directly trusted certificates and trust >> anchors. Two separate stores might be cleaner in the long run. >> >> Thanks, >> >> Tim Polk >> >> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >> >>> Folks- >>> >>> I am hoping someone can give me the answer to this. Does RFC 5280 >>> adress the case where an end-entity certificate (not a CA cert) is >>> installed in the trust anchor list by the user accepting the >>> presented cert as authoritative and then the cert is subsequently >>> presented (in a later access to the site). There should be no path >>> search, since the presented cert is in the trust anchor list. So, >>> where is it defined to accept the end-entity cert? >>> >>> Thanks ---- Bob >>> >>> Bob Bell >>> Cisco Systems, Inc. >>> 576 S. Brentwood Ln. >>> Bountiful, UT 84010 >>> 801-294-3034 (v) >>> 801-294-3023 (f) >>> 801-971-4200 (c) >>> rtbell@cisco.com >>> >> > From owner-ietf-pkix@mail.imc.org Tue Jun 10 15:44:06 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA423A68A6 for ; Tue, 10 Jun 2008 15:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nf3pqSJYx0g for ; Tue, 10 Jun 2008 15:44:04 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 103163A6839 for ; Tue, 10 Jun 2008 15:44:03 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AMKvOx048011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 15:20:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AMKvpl048010; Tue, 10 Jun 2008 15:20:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5AMKueq048004 for ; Tue, 10 Jun 2008 15:20:56 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 4079 invoked from network); 10 Jun 2008 22:10:41 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 22:10:41 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 22:10:40 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Tue, 10 Jun 2008 18:20:54 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLR6/rbH5JTTHRTEWzJ6bfpPewtwAAC5eA References: From: "Santosh Chokhani" To: "max pritikin" Cc: "Tim Polk" , "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, I do not have any problem with successfully verifying signature made by a trust anchor. As I said a day or two back in this chain, if the relying party who installs the certificate as a trust anchor and does not make additional checks of basic constraints, is susceptible to undetected compromise of this end entity certificate spawning an entire PKI hierarchy. -----Original Message----- From: max pritikin [mailto:pritikin@cisco.com]=20 Sent: Tuesday, June 10, 2008 6:17 PM To: Santosh Chokhani Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org Subject: Re: RFC 5280 Question We're into the realm of discussing _how_ one would modify Certificate =20 Path Validation to support EE certificates as a trust anchor where my =20 intention was only to support the concept as a discussion point. Santosh, it isn't that the constraints/extensions are ever applied to =20 the trust anchor credential itself. It is that they are applied when =20 validating the chain. Take for example Name Constraints or Policy =20 Constraints or other Basic Constraints fields such as =20 pathLenConstraint which are all in the trust anchor certificate and =20 then taken into account when validating a certificate chain. If the =20 trust anchor certificate does not have keyCertSign set then logically =20 no 'chained' certificates would be valid; just like if the =20 pathLenConstraint was '1' but the chain being verified has a path =20 length of something greater. I think this question of EE cert vs CA cert as a trust anchor is about =20 what should happen if the chain being validated consists of only the =20 trust anchor. Independent of any questions concerning key usage, =20 constraints or anything else. - max On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > > Max, > > The text you cite does not apply to trust anchor. Please see X.509 =20 > and > RFC 5280 path validation text. Nothing needs to be verified from a > trust anchor. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 4:47 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > Santosh, > > RFC5280 section 4.2.1.9 (Basic Constraints) says: >> The cA boolean indicates whether the certified public key may be >> used >> to verify certificate signatures. If the cA boolean is not >> asserted, >> then the keyCertSign bit in the key usage extension MUST NOT be >> asserted. If the basic constraints extension is not present in a >> version 3 certificate, or the extension is present but the cA >> boolean >> is not asserted, then the certified public key MUST NOT be used to >> verify certificate signatures. > > An EE certificate being in the trust store would not cause confusion > about this. > > - max > > On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > >> Max, >> >> I do not agree with your point on item 2. Once a certificate is a >> trust >> anchor, neither X.509 not 5280 have any constraints on it from =20 >> being a >> issuer. >> >> Furthermore, path length constraint if present in the self-signed >> certificate can be ignored by relying parties. >> >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org >> ] >> On Behalf Of max pritikin >> Sent: Tuesday, June 10, 2008 2:35 PM >> To: Tim Polk >> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> >> A few comments on this thread: >> >> 1) Any entry in the trust anchor store would seem to be "directly >> trusted". If so an additional flag isn't needed so much as a =20 >> statement >> about how path validation proceeds if, during path discovery, it =20 >> turns >> out the certificate being validated is already directly trusted. >> >> 2) Inclusion into the trust anchor store doesn't imply that a cert =20 >> is >> trusted to issue certificates -- that is directly controlled by the >> values within the certificate (chain). >> >> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >> been the subject of recent BoF work (and more?). It would nice if =20 >> that >> work also addressed this question. >> >> Issues related to this come up on a regular basis. Look at the =20 >> various >> ways browser deal with caching EE certificates to "trust this site >> always" etc. I think Bob has raised a good point. >> >> - max >> >> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >> >>> >>> Bob, >>> >>> [I realize I am late to the party, and that Santosh, Steve, and Wen- >>> Chen Wang have already provided a lot of good feedback. I decided >>> to respond to the original message because I would like to go back >>> to the perceived requirement.] >>> >>> It sounds like you want to construct a list of directly trusted EE >>> certificates, but are trying to satisfy this requirement using the >>> application's trust anchor store. There is nothing inherently wrong >>> with direct trust (and RFC 5280 does not preclude directly trusting >>> an EE certificate), but you really need a different - and far >>> simpler - mechanism. The trust anchor store is implicitly linked to >>> path discovery and validation, which are not relevant here since a >>> directly trusted certificate cannot be validated. With a directly >>> trusted certificate, there is also no mechanism to validate status >>> information. >>> >>> To further complicate matters, storing the certificate you wish to >>> directly trust in the trust anchor store implies that it is trusted >>> to issue certificates as well. The path validation inputs specified >>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>> public key algorithm, public key, and parameters if needed). The >>> assumption is that the trust anchor's authority to issue >>> certificates was verified based on an out-of-band trust mechanism >>> (which is out of scope for 5280). This makes sense since a trust >>> anchor might have distributed a v1 certificate (which does not >>> include extensions). >>> >>> As others have noted, direct trust also implies an out-of-band trust >>> mechanism. I received the EE certificate from a trusted source so I >>> can trust the binding between the subject name and the key; issuer >>> name and the signature are irrelevant. If the certificate status >>> matters, I am also depending on an out-of-band mechanism to inform >>> me! The out-of-band mechanism(s) in combination with protected >>> local storage provide the basis for security in this system... >>> >>> Trying to combine these two mechanisms using a single certificate >>> store probably requires an additional flag on every entry to >>> differentiate between directly trusted certificates and trust >>> anchors. Two separate stores might be cleaner in the long run. >>> >>> Thanks, >>> >>> Tim Polk >>> >>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>> >>>> Folks- >>>> >>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>> adress the case where an end-entity certificate (not a CA cert) is >>>> installed in the trust anchor list by the user accepting the >>>> presented cert as authoritative and then the cert is subsequently >>>> presented (in a later access to the site). There should be no path >>>> search, since the presented cert is in the trust anchor list. So, >>>> where is it defined to accept the end-entity cert? >>>> >>>> Thanks ---- Bob >>>> >>>> Bob Bell >>>> Cisco Systems, Inc. >>>> 576 S. Brentwood Ln. >>>> Bountiful, UT 84010 >>>> 801-294-3034 (v) >>>> 801-294-3023 (f) >>>> 801-971-4200 (c) >>>> rtbell@cisco.com >>>> >>> >> > From owner-ietf-pkix@mail.imc.org Tue Jun 10 16:19:39 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655673A6A20 for ; Tue, 10 Jun 2008 16:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36ytHquDTLWV for ; Tue, 10 Jun 2008 16:19:37 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EF29A3A6849 for ; Tue, 10 Jun 2008 16:19:36 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AMpHnd054089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 15:51:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AMpHZQ054088; Tue, 10 Jun 2008 15:51:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AMpECF054071 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2008 15:51:16 -0700 (MST) (envelope-from pritikin@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,620,1204498800"; d="scan'208";a="11329474" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2008 00:51:11 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5AMpBaX018828; Wed, 11 Jun 2008 00:51:11 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5AMpBar025759; Tue, 10 Jun 2008 22:51:11 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 00:51:11 +0200 Received: from [10.0.1.200] ([10.32.244.67]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 00:51:10 +0200 Cc: "Tim Polk" , "Bob Bell (rtbell)" , Message-Id: From: max pritikin To: "Santosh Chokhani" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 17:51:06 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 22:51:10.0604 (UTC) FILETIME=[7A126CC0:01C8CB4C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8403; t=1213138271; x=1214002271; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20RFC=205280=20Question |Sender:=20; bh=lX4wCJffNy60lXZkjotp5JdgHmRuI2+taD/uf9MnBN0=; b=XiWzSlYJjeitHTfcdzNW4njWBBb1OO/IgDVDYOe+trs6UIwpd0U1zD32Qf GYx4WLzaUkWUe8AOZnznOrdNXd4xPJOoaqA1Afu+6tRXPWwuNu0jj0+qN8C1 ZSrH3bxutb; Authentication-Results: ams-dkim-1; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh, you've moved the conversation back to a discussion of item (3) in my comments below: out-of-scope population of the trust anchors. I think this is orthogonal to a discussion of dealing with trust-anchors that exactly match a single certificate being validated. - max On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > > Max, > > I do not have any problem with successfully verifying signature made > by > a trust anchor. > > As I said a day or two back in this chain, if the relying party who > installs the certificate as a trust anchor and does not make > additional > checks of basic constraints, is susceptible to undetected compromise > of > this end entity certificate spawning an entire PKI hierarchy. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 6:17 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > We're into the realm of discussing _how_ one would modify Certificate > Path Validation to support EE certificates as a trust anchor where my > intention was only to support the concept as a discussion point. > > Santosh, it isn't that the constraints/extensions are ever applied to > the trust anchor credential itself. It is that they are applied when > validating the chain. Take for example Name Constraints or Policy > Constraints or other Basic Constraints fields such as > pathLenConstraint which are all in the trust anchor certificate and > then taken into account when validating a certificate chain. If the > trust anchor certificate does not have keyCertSign set then logically > no 'chained' certificates would be valid; just like if the > pathLenConstraint was '1' but the chain being verified has a path > length of something greater. > > I think this question of EE cert vs CA cert as a trust anchor is about > what should happen if the chain being validated consists of only the > trust anchor. Independent of any questions concerning key usage, > constraints or anything else. > > - max > > On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > >> >> Max, >> >> The text you cite does not apply to trust anchor. Please see X.509 >> and >> RFC 5280 path validation text. Nothing needs to be verified from a >> trust anchor. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 4:47 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> Santosh, >> >> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>> The cA boolean indicates whether the certified public key may be >>> used >>> to verify certificate signatures. If the cA boolean is not >>> asserted, >>> then the keyCertSign bit in the key usage extension MUST NOT be >>> asserted. If the basic constraints extension is not present in a >>> version 3 certificate, or the extension is present but the cA >>> boolean >>> is not asserted, then the certified public key MUST NOT be used to >>> verify certificate signatures. >> >> An EE certificate being in the trust store would not cause confusion >> about this. >> >> - max >> >> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >> >>> Max, >>> >>> I do not agree with your point on item 2. Once a certificate is a >>> trust >>> anchor, neither X.509 not 5280 have any constraints on it from >>> being a >>> issuer. >>> >>> Furthermore, path length constraint if present in the self-signed >>> certificate can be ignored by relying parties. >>> >>> -----Original Message----- >>> From: owner-ietf-pkix@mail.imc.org >> [mailto:owner-ietf-pkix@mail.imc.org >>> ] >>> On Behalf Of max pritikin >>> Sent: Tuesday, June 10, 2008 2:35 PM >>> To: Tim Polk >>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> >>> A few comments on this thread: >>> >>> 1) Any entry in the trust anchor store would seem to be "directly >>> trusted". If so an additional flag isn't needed so much as a >>> statement >>> about how path validation proceeds if, during path discovery, it >>> turns >>> out the certificate being validated is already directly trusted. >>> >>> 2) Inclusion into the trust anchor store doesn't imply that a cert >>> is >>> trusted to issue certificates -- that is directly controlled by the >>> values within the certificate (chain). >>> >>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>> been the subject of recent BoF work (and more?). It would nice if >>> that >>> work also addressed this question. >>> >>> Issues related to this come up on a regular basis. Look at the >>> various >>> ways browser deal with caching EE certificates to "trust this site >>> always" etc. I think Bob has raised a good point. >>> >>> - max >>> >>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>> >>>> >>>> Bob, >>>> >>>> [I realize I am late to the party, and that Santosh, Steve, and >>>> Wen- >>>> Chen Wang have already provided a lot of good feedback. I decided >>>> to respond to the original message because I would like to go back >>>> to the perceived requirement.] >>>> >>>> It sounds like you want to construct a list of directly trusted EE >>>> certificates, but are trying to satisfy this requirement using the >>>> application's trust anchor store. There is nothing inherently >>>> wrong >>>> with direct trust (and RFC 5280 does not preclude directly trusting >>>> an EE certificate), but you really need a different - and far >>>> simpler - mechanism. The trust anchor store is implicitly linked >>>> to >>>> path discovery and validation, which are not relevant here since a >>>> directly trusted certificate cannot be validated. With a directly >>>> trusted certificate, there is also no mechanism to validate status >>>> information. >>>> >>>> To further complicate matters, storing the certificate you wish to >>>> directly trust in the trust anchor store implies that it is trusted >>>> to issue certificates as well. The path validation inputs >>>> specified >>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>> public key algorithm, public key, and parameters if needed). The >>>> assumption is that the trust anchor's authority to issue >>>> certificates was verified based on an out-of-band trust mechanism >>>> (which is out of scope for 5280). This makes sense since a trust >>>> anchor might have distributed a v1 certificate (which does not >>>> include extensions). >>>> >>>> As others have noted, direct trust also implies an out-of-band >>>> trust >>>> mechanism. I received the EE certificate from a trusted source >>>> so I >>>> can trust the binding between the subject name and the key; issuer >>>> name and the signature are irrelevant. If the certificate status >>>> matters, I am also depending on an out-of-band mechanism to inform >>>> me! The out-of-band mechanism(s) in combination with protected >>>> local storage provide the basis for security in this system... >>>> >>>> Trying to combine these two mechanisms using a single certificate >>>> store probably requires an additional flag on every entry to >>>> differentiate between directly trusted certificates and trust >>>> anchors. Two separate stores might be cleaner in the long run. >>>> >>>> Thanks, >>>> >>>> Tim Polk >>>> >>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>> >>>>> Folks- >>>>> >>>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>>> adress the case where an end-entity certificate (not a CA cert) is >>>>> installed in the trust anchor list by the user accepting the >>>>> presented cert as authoritative and then the cert is subsequently >>>>> presented (in a later access to the site). There should be no path >>>>> search, since the presented cert is in the trust anchor list. So, >>>>> where is it defined to accept the end-entity cert? >>>>> >>>>> Thanks ---- Bob >>>>> >>>>> Bob Bell >>>>> Cisco Systems, Inc. >>>>> 576 S. Brentwood Ln. >>>>> Bountiful, UT 84010 >>>>> 801-294-3034 (v) >>>>> 801-294-3023 (f) >>>>> 801-971-4200 (c) >>>>> rtbell@cisco.com >>>>> >>>> >>> >> > From owner-ietf-pkix@mail.imc.org Tue Jun 10 16:38:30 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C9E3A6936 for ; Tue, 10 Jun 2008 16:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu6M9AJogQdj for ; Tue, 10 Jun 2008 16:38:29 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6FAB83A6884 for ; Tue, 10 Jun 2008 16:38:28 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AMGqnN047576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 15:16:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AMGqCl047575; Tue, 10 Jun 2008 15:16:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AMGoVB047569 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2008 15:16:51 -0700 (MST) (envelope-from pritikin@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,619,1204531200"; d="scan'208";a="15454120" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 10 Jun 2008 15:16:50 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5AMGocu002580; Tue, 10 Jun 2008 15:16:50 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5AMGotj004157; Tue, 10 Jun 2008 22:16:50 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 15:16:49 -0700 Received: from [10.0.1.200] ([10.32.244.67]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 15:16:49 -0700 Cc: "Tim Polk" , "Bob Bell (rtbell)" , Message-Id: From: max pritikin To: "Santosh Chokhani" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 17:16:48 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 22:16:49.0604 (UTC) FILETIME=[AD9EC840:01C8CB47] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7195; t=1213136210; x=1214000210; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20RFC=205280=20Question |Sender:=20; bh=86qPG0S7yauOyHhYYCl7LkpXGX7y+QTIx62MTU9NHEo=; b=g24Sff8kCzcd393b6yvo+yXMZrsCuN+egwhJzUD0kOxUhELnAmOgFEGOET PxU5/cpxu9JNKuU7ElGSDT16Foe+IAs1y1cMPzwqsmgRTPffccLVUo3fOcub 3Cz8cBAjyN; Authentication-Results: sj-dkim-3; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We're into the realm of discussing _how_ one would modify Certificate Path Validation to support EE certificates as a trust anchor where my intention was only to support the concept as a discussion point. Santosh, it isn't that the constraints/extensions are ever applied to the trust anchor credential itself. It is that they are applied when validating the chain. Take for example Name Constraints or Policy Constraints or other Basic Constraints fields such as pathLenConstraint which are all in the trust anchor certificate and then taken into account when validating a certificate chain. If the trust anchor certificate does not have keyCertSign set then logically no 'chained' certificates would be valid; just like if the pathLenConstraint was '1' but the chain being verified has a path length of something greater. I think this question of EE cert vs CA cert as a trust anchor is about what should happen if the chain being validated consists of only the trust anchor. Independent of any questions concerning key usage, constraints or anything else. - max On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > > Max, > > The text you cite does not apply to trust anchor. Please see X.509 > and > RFC 5280 path validation text. Nothing needs to be verified from a > trust anchor. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 4:47 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > Santosh, > > RFC5280 section 4.2.1.9 (Basic Constraints) says: >> The cA boolean indicates whether the certified public key may be >> used >> to verify certificate signatures. If the cA boolean is not >> asserted, >> then the keyCertSign bit in the key usage extension MUST NOT be >> asserted. If the basic constraints extension is not present in a >> version 3 certificate, or the extension is present but the cA >> boolean >> is not asserted, then the certified public key MUST NOT be used to >> verify certificate signatures. > > An EE certificate being in the trust store would not cause confusion > about this. > > - max > > On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > >> Max, >> >> I do not agree with your point on item 2. Once a certificate is a >> trust >> anchor, neither X.509 not 5280 have any constraints on it from >> being a >> issuer. >> >> Furthermore, path length constraint if present in the self-signed >> certificate can be ignored by relying parties. >> >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org >> ] >> On Behalf Of max pritikin >> Sent: Tuesday, June 10, 2008 2:35 PM >> To: Tim Polk >> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> >> A few comments on this thread: >> >> 1) Any entry in the trust anchor store would seem to be "directly >> trusted". If so an additional flag isn't needed so much as a >> statement >> about how path validation proceeds if, during path discovery, it >> turns >> out the certificate being validated is already directly trusted. >> >> 2) Inclusion into the trust anchor store doesn't imply that a cert >> is >> trusted to issue certificates -- that is directly controlled by the >> values within the certificate (chain). >> >> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >> been the subject of recent BoF work (and more?). It would nice if >> that >> work also addressed this question. >> >> Issues related to this come up on a regular basis. Look at the >> various >> ways browser deal with caching EE certificates to "trust this site >> always" etc. I think Bob has raised a good point. >> >> - max >> >> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >> >>> >>> Bob, >>> >>> [I realize I am late to the party, and that Santosh, Steve, and Wen- >>> Chen Wang have already provided a lot of good feedback. I decided >>> to respond to the original message because I would like to go back >>> to the perceived requirement.] >>> >>> It sounds like you want to construct a list of directly trusted EE >>> certificates, but are trying to satisfy this requirement using the >>> application's trust anchor store. There is nothing inherently wrong >>> with direct trust (and RFC 5280 does not preclude directly trusting >>> an EE certificate), but you really need a different - and far >>> simpler - mechanism. The trust anchor store is implicitly linked to >>> path discovery and validation, which are not relevant here since a >>> directly trusted certificate cannot be validated. With a directly >>> trusted certificate, there is also no mechanism to validate status >>> information. >>> >>> To further complicate matters, storing the certificate you wish to >>> directly trust in the trust anchor store implies that it is trusted >>> to issue certificates as well. The path validation inputs specified >>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>> public key algorithm, public key, and parameters if needed). The >>> assumption is that the trust anchor's authority to issue >>> certificates was verified based on an out-of-band trust mechanism >>> (which is out of scope for 5280). This makes sense since a trust >>> anchor might have distributed a v1 certificate (which does not >>> include extensions). >>> >>> As others have noted, direct trust also implies an out-of-band trust >>> mechanism. I received the EE certificate from a trusted source so I >>> can trust the binding between the subject name and the key; issuer >>> name and the signature are irrelevant. If the certificate status >>> matters, I am also depending on an out-of-band mechanism to inform >>> me! The out-of-band mechanism(s) in combination with protected >>> local storage provide the basis for security in this system... >>> >>> Trying to combine these two mechanisms using a single certificate >>> store probably requires an additional flag on every entry to >>> differentiate between directly trusted certificates and trust >>> anchors. Two separate stores might be cleaner in the long run. >>> >>> Thanks, >>> >>> Tim Polk >>> >>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>> >>>> Folks- >>>> >>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>> adress the case where an end-entity certificate (not a CA cert) is >>>> installed in the trust anchor list by the user accepting the >>>> presented cert as authoritative and then the cert is subsequently >>>> presented (in a later access to the site). There should be no path >>>> search, since the presented cert is in the trust anchor list. So, >>>> where is it defined to accept the end-entity cert? >>>> >>>> Thanks ---- Bob >>>> >>>> Bob Bell >>>> Cisco Systems, Inc. >>>> 576 S. Brentwood Ln. >>>> Bountiful, UT 84010 >>>> 801-294-3034 (v) >>>> 801-294-3023 (f) >>>> 801-971-4200 (c) >>>> rtbell@cisco.com >>>> >>> >> > From owner-ietf-pkix@mail.imc.org Tue Jun 10 20:08:35 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021D73A67FA for ; Tue, 10 Jun 2008 20:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKhwg-bpOM5j for ; Tue, 10 Jun 2008 20:08:33 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DE4113A677D for ; Tue, 10 Jun 2008 20:08:29 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5B2ZDJh003982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 19:35:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5B2ZDF5003981; Tue, 10 Jun 2008 19:35:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5B2ZBTK003974 for ; Tue, 10 Jun 2008 19:35:12 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 5511 invoked from network); 11 Jun 2008 02:24:55 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;11 Jun 2008 02:24:55 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 11 Jun 2008 02:24:54 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Tue, 10 Jun 2008 22:35:08 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLTH5Hg0qmW0KtSNutOGVbidlYtQAHwfDg References: From: "Santosh Chokhani" To: "max pritikin" Cc: "Tim Polk" , "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, I am just responding to inaccuracies in what you are saying. Can you and Bob tell me why you started this thread and what you are seeking from the PKIX community? I for sure am clueless except for pointing out inaccuracies in your assertions and/or conclusions. -----Original Message----- From: max pritikin [mailto:pritikin@cisco.com]=20 Sent: Tuesday, June 10, 2008 6:51 PM To: Santosh Chokhani Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org Subject: Re: RFC 5280 Question Santosh, you've moved the conversation back to a discussion of item =20 (3) in my comments below: out-of-scope population of the trust =20 anchors. I think this is orthogonal to a discussion of dealing with =20 trust-anchors that exactly match a single certificate being validated. - max On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > > Max, > > I do not have any problem with successfully verifying signature made =20 > by > a trust anchor. > > As I said a day or two back in this chain, if the relying party who > installs the certificate as a trust anchor and does not make =20 > additional > checks of basic constraints, is susceptible to undetected compromise =20 > of > this end entity certificate spawning an entire PKI hierarchy. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 6:17 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > We're into the realm of discussing _how_ one would modify Certificate > Path Validation to support EE certificates as a trust anchor where my > intention was only to support the concept as a discussion point. > > Santosh, it isn't that the constraints/extensions are ever applied to > the trust anchor credential itself. It is that they are applied when > validating the chain. Take for example Name Constraints or Policy > Constraints or other Basic Constraints fields such as > pathLenConstraint which are all in the trust anchor certificate and > then taken into account when validating a certificate chain. If the > trust anchor certificate does not have keyCertSign set then logically > no 'chained' certificates would be valid; just like if the > pathLenConstraint was '1' but the chain being verified has a path > length of something greater. > > I think this question of EE cert vs CA cert as a trust anchor is about > what should happen if the chain being validated consists of only the > trust anchor. Independent of any questions concerning key usage, > constraints or anything else. > > - max > > On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > >> >> Max, >> >> The text you cite does not apply to trust anchor. Please see X.509 >> and >> RFC 5280 path validation text. Nothing needs to be verified from a >> trust anchor. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 4:47 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> Santosh, >> >> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>> The cA boolean indicates whether the certified public key may be >>> used >>> to verify certificate signatures. If the cA boolean is not >>> asserted, >>> then the keyCertSign bit in the key usage extension MUST NOT be >>> asserted. If the basic constraints extension is not present in a >>> version 3 certificate, or the extension is present but the cA >>> boolean >>> is not asserted, then the certified public key MUST NOT be used to >>> verify certificate signatures. >> >> An EE certificate being in the trust store would not cause confusion >> about this. >> >> - max >> >> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >> >>> Max, >>> >>> I do not agree with your point on item 2. Once a certificate is a >>> trust >>> anchor, neither X.509 not 5280 have any constraints on it from >>> being a >>> issuer. >>> >>> Furthermore, path length constraint if present in the self-signed >>> certificate can be ignored by relying parties. >>> >>> -----Original Message----- >>> From: owner-ietf-pkix@mail.imc.org >> [mailto:owner-ietf-pkix@mail.imc.org >>> ] >>> On Behalf Of max pritikin >>> Sent: Tuesday, June 10, 2008 2:35 PM >>> To: Tim Polk >>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> >>> A few comments on this thread: >>> >>> 1) Any entry in the trust anchor store would seem to be "directly >>> trusted". If so an additional flag isn't needed so much as a >>> statement >>> about how path validation proceeds if, during path discovery, it >>> turns >>> out the certificate being validated is already directly trusted. >>> >>> 2) Inclusion into the trust anchor store doesn't imply that a cert >>> is >>> trusted to issue certificates -- that is directly controlled by the >>> values within the certificate (chain). >>> >>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>> been the subject of recent BoF work (and more?). It would nice if >>> that >>> work also addressed this question. >>> >>> Issues related to this come up on a regular basis. Look at the >>> various >>> ways browser deal with caching EE certificates to "trust this site >>> always" etc. I think Bob has raised a good point. >>> >>> - max >>> >>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>> >>>> >>>> Bob, >>>> >>>> [I realize I am late to the party, and that Santosh, Steve, and =20 >>>> Wen- >>>> Chen Wang have already provided a lot of good feedback. I decided >>>> to respond to the original message because I would like to go back >>>> to the perceived requirement.] >>>> >>>> It sounds like you want to construct a list of directly trusted EE >>>> certificates, but are trying to satisfy this requirement using the >>>> application's trust anchor store. There is nothing inherently =20 >>>> wrong >>>> with direct trust (and RFC 5280 does not preclude directly trusting >>>> an EE certificate), but you really need a different - and far >>>> simpler - mechanism. The trust anchor store is implicitly linked =20 >>>> to >>>> path discovery and validation, which are not relevant here since a >>>> directly trusted certificate cannot be validated. With a directly >>>> trusted certificate, there is also no mechanism to validate status >>>> information. >>>> >>>> To further complicate matters, storing the certificate you wish to >>>> directly trust in the trust anchor store implies that it is trusted >>>> to issue certificates as well. The path validation inputs =20 >>>> specified >>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>> public key algorithm, public key, and parameters if needed). The >>>> assumption is that the trust anchor's authority to issue >>>> certificates was verified based on an out-of-band trust mechanism >>>> (which is out of scope for 5280). This makes sense since a trust >>>> anchor might have distributed a v1 certificate (which does not >>>> include extensions). >>>> >>>> As others have noted, direct trust also implies an out-of-band =20 >>>> trust >>>> mechanism. I received the EE certificate from a trusted source =20 >>>> so I >>>> can trust the binding between the subject name and the key; issuer >>>> name and the signature are irrelevant. If the certificate status >>>> matters, I am also depending on an out-of-band mechanism to inform >>>> me! The out-of-band mechanism(s) in combination with protected >>>> local storage provide the basis for security in this system... >>>> >>>> Trying to combine these two mechanisms using a single certificate >>>> store probably requires an additional flag on every entry to >>>> differentiate between directly trusted certificates and trust >>>> anchors. Two separate stores might be cleaner in the long run. >>>> >>>> Thanks, >>>> >>>> Tim Polk >>>> >>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>> >>>>> Folks- >>>>> >>>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>>> adress the case where an end-entity certificate (not a CA cert) is >>>>> installed in the trust anchor list by the user accepting the >>>>> presented cert as authoritative and then the cert is subsequently >>>>> presented (in a later access to the site). There should be no path >>>>> search, since the presented cert is in the trust anchor list. So, >>>>> where is it defined to accept the end-entity cert? >>>>> >>>>> Thanks ---- Bob >>>>> >>>>> Bob Bell >>>>> Cisco Systems, Inc. >>>>> 576 S. Brentwood Ln. >>>>> Bountiful, UT 84010 >>>>> 801-294-3034 (v) >>>>> 801-294-3023 (f) >>>>> 801-971-4200 (c) >>>>> rtbell@cisco.com >>>>> >>>> >>> >> > From owner-ietf-pkix@mail.imc.org Tue Jun 10 20:52:45 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730BF3A6782 for ; Tue, 10 Jun 2008 20:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwuCH2QNyRls for ; Tue, 10 Jun 2008 20:52:43 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A51003A677D for ; Tue, 10 Jun 2008 20:52:42 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5B3Arsa010932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 20:10:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5B3Ar0T010929; Tue, 10 Jun 2008 20:10:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5B3Ao30010907 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2008 20:10:51 -0700 (MST) (envelope-from pritikin@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,621,1204531200"; d="scan'208";a="55614022" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2008 20:10:50 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5B3AoXn014448; Tue, 10 Jun 2008 20:10:50 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5B3AowV027669; Wed, 11 Jun 2008 03:10:50 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 20:10:49 -0700 Received: from [10.0.1.200] ([10.32.244.67]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 20:10:48 -0700 Cc: "Tim Polk" , "Bob Bell (rtbell)" , Message-Id: From: max pritikin To: "Santosh Chokhani" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 22:10:47 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 11 Jun 2008 03:10:49.0327 (UTC) FILETIME=[BFB6E7F0:01C8CB70] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9467; t=1213153850; x=1214017850; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20RFC=205280=20Question |Sender:=20; bh=MVdFEuO30lLWnj1eHUP8KsguoPSEeMjAOhLlRVAQV1w=; b=SEwZHhLyeri++tX9VY5eCPnXSJhJe1ULwTSD8Phf4LsUhRlEsD/7v0ZDxK fGQN9B40VzYcm460WJH8z3Vtkw1r8DvwOmKIb/C5rGOWZmsaPGPZ4OxXHzjM PlfbRFAma7; Authentication-Results: sj-dkim-3; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm not sure what Bob's goals are, perhaps just to ask the question. We don't work very closely together. This just struck a note with me because I've seen it raised as a problem in other cases as well. - max On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > Max, > > I am just responding to inaccuracies in what you are saying. > > Can you and Bob tell me why you started this thread and what you are > seeking from the PKIX community? > > I for sure am clueless except for pointing out inaccuracies in your > assertions and/or conclusions. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 6:51 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > Santosh, you've moved the conversation back to a discussion of item > (3) in my comments below: out-of-scope population of the trust > anchors. I think this is orthogonal to a discussion of dealing with > trust-anchors that exactly match a single certificate being validated. > > - max > > > On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > >> >> Max, >> >> I do not have any problem with successfully verifying signature made >> by >> a trust anchor. >> >> As I said a day or two back in this chain, if the relying party who >> installs the certificate as a trust anchor and does not make >> additional >> checks of basic constraints, is susceptible to undetected compromise >> of >> this end entity certificate spawning an entire PKI hierarchy. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 6:17 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> We're into the realm of discussing _how_ one would modify Certificate >> Path Validation to support EE certificates as a trust anchor where my >> intention was only to support the concept as a discussion point. >> >> Santosh, it isn't that the constraints/extensions are ever applied to >> the trust anchor credential itself. It is that they are applied when >> validating the chain. Take for example Name Constraints or Policy >> Constraints or other Basic Constraints fields such as >> pathLenConstraint which are all in the trust anchor certificate and >> then taken into account when validating a certificate chain. If the >> trust anchor certificate does not have keyCertSign set then logically >> no 'chained' certificates would be valid; just like if the >> pathLenConstraint was '1' but the chain being verified has a path >> length of something greater. >> >> I think this question of EE cert vs CA cert as a trust anchor is >> about >> what should happen if the chain being validated consists of only the >> trust anchor. Independent of any questions concerning key usage, >> constraints or anything else. >> >> - max >> >> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >> >>> >>> Max, >>> >>> The text you cite does not apply to trust anchor. Please see X.509 >>> and >>> RFC 5280 path validation text. Nothing needs to be verified from a >>> trust anchor. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 4:47 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> Santosh, >>> >>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>> The cA boolean indicates whether the certified public key may be >>>> used >>>> to verify certificate signatures. If the cA boolean is not >>>> asserted, >>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>> asserted. If the basic constraints extension is not present in a >>>> version 3 certificate, or the extension is present but the cA >>>> boolean >>>> is not asserted, then the certified public key MUST NOT be used to >>>> verify certificate signatures. >>> >>> An EE certificate being in the trust store would not cause confusion >>> about this. >>> >>> - max >>> >>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I do not agree with your point on item 2. Once a certificate is a >>>> trust >>>> anchor, neither X.509 not 5280 have any constraints on it from >>>> being a >>>> issuer. >>>> >>>> Furthermore, path length constraint if present in the self-signed >>>> certificate can be ignored by relying parties. >>>> >>>> -----Original Message----- >>>> From: owner-ietf-pkix@mail.imc.org >>> [mailto:owner-ietf-pkix@mail.imc.org >>>> ] >>>> On Behalf Of max pritikin >>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>> To: Tim Polk >>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> >>>> A few comments on this thread: >>>> >>>> 1) Any entry in the trust anchor store would seem to be "directly >>>> trusted". If so an additional flag isn't needed so much as a >>>> statement >>>> about how path validation proceeds if, during path discovery, it >>>> turns >>>> out the certificate being validated is already directly trusted. >>>> >>>> 2) Inclusion into the trust anchor store doesn't imply that a cert >>>> is >>>> trusted to issue certificates -- that is directly controlled by the >>>> values within the certificate (chain). >>>> >>>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>>> been the subject of recent BoF work (and more?). It would nice if >>>> that >>>> work also addressed this question. >>>> >>>> Issues related to this come up on a regular basis. Look at the >>>> various >>>> ways browser deal with caching EE certificates to "trust this site >>>> always" etc. I think Bob has raised a good point. >>>> >>>> - max >>>> >>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>> >>>>> >>>>> Bob, >>>>> >>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>> Wen- >>>>> Chen Wang have already provided a lot of good feedback. I decided >>>>> to respond to the original message because I would like to go back >>>>> to the perceived requirement.] >>>>> >>>>> It sounds like you want to construct a list of directly trusted EE >>>>> certificates, but are trying to satisfy this requirement using the >>>>> application's trust anchor store. There is nothing inherently >>>>> wrong >>>>> with direct trust (and RFC 5280 does not preclude directly >>>>> trusting >>>>> an EE certificate), but you really need a different - and far >>>>> simpler - mechanism. The trust anchor store is implicitly linked >>>>> to >>>>> path discovery and validation, which are not relevant here since a >>>>> directly trusted certificate cannot be validated. With a directly >>>>> trusted certificate, there is also no mechanism to validate status >>>>> information. >>>>> >>>>> To further complicate matters, storing the certificate you wish to >>>>> directly trust in the trust anchor store implies that it is >>>>> trusted >>>>> to issue certificates as well. The path validation inputs >>>>> specified >>>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>>> public key algorithm, public key, and parameters if needed). The >>>>> assumption is that the trust anchor's authority to issue >>>>> certificates was verified based on an out-of-band trust mechanism >>>>> (which is out of scope for 5280). This makes sense since a trust >>>>> anchor might have distributed a v1 certificate (which does not >>>>> include extensions). >>>>> >>>>> As others have noted, direct trust also implies an out-of-band >>>>> trust >>>>> mechanism. I received the EE certificate from a trusted source >>>>> so I >>>>> can trust the binding between the subject name and the key; issuer >>>>> name and the signature are irrelevant. If the certificate status >>>>> matters, I am also depending on an out-of-band mechanism to inform >>>>> me! The out-of-band mechanism(s) in combination with protected >>>>> local storage provide the basis for security in this system... >>>>> >>>>> Trying to combine these two mechanisms using a single certificate >>>>> store probably requires an additional flag on every entry to >>>>> differentiate between directly trusted certificates and trust >>>>> anchors. Two separate stores might be cleaner in the long run. >>>>> >>>>> Thanks, >>>>> >>>>> Tim Polk >>>>> >>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>> >>>>>> Folks- >>>>>> >>>>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>>>> adress the case where an end-entity certificate (not a CA cert) >>>>>> is >>>>>> installed in the trust anchor list by the user accepting the >>>>>> presented cert as authoritative and then the cert is subsequently >>>>>> presented (in a later access to the site). There should be no >>>>>> path >>>>>> search, since the presented cert is in the trust anchor list. So, >>>>>> where is it defined to accept the end-entity cert? >>>>>> >>>>>> Thanks ---- Bob >>>>>> >>>>>> Bob Bell >>>>>> Cisco Systems, Inc. >>>>>> 576 S. Brentwood Ln. >>>>>> Bountiful, UT 84010 >>>>>> 801-294-3034 (v) >>>>>> 801-294-3023 (f) >>>>>> 801-971-4200 (c) >>>>>> rtbell@cisco.com >>>>>> >>>>> >>>> >>> >> > From owner-ietf-pkix@mail.imc.org Tue Jun 10 21:12:33 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238F03A6814 for ; Tue, 10 Jun 2008 21:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.796 X-Spam-Level: *** X-Spam-Status: No, score=3.796 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MISSING_SUBJECT=1.762, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id At4MG5eA9Q+m for ; Tue, 10 Jun 2008 21:12:32 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 179073A67D1 for ; Tue, 10 Jun 2008 21:12:31 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5B3VOnK015876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 20:31:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5B3VODl015875; Tue, 10 Jun 2008 20:31:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.nic.cl (mail.nic.cl [200.1.123.8]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5B3VNRr015868 for ; Tue, 10 Jun 2008 20:31:24 -0700 (MST) (envelope-from hsalgado@nic.cl) Received: from mail.nic.cl (mailn [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 214DCCC8367 for ; Tue, 10 Jun 2008 23:31:11 -0400 (CLT) Received: by mail.nic.cl (Postfix, from userid 48) id 16547CC8375; Tue, 10 Jun 2008 23:31:11 -0400 (CLT) Received: from 200.83.213.101 (SquirrelMail authenticated user hsalgado) by webmail.nic.cl with HTTP; Tue, 10 Jun 2008 23:31:11 -0400 (CLT) Message-ID: <39016.200.83.213.101.1213155071.squirrel@webmail.nic.cl> Date: Tue, 10 Jun 2008 23:31:11 -0400 (CLT) Subject: From: hsalgado@nic.cl To: ietf-pkix@vpnc.org User-Agent: SquirrelMail/1.4.8-4.0.1..el5.centos.1 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV using ClamSMTP on Tue Jun 10 23:31:11 2008 -0400 (CLT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: auth 7ae8b5809ece7989f9c15ba872fe6262 subscribe ietf-pkix hsalgado@nic.cl From owner-ietf-pkix@mail.imc.org Wed Jun 11 08:29:10 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F993A69D6 for ; Wed, 11 Jun 2008 08:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQH7g1i-mxN3 for ; Wed, 11 Jun 2008 08:29:09 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EC08E3A6A23 for ; Wed, 11 Jun 2008 08:29:08 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BESvRo070278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 07:28:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5BESv37070276; Wed, 11 Jun 2008 07:28:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5BESo61070238 for ; Wed, 11 Jun 2008 07:28:55 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 11958 invoked from network); 11 Jun 2008 14:18:33 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;11 Jun 2008 14:18:33 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 11 Jun 2008 14:18:32 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Wed, 11 Jun 2008 10:28:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLcMPKSFwZDMdHReWQT29g5vSz9AAXoK3w References: From: "Santosh Chokhani" To: "max pritikin" Cc: "Tim Polk" , "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, I do not understand from your posting what the specific concern or issue you want to bring to the attention of PKIX. We have had lot of digressions on this topic. Please restate what your concerns are. -----Original Message----- From: max pritikin [mailto:pritikin@cisco.com]=20 Sent: Tuesday, June 10, 2008 11:11 PM To: Santosh Chokhani Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org Subject: Re: RFC 5280 Question I'm not sure what Bob's goals are, perhaps just to ask the question. =20 We don't work very closely together. This just struck a note with me because I've seen it raised as a =20 problem in other cases as well. - max On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > Max, > > I am just responding to inaccuracies in what you are saying. > > Can you and Bob tell me why you started this thread and what you are > seeking from the PKIX community? > > I for sure am clueless except for pointing out inaccuracies in your > assertions and/or conclusions. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 6:51 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > Santosh, you've moved the conversation back to a discussion of item > (3) in my comments below: out-of-scope population of the trust > anchors. I think this is orthogonal to a discussion of dealing with > trust-anchors that exactly match a single certificate being validated. > > - max > > > On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > >> >> Max, >> >> I do not have any problem with successfully verifying signature made >> by >> a trust anchor. >> >> As I said a day or two back in this chain, if the relying party who >> installs the certificate as a trust anchor and does not make >> additional >> checks of basic constraints, is susceptible to undetected compromise >> of >> this end entity certificate spawning an entire PKI hierarchy. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 6:17 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> We're into the realm of discussing _how_ one would modify Certificate >> Path Validation to support EE certificates as a trust anchor where my >> intention was only to support the concept as a discussion point. >> >> Santosh, it isn't that the constraints/extensions are ever applied to >> the trust anchor credential itself. It is that they are applied when >> validating the chain. Take for example Name Constraints or Policy >> Constraints or other Basic Constraints fields such as >> pathLenConstraint which are all in the trust anchor certificate and >> then taken into account when validating a certificate chain. If the >> trust anchor certificate does not have keyCertSign set then logically >> no 'chained' certificates would be valid; just like if the >> pathLenConstraint was '1' but the chain being verified has a path >> length of something greater. >> >> I think this question of EE cert vs CA cert as a trust anchor is =20 >> about >> what should happen if the chain being validated consists of only the >> trust anchor. Independent of any questions concerning key usage, >> constraints or anything else. >> >> - max >> >> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >> >>> >>> Max, >>> >>> The text you cite does not apply to trust anchor. Please see X.509 >>> and >>> RFC 5280 path validation text. Nothing needs to be verified from a >>> trust anchor. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 4:47 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> Santosh, >>> >>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>> The cA boolean indicates whether the certified public key may be >>>> used >>>> to verify certificate signatures. If the cA boolean is not >>>> asserted, >>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>> asserted. If the basic constraints extension is not present in a >>>> version 3 certificate, or the extension is present but the cA >>>> boolean >>>> is not asserted, then the certified public key MUST NOT be used to >>>> verify certificate signatures. >>> >>> An EE certificate being in the trust store would not cause confusion >>> about this. >>> >>> - max >>> >>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I do not agree with your point on item 2. Once a certificate is a >>>> trust >>>> anchor, neither X.509 not 5280 have any constraints on it from >>>> being a >>>> issuer. >>>> >>>> Furthermore, path length constraint if present in the self-signed >>>> certificate can be ignored by relying parties. >>>> >>>> -----Original Message----- >>>> From: owner-ietf-pkix@mail.imc.org >>> [mailto:owner-ietf-pkix@mail.imc.org >>>> ] >>>> On Behalf Of max pritikin >>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>> To: Tim Polk >>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> >>>> A few comments on this thread: >>>> >>>> 1) Any entry in the trust anchor store would seem to be "directly >>>> trusted". If so an additional flag isn't needed so much as a >>>> statement >>>> about how path validation proceeds if, during path discovery, it >>>> turns >>>> out the certificate being validated is already directly trusted. >>>> >>>> 2) Inclusion into the trust anchor store doesn't imply that a cert >>>> is >>>> trusted to issue certificates -- that is directly controlled by the >>>> values within the certificate (chain). >>>> >>>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>>> been the subject of recent BoF work (and more?). It would nice if >>>> that >>>> work also addressed this question. >>>> >>>> Issues related to this come up on a regular basis. Look at the >>>> various >>>> ways browser deal with caching EE certificates to "trust this site >>>> always" etc. I think Bob has raised a good point. >>>> >>>> - max >>>> >>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>> >>>>> >>>>> Bob, >>>>> >>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>> Wen- >>>>> Chen Wang have already provided a lot of good feedback. I decided >>>>> to respond to the original message because I would like to go back >>>>> to the perceived requirement.] >>>>> >>>>> It sounds like you want to construct a list of directly trusted EE >>>>> certificates, but are trying to satisfy this requirement using the >>>>> application's trust anchor store. There is nothing inherently >>>>> wrong >>>>> with direct trust (and RFC 5280 does not preclude directly =20 >>>>> trusting >>>>> an EE certificate), but you really need a different - and far >>>>> simpler - mechanism. The trust anchor store is implicitly linked >>>>> to >>>>> path discovery and validation, which are not relevant here since a >>>>> directly trusted certificate cannot be validated. With a directly >>>>> trusted certificate, there is also no mechanism to validate status >>>>> information. >>>>> >>>>> To further complicate matters, storing the certificate you wish to >>>>> directly trust in the trust anchor store implies that it is =20 >>>>> trusted >>>>> to issue certificates as well. The path validation inputs >>>>> specified >>>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>>> public key algorithm, public key, and parameters if needed). The >>>>> assumption is that the trust anchor's authority to issue >>>>> certificates was verified based on an out-of-band trust mechanism >>>>> (which is out of scope for 5280). This makes sense since a trust >>>>> anchor might have distributed a v1 certificate (which does not >>>>> include extensions). >>>>> >>>>> As others have noted, direct trust also implies an out-of-band >>>>> trust >>>>> mechanism. I received the EE certificate from a trusted source >>>>> so I >>>>> can trust the binding between the subject name and the key; issuer >>>>> name and the signature are irrelevant. If the certificate status >>>>> matters, I am also depending on an out-of-band mechanism to inform >>>>> me! The out-of-band mechanism(s) in combination with protected >>>>> local storage provide the basis for security in this system... >>>>> >>>>> Trying to combine these two mechanisms using a single certificate >>>>> store probably requires an additional flag on every entry to >>>>> differentiate between directly trusted certificates and trust >>>>> anchors. Two separate stores might be cleaner in the long run. >>>>> >>>>> Thanks, >>>>> >>>>> Tim Polk >>>>> >>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>> >>>>>> Folks- >>>>>> >>>>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>>>> adress the case where an end-entity certificate (not a CA cert) =20 >>>>>> is >>>>>> installed in the trust anchor list by the user accepting the >>>>>> presented cert as authoritative and then the cert is subsequently >>>>>> presented (in a later access to the site). There should be no =20 >>>>>> path >>>>>> search, since the presented cert is in the trust anchor list. So, >>>>>> where is it defined to accept the end-entity cert? >>>>>> >>>>>> Thanks ---- Bob >>>>>> >>>>>> Bob Bell >>>>>> Cisco Systems, Inc. >>>>>> 576 S. Brentwood Ln. >>>>>> Bountiful, UT 84010 >>>>>> 801-294-3034 (v) >>>>>> 801-294-3023 (f) >>>>>> 801-971-4200 (c) >>>>>> rtbell@cisco.com >>>>>> >>>>> >>>> >>> >> > From owner-ietf-pkix@mail.imc.org Wed Jun 11 09:00:17 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4074E3A68D2 for ; Wed, 11 Jun 2008 09:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVjmAVtjz+XN for ; Wed, 11 Jun 2008 09:00:11 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 704A93A6A67 for ; Wed, 11 Jun 2008 09:00:10 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BF5CLl076575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 08:05:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5BF5BwY076572; Wed, 11 Jun 2008 08:05:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BF56mo076551 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Wed, 11 Jun 2008 08:05:07 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,624,1204531200"; d="p7s'?scan'208";a="111848512" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2008 08:04:55 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5BF4tlm016374; Wed, 11 Jun 2008 08:04:55 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5BF4tXa017667; Wed, 11 Jun 2008 15:04:55 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 08:04:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Wed, 11 Jun 2008 08:04:52 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0029_01C8CBA2.3550B000" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLTH5Hg0qmW0KtSNutOGVbidlYtQAHwfDgABowzeA= References: From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , "Max Pritikin (pritikin)" Cc: "Tim Polk" , X-OriginalArrivalTime: 11 Jun 2008 15:04:55.0626 (UTC) FILETIME=[82194AA0:01C8CBD4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14707; t=1213196695; x=1214060695; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=wb2EfUxkd9ZMcT4b/KhVA1HEgAf99SntO/eXZsVu7S0=; b=uOgTsTNEsBrbQE1/prT5fWJUndTX6ygu7rMc3nh/VYnB1py6fpqHDUuAvG vOEneEYdTbcHffXkbe8QJ6vzx8hYjMIJA1l2lohtp+yzsf9Gm4sYnDqIqPxh Iy8D+VT57S15DJ+OEZy5+quV34jEb9W42UVVLf8eY8URJnWE16Ve8=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C8CBA2.3550B000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - I was requesting clarification on the meaning of some of the concepts in RFC5280. I had no other reasons. What I was trying to establish was if there were issues with the way some of my compatriates had interpreted the rfc. Bob > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani > Sent: Tuesday, 10 June, 2008 20:35 > To: Max Pritikin (pritikin) > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > > Max, > > I am just responding to inaccuracies in what you are saying. > > Can you and Bob tell me why you started this thread and what > you are seeking from the PKIX community? > > I for sure am clueless except for pointing out inaccuracies > in your assertions and/or conclusions. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 6:51 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > Santosh, you've moved the conversation back to a discussion of item > (3) in my comments below: out-of-scope population of the trust > anchors. I think this is orthogonal to a discussion of dealing with > trust-anchors that exactly match a single certificate being validated. > > - max > > > On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > > > > > Max, > > > > I do not have any problem with successfully verifying > signature made > > by > > a trust anchor. > > > > As I said a day or two back in this chain, if the relying party who > > installs the certificate as a trust anchor and does not make > > additional > > checks of basic constraints, is susceptible to undetected > compromise > > of > > this end entity certificate spawning an entire PKI hierarchy. > > > > -----Original Message----- > > From: max pritikin [mailto:pritikin@cisco.com] > > Sent: Tuesday, June 10, 2008 6:17 PM > > To: Santosh Chokhani > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > Subject: Re: RFC 5280 Question > > > > > > We're into the realm of discussing _how_ one would modify > Certificate > > Path Validation to support EE certificates as a trust > anchor where my > > intention was only to support the concept as a discussion point. > > > > Santosh, it isn't that the constraints/extensions are ever > applied to > > the trust anchor credential itself. It is that they are applied when > > validating the chain. Take for example Name Constraints or Policy > > Constraints or other Basic Constraints fields such as > > pathLenConstraint which are all in the trust anchor certificate and > > then taken into account when validating a certificate chain. If the > > trust anchor certificate does not have keyCertSign set then > logically > > no 'chained' certificates would be valid; just like if the > > pathLenConstraint was '1' but the chain being verified has a path > > length of something greater. > > > > I think this question of EE cert vs CA cert as a trust > anchor is about > > what should happen if the chain being validated consists of only the > > trust anchor. Independent of any questions concerning key usage, > > constraints or anything else. > > > > - max > > > > On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > > > >> > >> Max, > >> > >> The text you cite does not apply to trust anchor. Please see X.509 > >> and > >> RFC 5280 path validation text. Nothing needs to be verified from a > >> trust anchor. > >> > >> -----Original Message----- > >> From: max pritikin [mailto:pritikin@cisco.com] > >> Sent: Tuesday, June 10, 2008 4:47 PM > >> To: Santosh Chokhani > >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >> Subject: Re: RFC 5280 Question > >> > >> > >> Santosh, > >> > >> RFC5280 section 4.2.1.9 (Basic Constraints) says: > >>> The cA boolean indicates whether the certified public key may be > >>> used > >>> to verify certificate signatures. If the cA boolean is not > >>> asserted, > >>> then the keyCertSign bit in the key usage extension MUST NOT be > >>> asserted. If the basic constraints extension is not present in a > >>> version 3 certificate, or the extension is present but the cA > >>> boolean > >>> is not asserted, then the certified public key MUST NOT > be used to > >>> verify certificate signatures. > >> > >> An EE certificate being in the trust store would not cause > confusion > >> about this. > >> > >> - max > >> > >> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > >> > >>> Max, > >>> > >>> I do not agree with your point on item 2. Once a certificate is a > >>> trust > >>> anchor, neither X.509 not 5280 have any constraints on it from > >>> being a > >>> issuer. > >>> > >>> Furthermore, path length constraint if present in the self-signed > >>> certificate can be ignored by relying parties. > >>> > >>> -----Original Message----- > >>> From: owner-ietf-pkix@mail.imc.org > >> [mailto:owner-ietf-pkix@mail.imc.org > >>> ] > >>> On Behalf Of max pritikin > >>> Sent: Tuesday, June 10, 2008 2:35 PM > >>> To: Tim Polk > >>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org > >>> Subject: Re: RFC 5280 Question > >>> > >>> > >>> > >>> A few comments on this thread: > >>> > >>> 1) Any entry in the trust anchor store would seem to be "directly > >>> trusted". If so an additional flag isn't needed so much as a > >>> statement > >>> about how path validation proceeds if, during path discovery, it > >>> turns > >>> out the certificate being validated is already directly trusted. > >>> > >>> 2) Inclusion into the trust anchor store doesn't imply > that a cert > >>> is > >>> trusted to issue certificates -- that is directly > controlled by the > >>> values within the certificate (chain). > >>> > >>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has > >>> been the subject of recent BoF work (and more?). It would nice if > >>> that > >>> work also addressed this question. > >>> > >>> Issues related to this come up on a regular basis. Look at the > >>> various > >>> ways browser deal with caching EE certificates to "trust this site > >>> always" etc. I think Bob has raised a good point. > >>> > >>> - max > >>> > >>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > >>> > >>>> > >>>> Bob, > >>>> > >>>> [I realize I am late to the party, and that Santosh, Steve, and > >>>> Wen- > >>>> Chen Wang have already provided a lot of good feedback. > I decided > >>>> to respond to the original message because I would like > to go back > >>>> to the perceived requirement.] > >>>> > >>>> It sounds like you want to construct a list of directly > trusted EE > >>>> certificates, but are trying to satisfy this requirement > using the > >>>> application's trust anchor store. There is nothing inherently > >>>> wrong > >>>> with direct trust (and RFC 5280 does not preclude > directly trusting > >>>> an EE certificate), but you really need a different - and far > >>>> simpler - mechanism. The trust anchor store is > implicitly linked > >>>> to > >>>> path discovery and validation, which are not relevant > here since a > >>>> directly trusted certificate cannot be validated. With > a directly > >>>> trusted certificate, there is also no mechanism to > validate status > >>>> information. > >>>> > >>>> To further complicate matters, storing the certificate > you wish to > >>>> directly trust in the trust anchor store implies that it > is trusted > >>>> to issue certificates as well. The path validation inputs > >>>> specified > >>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, > >>>> public key algorithm, public key, and parameters if needed). The > >>>> assumption is that the trust anchor's authority to issue > >>>> certificates was verified based on an out-of-band trust mechanism > >>>> (which is out of scope for 5280). This makes sense since a trust > >>>> anchor might have distributed a v1 certificate (which does not > >>>> include extensions). > >>>> > >>>> As others have noted, direct trust also implies an out-of-band > >>>> trust > >>>> mechanism. I received the EE certificate from a trusted source > >>>> so I > >>>> can trust the binding between the subject name and the > key; issuer > >>>> name and the signature are irrelevant. If the > certificate status > >>>> matters, I am also depending on an out-of-band mechanism > to inform > >>>> me! The out-of-band mechanism(s) in combination with protected > >>>> local storage provide the basis for security in this system... > >>>> > >>>> Trying to combine these two mechanisms using a single certificate > >>>> store probably requires an additional flag on every entry to > >>>> differentiate between directly trusted certificates and trust > >>>> anchors. Two separate stores might be cleaner in the long run. > >>>> > >>>> Thanks, > >>>> > >>>> Tim Polk > >>>> > >>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > >>>> > >>>>> Folks- > >>>>> > >>>>> I am hoping someone can give me the answer to this. > Does RFC 5280 > >>>>> adress the case where an end-entity certificate (not a > CA cert) is > >>>>> installed in the trust anchor list by the user accepting the > >>>>> presented cert as authoritative and then the cert is > subsequently > >>>>> presented (in a later access to the site). There should > be no path > >>>>> search, since the presented cert is in the trust anchor > list. So, > >>>>> where is it defined to accept the end-entity cert? > >>>>> > >>>>> Thanks ---- Bob > >>>>> > >>>>> Bob Bell > >>>>> Cisco Systems, Inc. > >>>>> 576 S. Brentwood Ln. > >>>>> Bountiful, UT 84010 > >>>>> 801-294-3034 (v) > >>>>> 801-294-3023 (f) > >>>>> 801-971-4200 (c) > >>>>> rtbell@cisco.com > >>>>> > >>>> > >>> > >> > > > > ------=_NextPart_000_0029_01C8CBA2.3550B000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTExNTA0NTFaMCMGCSqGSIb3DQEJBDEWBBTyiLTLmxsq2JGWIOMq dmlbOlz/VDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYCN3Zc89eFzl6M7EGRadbYQRkkalzcCxaasadIJaM7cqOTDMCrnlaWNACfr328VUYX5rGEn ntlI3kToEKRXGIZXRvhHNwehiRhBYyuBofDiBz2W8TGaV6ZaidEM31shvajAoehmzxDAlL6XONUQ oeiZKlTCmLq+b3R+g+Vwyk1VAwAAAAAAAA== ------=_NextPart_000_0029_01C8CBA2.3550B000-- From owner-ietf-pkix@mail.imc.org Wed Jun 11 17:22:47 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2BC43A67A6 for ; Wed, 11 Jun 2008 17:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.9 X-Spam-Level: X-Spam-Status: No, score=-16.9 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPnzszKFpsTf for ; Wed, 11 Jun 2008 17:22:45 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2F3053A67A4 for ; Wed, 11 Jun 2008 17:22:44 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhQGB086143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 16:43:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5BNhQX0086142; Wed, 11 Jun 2008 16:43:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhO7t086130 for ; Wed, 11 Jun 2008 16:43:25 -0700 (MST) (envelope-from rfc-editor@rfc-editor.org) Received: by bosco.isi.edu (Postfix, from userid 70) id 55936136501; Wed, 11 Jun 2008 16:43:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5272 on Certificate Management over CMS (CMC) From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org Message-Id: <20080611234324.55936136501@bosco.isi.edu> Date: Wed, 11 Jun 2008 16:43:24 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A new Request for Comments is now available in online RFC libraries. RFC 5272 Title: Certificate Management over CMS (CMC) Author: J. Schaad, M. Myers Status: Standards Track Date: June 2008 Mailbox: jimsch@nwlink.com, mmyers@fastq.com Pages: 83 Characters: 167138 Obsoletes: RFC2797 I-D Tag: draft-ietf-pkix-2797-bis-07.txt URL: http://www.rfc-editor.org/rfc/rfc5272.txt This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and 2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design. CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS TRACK] This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From owner-ietf-pkix@mail.imc.org Wed Jun 11 18:04:44 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94BF3A68AF for ; Wed, 11 Jun 2008 18:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.905 X-Spam-Level: X-Spam-Status: No, score=-16.905 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5emTbetTK1U for ; Wed, 11 Jun 2008 18:04:39 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0E6A63A67CF for ; Wed, 11 Jun 2008 18:04:38 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhQso086146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 16:43:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5BNhQ7W086145; Wed, 11 Jun 2008 16:43:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhP6o086136 for ; Wed, 11 Jun 2008 16:43:25 -0700 (MST) (envelope-from rfc-editor@rfc-editor.org) Received: by bosco.isi.edu (Postfix, from userid 70) id 8059B136503; Wed, 11 Jun 2008 16:43:25 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5273 on Certificate Management over CMS (CMC): Transport Protocols From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org Message-Id: <20080611234325.8059B136503@bosco.isi.edu> Date: Wed, 11 Jun 2008 16:43:25 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A new Request for Comments is now available in online RFC libraries. RFC 5273 Title: Certificate Management over CMS (CMC): Transport Protocols Author: J. Schaad, M. Myers Status: Standards Track Date: June 2008 Mailbox: jimsch@nwlink.com, mmyers@fastq.com Pages: 7 Characters: 14030 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-cmc-trans-08.txt URL: http://www.rfc-editor.org/rfc/rfc5273.txt This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. [STANDARDS TRACK] This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From owner-ietf-pkix@mail.imc.org Wed Jun 11 18:07:26 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881E83A68FC for ; Wed, 11 Jun 2008 18:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.907 X-Spam-Level: X-Spam-Status: No, score=-16.907 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrzM4DKzaMjL for ; Wed, 11 Jun 2008 18:07:25 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5CB7D3A68ED for ; Wed, 11 Jun 2008 18:07:25 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhUEs086166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 16:43:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5BNhUMu086165; Wed, 11 Jun 2008 16:43:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhTWx086159 for ; Wed, 11 Jun 2008 16:43:29 -0700 (MST) (envelope-from rfc-editor@rfc-editor.org) Received: by bosco.isi.edu (Postfix, from userid 70) id 8C086136506; Wed, 11 Jun 2008 16:43:29 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5274 on Certificate Managmement Messages over CMS (CMC): Complience Requirements From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org Message-Id: <20080611234329.8C086136506@bosco.isi.edu> Date: Wed, 11 Jun 2008 16:43:29 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A new Request for Comments is now available in online RFC libraries. RFC 5274 Title: Certificate Managmement Messages over CMS (CMC): Complience Requirements Author: J. Schaad, M. Myers Status: Standards Track Date: June 2008 Mailbox: jimsch@nwlink.com, mmyers@fastq.com Pages: 13 Characters: 27380 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-cmc-compl-05.txt URL: http://www.rfc-editor.org/rfc/rfc5274.txt This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. [STANDARDS TRACK] This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From owner-ietf-pkix@mail.imc.org Wed Jun 11 23:04:17 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91FE93A684F for ; Wed, 11 Jun 2008 23:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aya4JLhkafIC for ; Wed, 11 Jun 2008 23:04:16 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 31C153A6836 for ; Wed, 11 Jun 2008 23:04:15 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5C5HgHP056522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 22:17:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5C5HgYK056521; Wed, 11 Jun 2008 22:17:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5C5HdSX056502 for ; Wed, 11 Jun 2008 22:17:40 -0700 (MST) (envelope-from ynir@checkpoint.com) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8D8E4294002; Thu, 12 Jun 2008 08:17:38 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B4D17294001 for ; Thu, 12 Jun 2008 08:17:37 +0300 (IDT) Received: from [172.31.24.139] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m5C5HajI006487 for ; Thu, 12 Jun 2008 08:17:36 +0300 (IDT) Message-Id: From: Yoav Nir To: ietf-pkix@imc.org In-Reply-To: <20080611234329.8C086136506@bosco.isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5274 on Certificate Managmement Messages over CMS (CMC): Complience Requirements Date: Thu, 12 Jun 2008 08:17:14 +0300 References: <20080611234329.8C086136506@bosco.isi.edu> X-Mailer: Apple Mail (2.924) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, at least the real RFC doesn't have the spelling mistakes. s/Managmement/Management/ s/Complience/Compliance/ On Jun 12, 2008, at 2:43 AM, rfc-editor@rfc-editor.org wrote: > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5274 > > Title: Certificate Managmement Messages over CMS > (CMC): Complience Requirements > Author: J. Schaad, M. Myers > Status: Standards Track > Date: June 2008 > Mailbox: jimsch@nwlink.com, mmyers@fastq.com > Pages: 13 > Characters: 27380 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-pkix-cmc-compl-05.txt > > URL: http://www.rfc-editor.org/rfc/rfc5274.txt > > This document provides a set of compliance statements about the CMC > (Certificate Management over CMS) enrollment protocol. The ASN.1 > structures and the transport mechanisms for the CMC enrollment > protocol are covered in other documents. This document provides the > information needed to make a compliant version of CMC. [STANDARDS > TRACK] > > This document is a product of the Public-Key Infrastructure (X.509) > Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html > . > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. > Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > > > Scanned by Check Point Total Security Gateway. > From owner-ietf-pkix@mail.imc.org Thu Jun 12 11:44:02 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D863A68B7 for ; Thu, 12 Jun 2008 11:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNLVW6+FdWq5 for ; Thu, 12 Jun 2008 11:43:58 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D58113A6782 for ; Thu, 12 Jun 2008 11:43:56 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CI1oI8030314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 11:01:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5CI1od0030312; Thu, 12 Jun 2008 11:01:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CI1mBw030284 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Thu, 12 Jun 2008 11:01:49 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,632,1204531200"; d="p7s'?scan'208";a="40894283" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 12 Jun 2008 11:01:47 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5CI1lbA021179; Thu, 12 Jun 2008 11:01:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5CI1llO028246; Thu, 12 Jun 2008 18:01:47 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 11:01:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Thu, 12 Jun 2008 11:01:44 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D8_01C8CC84.14EFAC20" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjMtWQlJr5jW+zJSKKZO5AdcKzRYAAAK5jA References: From: "Bob Bell (rtbell)" To: "Timothy J Miller" , "Santosh Chokhani" Cc: "Max Pritikin (pritikin)" , "Tim Polk" , X-OriginalArrivalTime: 12 Jun 2008 18:01:47.0551 (UTC) FILETIME=[61B64AF0:01C8CCB6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15454; t=1213293707; x=1214157707; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=knZ5EDrJoSiVuNftbkRfdcVz1P1IgAm0Owmuo19jIzM=; b=j7uWmGhwYNiv/Qy5sKqmGjUN9FuVAOBfZnUgGThiQLNLBku6XyiH8QBw1v L19IYAK5fUcuoOVwrkDlwfl/G2itXs/2eeG8FDwlhnYWYEsc5UMXcsRv9rgt AgtVgIsHHw; Authentication-Results: sj-dkim-2; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00D8_01C8CC84.14EFAC20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Timothy - However, these were implementation issues and not theory issues. It also avoided several vulnerabilities wherein the device is presented with a cert that is signed by a "trusted" CA, but that the cert was infact invalid. Case in point was the issuance to an outside of the Microsoft signing certificate. Bob > -----Original Message----- > From: Timothy J Miller [mailto:tmiller@mitre.org] > Sent: Thursday, 12 June, 2008 11:53 > To: Santosh Chokhani > Cc: Max Pritikin (pritikin); Tim Polk; Bob Bell (rtbell); > ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > Cisco's CallManager does interesting things re: certificates > provisioning and trust lists (google Certificate Authority Proxy > Function [CAPF] and Certificate Trust List Provider [CTL > Provider]). > Coincidentally, both these services had fairly significant > vulnerabilities recently. > > Shall I speculate that the question arises from this? :) > > -- Tim > > > On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > > > > Max, > > > > I am just responding to inaccuracies in what you are saying. > > > > Can you and Bob tell me why you started this thread and > what you are > > seeking from the PKIX community? > > > > I for sure am clueless except for pointing out inaccuracies in your > > assertions and/or conclusions. > > > > -----Original Message----- > > From: max pritikin [mailto:pritikin@cisco.com] > > Sent: Tuesday, June 10, 2008 6:51 PM > > To: Santosh Chokhani > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > Subject: Re: RFC 5280 Question > > > > > > Santosh, you've moved the conversation back to a discussion of item > > (3) in my comments below: out-of-scope population of the trust > > anchors. I think this is orthogonal to a discussion of dealing with > > trust-anchors that exactly match a single certificate being > validated. > > > > - max > > > > > > On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > > > >> > >> Max, > >> > >> I do not have any problem with successfully verifying > signature made > >> by a trust anchor. > >> > >> As I said a day or two back in this chain, if the relying > party who > >> installs the certificate as a trust anchor and does not make > >> additional checks of basic constraints, is susceptible to > undetected > >> compromise of this end entity certificate spawning an entire PKI > >> hierarchy. > >> > >> -----Original Message----- > >> From: max pritikin [mailto:pritikin@cisco.com] > >> Sent: Tuesday, June 10, 2008 6:17 PM > >> To: Santosh Chokhani > >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >> Subject: Re: RFC 5280 Question > >> > >> > >> We're into the realm of discussing _how_ one would modify > Certificate > >> Path Validation to support EE certificates as a trust > anchor where my > >> intention was only to support the concept as a discussion point. > >> > >> Santosh, it isn't that the constraints/extensions are ever > applied to > >> the trust anchor credential itself. It is that they are > applied when > >> validating the chain. Take for example Name Constraints or Policy > >> Constraints or other Basic Constraints fields such as > >> pathLenConstraint which are all in the trust anchor > certificate and > >> then taken into account when validating a certificate > chain. If the > >> trust anchor certificate does not have keyCertSign set > then logically > >> no 'chained' certificates would be valid; just like if the > >> pathLenConstraint was '1' but the chain being verified has a path > >> length of something greater. > >> > >> I think this question of EE cert vs CA cert as a trust anchor is > >> about what should happen if the chain being validated consists of > >> only the trust anchor. Independent of any questions concerning key > >> usage, constraints or anything else. > >> > >> - max > >> > >> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > >> > >>> > >>> Max, > >>> > >>> The text you cite does not apply to trust anchor. Please > see X.509 > >>> and RFC 5280 path validation text. Nothing needs to be verified > >>> from a trust anchor. > >>> > >>> -----Original Message----- > >>> From: max pritikin [mailto:pritikin@cisco.com] > >>> Sent: Tuesday, June 10, 2008 4:47 PM > >>> To: Santosh Chokhani > >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >>> Subject: Re: RFC 5280 Question > >>> > >>> > >>> Santosh, > >>> > >>> RFC5280 section 4.2.1.9 (Basic Constraints) says: > >>>> The cA boolean indicates whether the certified public key may be > >>>> used to verify certificate signatures. If the cA boolean is not > >>>> asserted, then the keyCertSign bit in the key usage > extension MUST > >>>> NOT be asserted. If the basic constraints extension is > not present > >>>> in a version 3 certificate, or the extension is present > but the cA > >>>> boolean is not asserted, then the certified public key > MUST NOT be > >>>> used to verify certificate signatures. > >>> > >>> An EE certificate being in the trust store would not > cause confusion > >>> about this. > >>> > >>> - max > >>> > >>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > >>> > >>>> Max, > >>>> > >>>> I do not agree with your point on item 2. Once a > certificate is a > >>>> trust anchor, neither X.509 not 5280 have any constraints on it > >>>> from being a issuer. > >>>> > >>>> Furthermore, path length constraint if present in the > self-signed > >>>> certificate can be ignored by relying parties. > >>>> > >>>> -----Original Message----- > >>>> From: owner-ietf-pkix@mail.imc.org > >>> [mailto:owner-ietf-pkix@mail.imc.org > >>>> ] > >>>> On Behalf Of max pritikin > >>>> Sent: Tuesday, June 10, 2008 2:35 PM > >>>> To: Tim Polk > >>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org > >>>> Subject: Re: RFC 5280 Question > >>>> > >>>> > >>>> > >>>> A few comments on this thread: > >>>> > >>>> 1) Any entry in the trust anchor store would seem to be > "directly > >>>> trusted". If so an additional flag isn't needed so much as a > >>>> statement about how path validation proceeds if, during path > >>>> discovery, it turns out the certificate being validated > is already > >>>> directly trusted. > >>>> > >>>> 2) Inclusion into the trust anchor store doesn't imply > that a cert > >>>> is trusted to issue certificates -- that is directly > controlled by > >>>> the values within the certificate (chain). > >>>> > >>>> 3) The out-of-band mechanism is out of scope for > 5280/3280 but has > >>>> been the subject of recent BoF work (and more?). It > would nice if > >>>> that work also addressed this question. > >>>> > >>>> Issues related to this come up on a regular basis. Look at the > >>>> various ways browser deal with caching EE certificates to "trust > >>>> this site always" etc. I think Bob has raised a good point. > >>>> > >>>> - max > >>>> > >>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > >>>> > >>>>> > >>>>> Bob, > >>>>> > >>>>> [I realize I am late to the party, and that Santosh, Steve, and > >>>>> Wen- > >>>>> Chen Wang have already provided a lot of good feedback. > I decided > >>>>> to respond to the original message because I would like > to go back > >>>>> to the perceived requirement.] > >>>>> > >>>>> It sounds like you want to construct a list of directly > trusted EE > >>>>> certificates, but are trying to satisfy this > requirement using the > >>>>> application's trust anchor store. There is nothing inherently > >>>>> wrong with direct trust (and RFC 5280 does not preclude > directly > >>>>> trusting an EE certificate), but you really need a > different - and > >>>>> far simpler - mechanism. The trust anchor store is implicitly > >>>>> linked to path discovery and validation, which are not relevant > >>>>> here since a directly trusted certificate cannot be validated. > >>>>> With a directly trusted certificate, there is also no > mechanism to > >>>>> validate status information. > >>>>> > >>>>> To further complicate matters, storing the certificate > you wish to > >>>>> directly trust in the trust anchor store implies that it is > >>>>> trusted to issue certificates as well. The path > validation inputs > >>>>> specified in 6.1.1 (d) consider only four aspects of a trust > >>>>> anchor (name, public key algorithm, public key, and > parameters if > >>>>> needed). The assumption is that the trust anchor's > authority to > >>>>> issue certificates was verified based on an out-of-band trust > >>>>> mechanism (which is out of scope for 5280). This makes sense > >>>>> since a trust anchor might have distributed a v1 certificate > >>>>> (which does not include extensions). > >>>>> > >>>>> As others have noted, direct trust also implies an out-of-band > >>>>> trust mechanism. I received the EE certificate from a trusted > >>>>> source so I can trust the binding between the subject > name and the > >>>>> key; issuer > >>>>> name and the signature are irrelevant. If the > certificate status > >>>>> matters, I am also depending on an out-of-band > mechanism to inform > >>>>> me! The out-of-band mechanism(s) in combination with protected > >>>>> local storage provide the basis for security in this system... > >>>>> > >>>>> Trying to combine these two mechanisms using a single > certificate > >>>>> store probably requires an additional flag on every entry to > >>>>> differentiate between directly trusted certificates and trust > >>>>> anchors. Two separate stores might be cleaner in the long run. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Tim Polk > >>>>> > >>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > >>>>> > >>>>>> Folks- > >>>>>> > >>>>>> I am hoping someone can give me the answer to this. > Does RFC 5280 > >>>>>> adress the case where an end-entity certificate (not a > CA cert) > >>>>>> is installed in the trust anchor list by the user > accepting the > >>>>>> presented cert as authoritative and then the cert is > subsequently > >>>>>> presented (in a later access to the site). There should be no > >>>>>> path search, since the presented cert is in the trust anchor > >>>>>> list. So, where is it defined to accept the end-entity cert? > >>>>>> > >>>>>> Thanks ---- Bob > >>>>>> > >>>>>> Bob Bell > >>>>>> Cisco Systems, Inc. > >>>>>> 576 S. Brentwood Ln. > >>>>>> Bountiful, UT 84010 > >>>>>> 801-294-3034 (v) > >>>>>> 801-294-3023 (f) > >>>>>> 801-971-4200 (c) > >>>>>> rtbell@cisco.com > >>>>>> > >>>>> > >>>> > >>> > >> > > > > ------=_NextPart_000_00D8_01C8CC84.14EFAC20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTIxODAxNDNaMCMGCSqGSIb3DQEJBDEWBBSkAin1WJ/X9b1V8g9e BtUy2F0/xTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYBZkTiGciinF2ea4d+Z0FHJ5AwmdIfwbMd9fDqAzeEhIZRuQCq13bTansSAIJc/vxsxB5SG GjqOJiectGLY6XO7iy385rM+bTAr/sXV/CSd5aMvUY2ivtXS5bCCSmJQS1XS/FBG54bumWKTtYka feRkvG3TQ8YXV1OeAD5I3+FG9QAAAAAAAA== ------=_NextPart_000_00D8_01C8CC84.14EFAC20-- From owner-ietf-pkix@mail.imc.org Thu Jun 12 11:44:41 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF97B3A69EC for ; Thu, 12 Jun 2008 11:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhXaq23WxjzP for ; Thu, 12 Jun 2008 11:44:40 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5FB133A69AC for ; Thu, 12 Jun 2008 11:44:39 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CHsFN6026289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 10:54:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5CHsEaW026286; Thu, 12 Jun 2008 10:54:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CHsCLk026242 for ; Thu, 12 Jun 2008 10:54:13 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m5CHsBrY026390 for ; Thu, 12 Jun 2008 13:54:11 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m5CHsBfq026381; Thu, 12 Jun 2008 13:54:11 -0400 Received: from mb711fa48.tmodns.net ([172.31.18.118]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 13:54:03 -0400 Cc: "max pritikin" , "Tim Polk" , "Bob Bell (rtbell)" , Message-Id: From: Timothy J Miller To: Santosh Chokhani In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-6-910284558; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Thu, 12 Jun 2008 12:53:18 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 12 Jun 2008 17:54:05.0748 (UTC) FILETIME=[4E74BF40:01C8CCB5] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-6-910284558 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cisco's CallManager does interesting things re: certificates provisioning and trust lists (google Certificate Authority Proxy Function [CAPF] and Certificate Trust List Provider [CTL Provider]). Coincidentally, both these services had fairly significant vulnerabilities recently. Shall I speculate that the question arises from this? :) -- Tim On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > Max, > > I am just responding to inaccuracies in what you are saying. > > Can you and Bob tell me why you started this thread and what you are > seeking from the PKIX community? > > I for sure am clueless except for pointing out inaccuracies in your > assertions and/or conclusions. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 6:51 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > Santosh, you've moved the conversation back to a discussion of item > (3) in my comments below: out-of-scope population of the trust > anchors. I think this is orthogonal to a discussion of dealing with > trust-anchors that exactly match a single certificate being validated. > > - max > > > On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > >> >> Max, >> >> I do not have any problem with successfully verifying signature made >> by >> a trust anchor. >> >> As I said a day or two back in this chain, if the relying party who >> installs the certificate as a trust anchor and does not make >> additional >> checks of basic constraints, is susceptible to undetected compromise >> of >> this end entity certificate spawning an entire PKI hierarchy. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 6:17 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> We're into the realm of discussing _how_ one would modify Certificate >> Path Validation to support EE certificates as a trust anchor where my >> intention was only to support the concept as a discussion point. >> >> Santosh, it isn't that the constraints/extensions are ever applied to >> the trust anchor credential itself. It is that they are applied when >> validating the chain. Take for example Name Constraints or Policy >> Constraints or other Basic Constraints fields such as >> pathLenConstraint which are all in the trust anchor certificate and >> then taken into account when validating a certificate chain. If the >> trust anchor certificate does not have keyCertSign set then logically >> no 'chained' certificates would be valid; just like if the >> pathLenConstraint was '1' but the chain being verified has a path >> length of something greater. >> >> I think this question of EE cert vs CA cert as a trust anchor is >> about >> what should happen if the chain being validated consists of only the >> trust anchor. Independent of any questions concerning key usage, >> constraints or anything else. >> >> - max >> >> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >> >>> >>> Max, >>> >>> The text you cite does not apply to trust anchor. Please see X.509 >>> and >>> RFC 5280 path validation text. Nothing needs to be verified from a >>> trust anchor. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 4:47 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> Santosh, >>> >>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>> The cA boolean indicates whether the certified public key may be >>>> used >>>> to verify certificate signatures. If the cA boolean is not >>>> asserted, >>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>> asserted. If the basic constraints extension is not present in a >>>> version 3 certificate, or the extension is present but the cA >>>> boolean >>>> is not asserted, then the certified public key MUST NOT be used to >>>> verify certificate signatures. >>> >>> An EE certificate being in the trust store would not cause confusion >>> about this. >>> >>> - max >>> >>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I do not agree with your point on item 2. Once a certificate is a >>>> trust >>>> anchor, neither X.509 not 5280 have any constraints on it from >>>> being a >>>> issuer. >>>> >>>> Furthermore, path length constraint if present in the self-signed >>>> certificate can be ignored by relying parties. >>>> >>>> -----Original Message----- >>>> From: owner-ietf-pkix@mail.imc.org >>> [mailto:owner-ietf-pkix@mail.imc.org >>>> ] >>>> On Behalf Of max pritikin >>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>> To: Tim Polk >>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> >>>> A few comments on this thread: >>>> >>>> 1) Any entry in the trust anchor store would seem to be "directly >>>> trusted". If so an additional flag isn't needed so much as a >>>> statement >>>> about how path validation proceeds if, during path discovery, it >>>> turns >>>> out the certificate being validated is already directly trusted. >>>> >>>> 2) Inclusion into the trust anchor store doesn't imply that a cert >>>> is >>>> trusted to issue certificates -- that is directly controlled by the >>>> values within the certificate (chain). >>>> >>>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>>> been the subject of recent BoF work (and more?). It would nice if >>>> that >>>> work also addressed this question. >>>> >>>> Issues related to this come up on a regular basis. Look at the >>>> various >>>> ways browser deal with caching EE certificates to "trust this site >>>> always" etc. I think Bob has raised a good point. >>>> >>>> - max >>>> >>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>> >>>>> >>>>> Bob, >>>>> >>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>> Wen- >>>>> Chen Wang have already provided a lot of good feedback. I decided >>>>> to respond to the original message because I would like to go back >>>>> to the perceived requirement.] >>>>> >>>>> It sounds like you want to construct a list of directly trusted EE >>>>> certificates, but are trying to satisfy this requirement using the >>>>> application's trust anchor store. There is nothing inherently >>>>> wrong >>>>> with direct trust (and RFC 5280 does not preclude directly >>>>> trusting >>>>> an EE certificate), but you really need a different - and far >>>>> simpler - mechanism. The trust anchor store is implicitly linked >>>>> to >>>>> path discovery and validation, which are not relevant here since a >>>>> directly trusted certificate cannot be validated. With a directly >>>>> trusted certificate, there is also no mechanism to validate status >>>>> information. >>>>> >>>>> To further complicate matters, storing the certificate you wish to >>>>> directly trust in the trust anchor store implies that it is >>>>> trusted >>>>> to issue certificates as well. The path validation inputs >>>>> specified >>>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>>> public key algorithm, public key, and parameters if needed). The >>>>> assumption is that the trust anchor's authority to issue >>>>> certificates was verified based on an out-of-band trust mechanism >>>>> (which is out of scope for 5280). This makes sense since a trust >>>>> anchor might have distributed a v1 certificate (which does not >>>>> include extensions). >>>>> >>>>> As others have noted, direct trust also implies an out-of-band >>>>> trust >>>>> mechanism. I received the EE certificate from a trusted source >>>>> so I >>>>> can trust the binding between the subject name and the key; issuer >>>>> name and the signature are irrelevant. If the certificate status >>>>> matters, I am also depending on an out-of-band mechanism to inform >>>>> me! The out-of-band mechanism(s) in combination with protected >>>>> local storage provide the basis for security in this system... >>>>> >>>>> Trying to combine these two mechanisms using a single certificate >>>>> store probably requires an additional flag on every entry to >>>>> differentiate between directly trusted certificates and trust >>>>> anchors. Two separate stores might be cleaner in the long run. >>>>> >>>>> Thanks, >>>>> >>>>> Tim Polk >>>>> >>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>> >>>>>> Folks- >>>>>> >>>>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>>>> adress the case where an end-entity certificate (not a CA cert) >>>>>> is >>>>>> installed in the trust anchor list by the user accepting the >>>>>> presented cert as authoritative and then the cert is subsequently >>>>>> presented (in a later access to the site). There should be no >>>>>> path >>>>>> search, since the presented cert is in the trust anchor list. So, >>>>>> where is it defined to accept the end-entity cert? >>>>>> >>>>>> Thanks ---- Bob >>>>>> >>>>>> Bob Bell >>>>>> Cisco Systems, Inc. >>>>>> 576 S. Brentwood Ln. >>>>>> Bountiful, UT 84010 >>>>>> 801-294-3034 (v) >>>>>> 801-294-3023 (f) >>>>>> 801-971-4200 (c) >>>>>> rtbell@cisco.com >>>>>> >>>>> >>>> >>> >> > --Apple-Mail-6-910284558 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16 KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS +lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8 umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3 aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6 1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNjEyMTc1MzE4 WjAjBgkqhkiG9w0BCQQxFgQUxcC/OYyCLKoBdIE4c6KhrHhgTggwcgYJKwYBBAGCNxAEMWUwYzBd MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB BQAEgYDaxEECOBXZhddWdHCmBBctYc9G28W6gLReA4iOSg3l1mjyKxRy0yYmtwISqIIYJ09gbYeV WDgR18M9RRtqF3v4rOhUIaBTc8TqZ5jfC/e2ZJE5DtaBhBhUDeG2uZ+ike08ftZbXj0Rm3RDSU7R j/xWOLr0xjl70/WfeUZM3ExiqgAAAAAAAA== --Apple-Mail-6-910284558-- From owner-ietf-pkix@mail.imc.org Thu Jun 12 16:45:58 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3DA3A681C for ; Thu, 12 Jun 2008 16:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glCjn0d3KASn for ; Thu, 12 Jun 2008 16:45:45 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 245B13A6B0A for ; Thu, 12 Jun 2008 16:45:39 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CN7cde091010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 16:07:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5CN7cvt091009; Thu, 12 Jun 2008 16:07:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CN7Y9U090982 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Thu, 12 Jun 2008 16:07:35 -0700 (MST) (envelope-from pritikin@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,633,1204531200"; d="scan'208";a="112602745" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2008 16:07:33 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5CN7Xev005638; Thu, 12 Jun 2008 16:07:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5CN7XTs001731; Thu, 12 Jun 2008 23:07:33 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 16:07:33 -0700 Received: from [192.168.2.16] ([10.21.113.98]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 16:07:32 -0700 Cc: "Tim Polk" , "Bob Bell (rtbell)" , Message-Id: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> From: max pritikin To: "Santosh Chokhani" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Thu, 12 Jun 2008 18:07:28 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 12 Jun 2008 23:07:33.0022 (UTC) FILETIME=[187703E0:01C8CCE1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10798; t=1213312053; x=1214176053; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20RFC=205280=20Question |Sender:=20; bh=pL6dCr7Hk43dQ+HQ8B0SNt/7N6SF+eXmu36Csx430jI=; b=dR5maqwWXJzD//UiImW5azUsdjo/9Ug1231Lxqugq8iXDW2UvnC6utAvQI zeQSXQwhc9y46fKFlIuW/sT6+b3CuAm9jlLSwRf4Zd5g/sfPxjgSdkYeFt8v c9u9O1P1Ce; Authentication-Results: sj-dkim-2; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think Bob's question touched on an important issue. The inclusion of self-signed or EE certificates into the certificate store. For an example one should experiment with how the various major web browsers handle "trust this certificate" (sometimes called "trust this web page" etc). They all do it differently. - max On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: > > Max, > > I do not understand from your posting what the specific concern or > issue > you want to bring to the attention of PKIX. > > We have had lot of digressions on this topic. > > Please restate what your concerns are. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 11:11 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > I'm not sure what Bob's goals are, perhaps just to ask the question. > We don't work very closely together. > > This just struck a note with me because I've seen it raised as a > problem in other cases as well. > > - max > > On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > >> >> Max, >> >> I am just responding to inaccuracies in what you are saying. >> >> Can you and Bob tell me why you started this thread and what you are >> seeking from the PKIX community? >> >> I for sure am clueless except for pointing out inaccuracies in your >> assertions and/or conclusions. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 6:51 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> Santosh, you've moved the conversation back to a discussion of item >> (3) in my comments below: out-of-scope population of the trust >> anchors. I think this is orthogonal to a discussion of dealing with >> trust-anchors that exactly match a single certificate being >> validated. >> >> - max >> >> >> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >> >>> >>> Max, >>> >>> I do not have any problem with successfully verifying signature made >>> by >>> a trust anchor. >>> >>> As I said a day or two back in this chain, if the relying party who >>> installs the certificate as a trust anchor and does not make >>> additional >>> checks of basic constraints, is susceptible to undetected compromise >>> of >>> this end entity certificate spawning an entire PKI hierarchy. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 6:17 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> We're into the realm of discussing _how_ one would modify >>> Certificate >>> Path Validation to support EE certificates as a trust anchor where >>> my >>> intention was only to support the concept as a discussion point. >>> >>> Santosh, it isn't that the constraints/extensions are ever applied >>> to >>> the trust anchor credential itself. It is that they are applied when >>> validating the chain. Take for example Name Constraints or Policy >>> Constraints or other Basic Constraints fields such as >>> pathLenConstraint which are all in the trust anchor certificate and >>> then taken into account when validating a certificate chain. If the >>> trust anchor certificate does not have keyCertSign set then >>> logically >>> no 'chained' certificates would be valid; just like if the >>> pathLenConstraint was '1' but the chain being verified has a path >>> length of something greater. >>> >>> I think this question of EE cert vs CA cert as a trust anchor is >>> about >>> what should happen if the chain being validated consists of only the >>> trust anchor. Independent of any questions concerning key usage, >>> constraints or anything else. >>> >>> - max >>> >>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>> >>>> >>>> Max, >>>> >>>> The text you cite does not apply to trust anchor. Please see X.509 >>>> and >>>> RFC 5280 path validation text. Nothing needs to be verified from a >>>> trust anchor. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> Santosh, >>>> >>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>> The cA boolean indicates whether the certified public key may be >>>>> used >>>>> to verify certificate signatures. If the cA boolean is not >>>>> asserted, >>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>> asserted. If the basic constraints extension is not present in a >>>>> version 3 certificate, or the extension is present but the cA >>>>> boolean >>>>> is not asserted, then the certified public key MUST NOT be used to >>>>> verify certificate signatures. >>>> >>>> An EE certificate being in the trust store would not cause >>>> confusion >>>> about this. >>>> >>>> - max >>>> >>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I do not agree with your point on item 2. Once a certificate is a >>>>> trust >>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>> being a >>>>> issuer. >>>>> >>>>> Furthermore, path length constraint if present in the self-signed >>>>> certificate can be ignored by relying parties. >>>>> >>>>> -----Original Message----- >>>>> From: owner-ietf-pkix@mail.imc.org >>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>> ] >>>>> On Behalf Of max pritikin >>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>> To: Tim Polk >>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> >>>>> A few comments on this thread: >>>>> >>>>> 1) Any entry in the trust anchor store would seem to be "directly >>>>> trusted". If so an additional flag isn't needed so much as a >>>>> statement >>>>> about how path validation proceeds if, during path discovery, it >>>>> turns >>>>> out the certificate being validated is already directly trusted. >>>>> >>>>> 2) Inclusion into the trust anchor store doesn't imply that a >>>>> cert >>>>> is >>>>> trusted to issue certificates -- that is directly controlled by >>>>> the >>>>> values within the certificate (chain). >>>>> >>>>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>>>> been the subject of recent BoF work (and more?). It would nice if >>>>> that >>>>> work also addressed this question. >>>>> >>>>> Issues related to this come up on a regular basis. Look at the >>>>> various >>>>> ways browser deal with caching EE certificates to "trust this site >>>>> always" etc. I think Bob has raised a good point. >>>>> >>>>> - max >>>>> >>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>> >>>>>> >>>>>> Bob, >>>>>> >>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>> Wen- >>>>>> Chen Wang have already provided a lot of good feedback. I >>>>>> decided >>>>>> to respond to the original message because I would like to go >>>>>> back >>>>>> to the perceived requirement.] >>>>>> >>>>>> It sounds like you want to construct a list of directly trusted >>>>>> EE >>>>>> certificates, but are trying to satisfy this requirement using >>>>>> the >>>>>> application's trust anchor store. There is nothing inherently >>>>>> wrong >>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>> trusting >>>>>> an EE certificate), but you really need a different - and far >>>>>> simpler - mechanism. The trust anchor store is implicitly linked >>>>>> to >>>>>> path discovery and validation, which are not relevant here >>>>>> since a >>>>>> directly trusted certificate cannot be validated. With a >>>>>> directly >>>>>> trusted certificate, there is also no mechanism to validate >>>>>> status >>>>>> information. >>>>>> >>>>>> To further complicate matters, storing the certificate you wish >>>>>> to >>>>>> directly trust in the trust anchor store implies that it is >>>>>> trusted >>>>>> to issue certificates as well. The path validation inputs >>>>>> specified >>>>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>>>> public key algorithm, public key, and parameters if needed). The >>>>>> assumption is that the trust anchor's authority to issue >>>>>> certificates was verified based on an out-of-band trust mechanism >>>>>> (which is out of scope for 5280). This makes sense since a trust >>>>>> anchor might have distributed a v1 certificate (which does not >>>>>> include extensions). >>>>>> >>>>>> As others have noted, direct trust also implies an out-of-band >>>>>> trust >>>>>> mechanism. I received the EE certificate from a trusted source >>>>>> so I >>>>>> can trust the binding between the subject name and the key; >>>>>> issuer >>>>>> name and the signature are irrelevant. If the certificate >>>>>> status >>>>>> matters, I am also depending on an out-of-band mechanism to >>>>>> inform >>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>> local storage provide the basis for security in this system... >>>>>> >>>>>> Trying to combine these two mechanisms using a single certificate >>>>>> store probably requires an additional flag on every entry to >>>>>> differentiate between directly trusted certificates and trust >>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Tim Polk >>>>>> >>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>> >>>>>>> Folks- >>>>>>> >>>>>>> I am hoping someone can give me the answer to this. Does RFC >>>>>>> 5280 >>>>>>> adress the case where an end-entity certificate (not a CA cert) >>>>>>> is >>>>>>> installed in the trust anchor list by the user accepting the >>>>>>> presented cert as authoritative and then the cert is >>>>>>> subsequently >>>>>>> presented (in a later access to the site). There should be no >>>>>>> path >>>>>>> search, since the presented cert is in the trust anchor list. >>>>>>> So, >>>>>>> where is it defined to accept the end-entity cert? >>>>>>> >>>>>>> Thanks ---- Bob >>>>>>> >>>>>>> Bob Bell >>>>>>> Cisco Systems, Inc. >>>>>>> 576 S. Brentwood Ln. >>>>>>> Bountiful, UT 84010 >>>>>>> 801-294-3034 (v) >>>>>>> 801-294-3023 (f) >>>>>>> 801-971-4200 (c) >>>>>>> rtbell@cisco.com >>>>>>> >>>>>> >>>>> >>>> >>> >> > From owner-ietf-pkix@mail.imc.org Thu Jun 12 17:54:34 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739B73A69F1 for ; Thu, 12 Jun 2008 17:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4CVq+WyxEaS for ; Thu, 12 Jun 2008 17:54:33 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5ECC53A6907 for ; Thu, 12 Jun 2008 17:54:32 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5D0LEC7005437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 17:21:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5D0LEFB005436; Thu, 12 Jun 2008 17:21:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5D0LCEh005430 for ; Thu, 12 Jun 2008 17:21:13 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 27632 invoked from network); 13 Jun 2008 00:10:53 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Jun 2008 00:10:53 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Jun 2008 00:10:53 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Thu, 12 Jun 2008 20:21:04 -0400 Message-ID: In-Reply-To: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjM4R2FGr+XJh/aR3icrE8p2IycgQACdOqg References: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> From: "Santosh Chokhani" To: "max pritikin" Cc: "Tim Polk" , "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, So, are you saying that you wanted to explore the implication of a self-signed certificate that does not have basic constraints extension in it and does not set keyCertSign bit in the key usage? I ask because that is the certificate Bob sent me. Please provide a clear, concise and complete description of your issues so that we have the same point of reference for discussions. -----Original Message----- From: max pritikin [mailto:pritikin@cisco.com]=20 Sent: Thursday, June 12, 2008 7:07 PM To: Santosh Chokhani Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org Subject: Re: RFC 5280 Question I think Bob's question touched on an important issue. The inclusion of =20 self-signed or EE certificates into the certificate store. For an example one should experiment with how the various major web =20 browsers handle "trust this certificate" (sometimes called "trust this =20 web page" etc). They all do it differently. - max On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: > > Max, > > I do not understand from your posting what the specific concern or =20 > issue > you want to bring to the attention of PKIX. > > We have had lot of digressions on this topic. > > Please restate what your concerns are. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 11:11 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > I'm not sure what Bob's goals are, perhaps just to ask the question. > We don't work very closely together. > > This just struck a note with me because I've seen it raised as a > problem in other cases as well. > > - max > > On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > >> >> Max, >> >> I am just responding to inaccuracies in what you are saying. >> >> Can you and Bob tell me why you started this thread and what you are >> seeking from the PKIX community? >> >> I for sure am clueless except for pointing out inaccuracies in your >> assertions and/or conclusions. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 6:51 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> Santosh, you've moved the conversation back to a discussion of item >> (3) in my comments below: out-of-scope population of the trust >> anchors. I think this is orthogonal to a discussion of dealing with >> trust-anchors that exactly match a single certificate being =20 >> validated. >> >> - max >> >> >> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >> >>> >>> Max, >>> >>> I do not have any problem with successfully verifying signature made >>> by >>> a trust anchor. >>> >>> As I said a day or two back in this chain, if the relying party who >>> installs the certificate as a trust anchor and does not make >>> additional >>> checks of basic constraints, is susceptible to undetected compromise >>> of >>> this end entity certificate spawning an entire PKI hierarchy. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 6:17 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> We're into the realm of discussing _how_ one would modify =20 >>> Certificate >>> Path Validation to support EE certificates as a trust anchor where =20 >>> my >>> intention was only to support the concept as a discussion point. >>> >>> Santosh, it isn't that the constraints/extensions are ever applied =20 >>> to >>> the trust anchor credential itself. It is that they are applied when >>> validating the chain. Take for example Name Constraints or Policy >>> Constraints or other Basic Constraints fields such as >>> pathLenConstraint which are all in the trust anchor certificate and >>> then taken into account when validating a certificate chain. If the >>> trust anchor certificate does not have keyCertSign set then =20 >>> logically >>> no 'chained' certificates would be valid; just like if the >>> pathLenConstraint was '1' but the chain being verified has a path >>> length of something greater. >>> >>> I think this question of EE cert vs CA cert as a trust anchor is >>> about >>> what should happen if the chain being validated consists of only the >>> trust anchor. Independent of any questions concerning key usage, >>> constraints or anything else. >>> >>> - max >>> >>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>> >>>> >>>> Max, >>>> >>>> The text you cite does not apply to trust anchor. Please see X.509 >>>> and >>>> RFC 5280 path validation text. Nothing needs to be verified from a >>>> trust anchor. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> Santosh, >>>> >>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>> The cA boolean indicates whether the certified public key may be >>>>> used >>>>> to verify certificate signatures. If the cA boolean is not >>>>> asserted, >>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>> asserted. If the basic constraints extension is not present in a >>>>> version 3 certificate, or the extension is present but the cA >>>>> boolean >>>>> is not asserted, then the certified public key MUST NOT be used to >>>>> verify certificate signatures. >>>> >>>> An EE certificate being in the trust store would not cause =20 >>>> confusion >>>> about this. >>>> >>>> - max >>>> >>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I do not agree with your point on item 2. Once a certificate is a >>>>> trust >>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>> being a >>>>> issuer. >>>>> >>>>> Furthermore, path length constraint if present in the self-signed >>>>> certificate can be ignored by relying parties. >>>>> >>>>> -----Original Message----- >>>>> From: owner-ietf-pkix@mail.imc.org >>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>> ] >>>>> On Behalf Of max pritikin >>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>> To: Tim Polk >>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> >>>>> A few comments on this thread: >>>>> >>>>> 1) Any entry in the trust anchor store would seem to be "directly >>>>> trusted". If so an additional flag isn't needed so much as a >>>>> statement >>>>> about how path validation proceeds if, during path discovery, it >>>>> turns >>>>> out the certificate being validated is already directly trusted. >>>>> >>>>> 2) Inclusion into the trust anchor store doesn't imply that a =20 >>>>> cert >>>>> is >>>>> trusted to issue certificates -- that is directly controlled by =20 >>>>> the >>>>> values within the certificate (chain). >>>>> >>>>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>>>> been the subject of recent BoF work (and more?). It would nice if >>>>> that >>>>> work also addressed this question. >>>>> >>>>> Issues related to this come up on a regular basis. Look at the >>>>> various >>>>> ways browser deal with caching EE certificates to "trust this site >>>>> always" etc. I think Bob has raised a good point. >>>>> >>>>> - max >>>>> >>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>> >>>>>> >>>>>> Bob, >>>>>> >>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>> Wen- >>>>>> Chen Wang have already provided a lot of good feedback. I =20 >>>>>> decided >>>>>> to respond to the original message because I would like to go =20 >>>>>> back >>>>>> to the perceived requirement.] >>>>>> >>>>>> It sounds like you want to construct a list of directly trusted =20 >>>>>> EE >>>>>> certificates, but are trying to satisfy this requirement using =20 >>>>>> the >>>>>> application's trust anchor store. There is nothing inherently >>>>>> wrong >>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>> trusting >>>>>> an EE certificate), but you really need a different - and far >>>>>> simpler - mechanism. The trust anchor store is implicitly linked >>>>>> to >>>>>> path discovery and validation, which are not relevant here =20 >>>>>> since a >>>>>> directly trusted certificate cannot be validated. With a =20 >>>>>> directly >>>>>> trusted certificate, there is also no mechanism to validate =20 >>>>>> status >>>>>> information. >>>>>> >>>>>> To further complicate matters, storing the certificate you wish =20 >>>>>> to >>>>>> directly trust in the trust anchor store implies that it is >>>>>> trusted >>>>>> to issue certificates as well. The path validation inputs >>>>>> specified >>>>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>>>> public key algorithm, public key, and parameters if needed). The >>>>>> assumption is that the trust anchor's authority to issue >>>>>> certificates was verified based on an out-of-band trust mechanism >>>>>> (which is out of scope for 5280). This makes sense since a trust >>>>>> anchor might have distributed a v1 certificate (which does not >>>>>> include extensions). >>>>>> >>>>>> As others have noted, direct trust also implies an out-of-band >>>>>> trust >>>>>> mechanism. I received the EE certificate from a trusted source >>>>>> so I >>>>>> can trust the binding between the subject name and the key; =20 >>>>>> issuer >>>>>> name and the signature are irrelevant. If the certificate =20 >>>>>> status >>>>>> matters, I am also depending on an out-of-band mechanism to =20 >>>>>> inform >>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>> local storage provide the basis for security in this system... >>>>>> >>>>>> Trying to combine these two mechanisms using a single certificate >>>>>> store probably requires an additional flag on every entry to >>>>>> differentiate between directly trusted certificates and trust >>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Tim Polk >>>>>> >>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>> >>>>>>> Folks- >>>>>>> >>>>>>> I am hoping someone can give me the answer to this. Does RFC =20 >>>>>>> 5280 >>>>>>> adress the case where an end-entity certificate (not a CA cert) >>>>>>> is >>>>>>> installed in the trust anchor list by the user accepting the >>>>>>> presented cert as authoritative and then the cert is =20 >>>>>>> subsequently >>>>>>> presented (in a later access to the site). There should be no >>>>>>> path >>>>>>> search, since the presented cert is in the trust anchor list. =20 >>>>>>> So, >>>>>>> where is it defined to accept the end-entity cert? >>>>>>> >>>>>>> Thanks ---- Bob >>>>>>> >>>>>>> Bob Bell >>>>>>> Cisco Systems, Inc. >>>>>>> 576 S. Brentwood Ln. >>>>>>> Bountiful, UT 84010 >>>>>>> 801-294-3034 (v) >>>>>>> 801-294-3023 (f) >>>>>>> 801-971-4200 (c) >>>>>>> rtbell@cisco.com >>>>>>> >>>>>> >>>>> >>>> >>> >> > From owner-ietf-pkix@mail.imc.org Thu Jun 12 19:59:42 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB2F3A68C4 for ; Thu, 12 Jun 2008 19:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b9-86K38N04 for ; Thu, 12 Jun 2008 19:59:41 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A9FE53A6A4C for ; Thu, 12 Jun 2008 19:59:40 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5D2KvLe032541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 19:20:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5D2KvWo032540; Thu, 12 Jun 2008 19:20:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5D2KtS1032517 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Thu, 12 Jun 2008 19:20:56 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,635,1204531200"; d="p7s'?scan'208";a="112674539" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2008 19:20:55 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5D2KtWH032647; Thu, 12 Jun 2008 19:20:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5D2KsNr000755; Fri, 13 Jun 2008 02:20:55 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 19:20:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Thu, 12 Jun 2008 19:20:51 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0153_01C8CCC9.CF04CBF0" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjM4R2FGr+XJh/aR3icrE8p2IycgQACdOqgAAQzQhA= References: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , "Max Pritikin (pritikin)" Cc: "Tim Polk" , X-OriginalArrivalTime: 13 Jun 2008 02:20:54.0789 (UTC) FILETIME=[1BA82B50:01C8CCFC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17571; t=1213323655; x=1214187655; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=szJwRVVOmyAphJWUB3VyvqTiOoWK7USmixJBG8TJHpY=; b=khO0HK6811HW1DNlAkI2nKuyCV1T42YDsBRH+K9e5XK2AdyFjAsfAnUpLn RaeL9y3HXDFGtIlZ0vtYtHdE4blvOfqMv2mHIQg2CWwzS05lb3/Wfx0PtE3T Q6uNtJlaAYRgD3FAdE5bzH8+hzm0RrH6naU/i7p+sN7ADRwb74bKM=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0153_01C8CCC9.CF04CBF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - I would recommend that the definition be broadened slightly to indicate that regardless of whether basic constraints are present (as long as the CA bit is false or non-existent), and that the keyCertSign bit is false. This, at least as I read the definitions, defines the cert as an end-entity cert. That kind of a cert in the trust store is what is causing problems for me. Bob > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani > Sent: Thursday, 12 June, 2008 18:21 > To: Max Pritikin (pritikin) > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > > Max, > > So, are you saying that you wanted to explore the implication > of a self-signed certificate that does not have basic > constraints extension in it and does not set keyCertSign bit > in the key usage? I ask because that is the certificate Bob sent me. > > Please provide a clear, concise and complete description of > your issues so that we have the same point of reference for > discussions. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Thursday, June 12, 2008 7:07 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > I think Bob's question touched on an important issue. The > inclusion of > self-signed or EE certificates into the certificate store. > > For an example one should experiment with how the various major web > browsers handle "trust this certificate" (sometimes called > "trust this > web page" etc). They all do it differently. > > - max > > On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: > > > > > Max, > > > > I do not understand from your posting what the specific concern or > > issue > > you want to bring to the attention of PKIX. > > > > We have had lot of digressions on this topic. > > > > Please restate what your concerns are. > > > > -----Original Message----- > > From: max pritikin [mailto:pritikin@cisco.com] > > Sent: Tuesday, June 10, 2008 11:11 PM > > To: Santosh Chokhani > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > Subject: Re: RFC 5280 Question > > > > > > I'm not sure what Bob's goals are, perhaps just to ask the question. > > We don't work very closely together. > > > > This just struck a note with me because I've seen it raised as a > > problem in other cases as well. > > > > - max > > > > On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > > >> > >> Max, > >> > >> I am just responding to inaccuracies in what you are saying. > >> > >> Can you and Bob tell me why you started this thread and > what you are > >> seeking from the PKIX community? > >> > >> I for sure am clueless except for pointing out inaccuracies in your > >> assertions and/or conclusions. > >> > >> -----Original Message----- > >> From: max pritikin [mailto:pritikin@cisco.com] > >> Sent: Tuesday, June 10, 2008 6:51 PM > >> To: Santosh Chokhani > >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >> Subject: Re: RFC 5280 Question > >> > >> > >> Santosh, you've moved the conversation back to a discussion of item > >> (3) in my comments below: out-of-scope population of the trust > >> anchors. I think this is orthogonal to a discussion of dealing with > >> trust-anchors that exactly match a single certificate being > >> validated. > >> > >> - max > >> > >> > >> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > >> > >>> > >>> Max, > >>> > >>> I do not have any problem with successfully verifying > signature made > >>> by > >>> a trust anchor. > >>> > >>> As I said a day or two back in this chain, if the relying > party who > >>> installs the certificate as a trust anchor and does not make > >>> additional > >>> checks of basic constraints, is susceptible to undetected > compromise > >>> of > >>> this end entity certificate spawning an entire PKI hierarchy. > >>> > >>> -----Original Message----- > >>> From: max pritikin [mailto:pritikin@cisco.com] > >>> Sent: Tuesday, June 10, 2008 6:17 PM > >>> To: Santosh Chokhani > >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >>> Subject: Re: RFC 5280 Question > >>> > >>> > >>> We're into the realm of discussing _how_ one would modify > >>> Certificate > >>> Path Validation to support EE certificates as a trust > anchor where > >>> my > >>> intention was only to support the concept as a discussion point. > >>> > >>> Santosh, it isn't that the constraints/extensions are > ever applied > >>> to > >>> the trust anchor credential itself. It is that they are > applied when > >>> validating the chain. Take for example Name Constraints or Policy > >>> Constraints or other Basic Constraints fields such as > >>> pathLenConstraint which are all in the trust anchor > certificate and > >>> then taken into account when validating a certificate > chain. If the > >>> trust anchor certificate does not have keyCertSign set then > >>> logically > >>> no 'chained' certificates would be valid; just like if the > >>> pathLenConstraint was '1' but the chain being verified has a path > >>> length of something greater. > >>> > >>> I think this question of EE cert vs CA cert as a trust anchor is > >>> about > >>> what should happen if the chain being validated consists > of only the > >>> trust anchor. Independent of any questions concerning key usage, > >>> constraints or anything else. > >>> > >>> - max > >>> > >>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > >>> > >>>> > >>>> Max, > >>>> > >>>> The text you cite does not apply to trust anchor. > Please see X.509 > >>>> and > >>>> RFC 5280 path validation text. Nothing needs to be > verified from a > >>>> trust anchor. > >>>> > >>>> -----Original Message----- > >>>> From: max pritikin [mailto:pritikin@cisco.com] > >>>> Sent: Tuesday, June 10, 2008 4:47 PM > >>>> To: Santosh Chokhani > >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >>>> Subject: Re: RFC 5280 Question > >>>> > >>>> > >>>> Santosh, > >>>> > >>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: > >>>>> The cA boolean indicates whether the certified public key may be > >>>>> used > >>>>> to verify certificate signatures. If the cA boolean is not > >>>>> asserted, > >>>>> then the keyCertSign bit in the key usage extension MUST NOT be > >>>>> asserted. If the basic constraints extension is not > present in a > >>>>> version 3 certificate, or the extension is present but the cA > >>>>> boolean > >>>>> is not asserted, then the certified public key MUST NOT > be used to > >>>>> verify certificate signatures. > >>>> > >>>> An EE certificate being in the trust store would not cause > >>>> confusion > >>>> about this. > >>>> > >>>> - max > >>>> > >>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > >>>> > >>>>> Max, > >>>>> > >>>>> I do not agree with your point on item 2. Once a > certificate is a > >>>>> trust > >>>>> anchor, neither X.509 not 5280 have any constraints on it from > >>>>> being a > >>>>> issuer. > >>>>> > >>>>> Furthermore, path length constraint if present in the > self-signed > >>>>> certificate can be ignored by relying parties. > >>>>> > >>>>> -----Original Message----- > >>>>> From: owner-ietf-pkix@mail.imc.org > >>>> [mailto:owner-ietf-pkix@mail.imc.org > >>>>> ] > >>>>> On Behalf Of max pritikin > >>>>> Sent: Tuesday, June 10, 2008 2:35 PM > >>>>> To: Tim Polk > >>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org > >>>>> Subject: Re: RFC 5280 Question > >>>>> > >>>>> > >>>>> > >>>>> A few comments on this thread: > >>>>> > >>>>> 1) Any entry in the trust anchor store would seem to be > "directly > >>>>> trusted". If so an additional flag isn't needed so much as a > >>>>> statement > >>>>> about how path validation proceeds if, during path discovery, it > >>>>> turns > >>>>> out the certificate being validated is already directly trusted. > >>>>> > >>>>> 2) Inclusion into the trust anchor store doesn't imply that a > >>>>> cert > >>>>> is > >>>>> trusted to issue certificates -- that is directly > controlled by > >>>>> the > >>>>> values within the certificate (chain). > >>>>> > >>>>> 3) The out-of-band mechanism is out of scope for > 5280/3280 but has > >>>>> been the subject of recent BoF work (and more?). It > would nice if > >>>>> that > >>>>> work also addressed this question. > >>>>> > >>>>> Issues related to this come up on a regular basis. Look at the > >>>>> various > >>>>> ways browser deal with caching EE certificates to > "trust this site > >>>>> always" etc. I think Bob has raised a good point. > >>>>> > >>>>> - max > >>>>> > >>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > >>>>> > >>>>>> > >>>>>> Bob, > >>>>>> > >>>>>> [I realize I am late to the party, and that Santosh, Steve, and > >>>>>> Wen- > >>>>>> Chen Wang have already provided a lot of good feedback. I > >>>>>> decided > >>>>>> to respond to the original message because I would like to go > >>>>>> back > >>>>>> to the perceived requirement.] > >>>>>> > >>>>>> It sounds like you want to construct a list of > directly trusted > >>>>>> EE > >>>>>> certificates, but are trying to satisfy this > requirement using > >>>>>> the > >>>>>> application's trust anchor store. There is nothing inherently > >>>>>> wrong > >>>>>> with direct trust (and RFC 5280 does not preclude directly > >>>>>> trusting > >>>>>> an EE certificate), but you really need a different - and far > >>>>>> simpler - mechanism. The trust anchor store is > implicitly linked > >>>>>> to > >>>>>> path discovery and validation, which are not relevant here > >>>>>> since a > >>>>>> directly trusted certificate cannot be validated. With a > >>>>>> directly > >>>>>> trusted certificate, there is also no mechanism to validate > >>>>>> status > >>>>>> information. > >>>>>> > >>>>>> To further complicate matters, storing the certificate > you wish > >>>>>> to > >>>>>> directly trust in the trust anchor store implies that it is > >>>>>> trusted > >>>>>> to issue certificates as well. The path validation inputs > >>>>>> specified > >>>>>> in 6.1.1 (d) consider only four aspects of a trust > anchor (name, > >>>>>> public key algorithm, public key, and parameters if > needed). The > >>>>>> assumption is that the trust anchor's authority to issue > >>>>>> certificates was verified based on an out-of-band > trust mechanism > >>>>>> (which is out of scope for 5280). This makes sense > since a trust > >>>>>> anchor might have distributed a v1 certificate (which does not > >>>>>> include extensions). > >>>>>> > >>>>>> As others have noted, direct trust also implies an out-of-band > >>>>>> trust > >>>>>> mechanism. I received the EE certificate from a trusted source > >>>>>> so I > >>>>>> can trust the binding between the subject name and the key; > >>>>>> issuer > >>>>>> name and the signature are irrelevant. If the certificate > >>>>>> status > >>>>>> matters, I am also depending on an out-of-band mechanism to > >>>>>> inform > >>>>>> me! The out-of-band mechanism(s) in combination with protected > >>>>>> local storage provide the basis for security in this system... > >>>>>> > >>>>>> Trying to combine these two mechanisms using a single > certificate > >>>>>> store probably requires an additional flag on every entry to > >>>>>> differentiate between directly trusted certificates and trust > >>>>>> anchors. Two separate stores might be cleaner in the long run. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Tim Polk > >>>>>> > >>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > >>>>>> > >>>>>>> Folks- > >>>>>>> > >>>>>>> I am hoping someone can give me the answer to this. Does RFC > >>>>>>> 5280 > >>>>>>> adress the case where an end-entity certificate (not > a CA cert) > >>>>>>> is > >>>>>>> installed in the trust anchor list by the user accepting the > >>>>>>> presented cert as authoritative and then the cert is > >>>>>>> subsequently > >>>>>>> presented (in a later access to the site). There should be no > >>>>>>> path > >>>>>>> search, since the presented cert is in the trust > anchor list. > >>>>>>> So, > >>>>>>> where is it defined to accept the end-entity cert? > >>>>>>> > >>>>>>> Thanks ---- Bob > >>>>>>> > >>>>>>> Bob Bell > >>>>>>> Cisco Systems, Inc. > >>>>>>> 576 S. Brentwood Ln. > >>>>>>> Bountiful, UT 84010 > >>>>>>> 801-294-3034 (v) > >>>>>>> 801-294-3023 (f) > >>>>>>> 801-971-4200 (c) > >>>>>>> rtbell@cisco.com > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > ------=_NextPart_000_0153_01C8CCC9.CF04CBF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTMwMjIwNTFaMCMGCSqGSIb3DQEJBDEWBBRjgVvC+97VhS9qHdoo /Wcumg/mqDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYCspFhnMK6kov9ErpMlQx7a7WoH+b0dF4s/nm20gLdRASpbMgmit4wUeAkV0RZJfCYwXEKU /9f96IvCbFkI4HTMNX655fXWazSVr4iQZiM+b1LMfTtbS+0oZY8pZz5Asub7gM4krxPC9FLXQ06Z zjBUg1jzu8Lv8kCiVmCXhpQ66gAAAAAAAA== ------=_NextPart_000_0153_01C8CCC9.CF04CBF0-- From owner-ietf-pkix@mail.imc.org Fri Jun 13 02:33:28 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDBAB3A6B58 for ; Fri, 13 Jun 2008 02:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMpuHGOQAaiR for ; Fri, 13 Jun 2008 02:33:27 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A03223A6B57 for ; Fri, 13 Jun 2008 02:33:26 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5D8j96m012455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 01:45:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5D8j9OF012454; Fri, 13 Jun 2008 01:45:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (kraid.ipv6.nerim.net [IPv6:2001:7a8:1:1::95]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5D8j73o012447 for ; Fri, 13 Jun 2008 01:45:08 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id A2B1CCF095; Fri, 13 Jun 2008 10:45:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 0DA00442A0; Fri, 13 Jun 2008 10:45:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqIHsSDrauUA; Fri, 13 Jun 2008 10:44:59 +0200 (CEST) Received: from [10.0.1.15] (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with ESMTP id 7487749717; Fri, 13 Jun 2008 10:13:52 +0200 (CEST) Message-ID: <48522C3F.4050103@cryptolog.com> Date: Fri, 13 Jun 2008 10:13:51 +0200 From: Julien Stern User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: "Bob Bell (rtbell)" Cc: Santosh Chokhani , "Max Pritikin (pritikin)" , Tim Polk , ietf-pkix@imc.org Subject: Re: RFC 5280 Question References: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If I may (briefly) jump into the discussion. There seem to be a misunderstanding regarding "trusted certificates" and "trust store". Neither X.509 nor 5280 define the notion of trust store or trusted certificate. This does not exist and there is no such thing as trusted EE certificates or trusted CA certificates. You can have a "Trust Anchor" that is a DN and a public Key (see X.509 p.6 for the definition) which can be used to verify other certificates. In practice, the DN and the public key, are commonly distributed as an X.509 certificate, but that's to make things simple. Extensions/constraints, etc are not supposed to apply (See validation algorithm in X.509, p.50) Then, you have the notion of "Direct Trust", which is not clearly expressed in X.509 or 5280, but which is natural in a PKI. Direct Trust means that you have verified the binding between a DN and a public key by out of band means. In other words, it means you know the owner of the key. It this owner happens to be a CA, you are essentially in the "Trust Anchor" case. Otherwise, you are also supposed to know (by out of band means) what the public key can be used for. In your specific case, my reading of the standard is the following: 1) you insert a "certificate" in a "trust store" => This means that you insert only the public key and the DN as trusted and as a CA (the rest of the certificate is irrelevant). 2) You want to try to use standard validation mechanisms (and not direct trust). You take your EE cert, and since it is self signed and self-issued, it will validate up to the trust anchor that you have entered. 3) Be warned, however, that the owner of this public key will now be able to issue as many certificates for other DNs that he wishes. Alternative option: you use "direct trust". 1) You insert your certificate in a "direct trust store". 2) When encountering the certificate, you do not perform the X.509 validation if is it "directly trusted" 3) Be warned that you can only revoke by hand. Now, I believe (experts, please correct me if I'm wrong), that you are free to modify the X.509 or the 5280 validation algorithm as long as you are more restrictive. So, I assume you could define a "trust store with constraints" that would be populated with "trust anchors with constraints" in any way you see fit. Hope this helps. Regards, -- Julien Bob Bell (rtbell) wrote: > Santosh - > > I would recommend that the definition be broadened slightly to indicate that > regardless of whether basic constraints are present (as long as the CA bit > is false or non-existent), and that the keyCertSign bit is false. This, at > least as I read the definitions, defines the cert as an end-entity cert. > That kind of a cert in the trust store is what is causing problems for me. > > Bob > >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org >> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani >> Sent: Thursday, 12 June, 2008 18:21 >> To: Max Pritikin (pritikin) >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> >> Max, >> >> So, are you saying that you wanted to explore the implication >> of a self-signed certificate that does not have basic >> constraints extension in it and does not set keyCertSign bit >> in the key usage? I ask because that is the certificate Bob sent me. >> >> Please provide a clear, concise and complete description of >> your issues so that we have the same point of reference for >> discussions. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Thursday, June 12, 2008 7:07 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> I think Bob's question touched on an important issue. The >> inclusion of >> self-signed or EE certificates into the certificate store. >> >> For an example one should experiment with how the various major web >> browsers handle "trust this certificate" (sometimes called >> "trust this >> web page" etc). They all do it differently. >> >> - max >> >> On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: >> >>> Max, >>> >>> I do not understand from your posting what the specific concern or >>> issue >>> you want to bring to the attention of PKIX. >>> >>> We have had lot of digressions on this topic. >>> >>> Please restate what your concerns are. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 11:11 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> I'm not sure what Bob's goals are, perhaps just to ask the question. >>> We don't work very closely together. >>> >>> This just struck a note with me because I've seen it raised as a >>> problem in other cases as well. >>> >>> - max >>> >>> On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I am just responding to inaccuracies in what you are saying. >>>> >>>> Can you and Bob tell me why you started this thread and >> what you are >>>> seeking from the PKIX community? >>>> >>>> I for sure am clueless except for pointing out inaccuracies in your >>>> assertions and/or conclusions. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 6:51 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> Santosh, you've moved the conversation back to a discussion of item >>>> (3) in my comments below: out-of-scope population of the trust >>>> anchors. I think this is orthogonal to a discussion of dealing with >>>> trust-anchors that exactly match a single certificate being >>>> validated. >>>> >>>> - max >>>> >>>> >>>> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I do not have any problem with successfully verifying >> signature made >>>>> by >>>>> a trust anchor. >>>>> >>>>> As I said a day or two back in this chain, if the relying >> party who >>>>> installs the certificate as a trust anchor and does not make >>>>> additional >>>>> checks of basic constraints, is susceptible to undetected >> compromise >>>>> of >>>>> this end entity certificate spawning an entire PKI hierarchy. >>>>> >>>>> -----Original Message----- >>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>> Sent: Tuesday, June 10, 2008 6:17 PM >>>>> To: Santosh Chokhani >>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> We're into the realm of discussing _how_ one would modify >>>>> Certificate >>>>> Path Validation to support EE certificates as a trust >> anchor where >>>>> my >>>>> intention was only to support the concept as a discussion point. >>>>> >>>>> Santosh, it isn't that the constraints/extensions are >> ever applied >>>>> to >>>>> the trust anchor credential itself. It is that they are >> applied when >>>>> validating the chain. Take for example Name Constraints or Policy >>>>> Constraints or other Basic Constraints fields such as >>>>> pathLenConstraint which are all in the trust anchor >> certificate and >>>>> then taken into account when validating a certificate >> chain. If the >>>>> trust anchor certificate does not have keyCertSign set then >>>>> logically >>>>> no 'chained' certificates would be valid; just like if the >>>>> pathLenConstraint was '1' but the chain being verified has a path >>>>> length of something greater. >>>>> >>>>> I think this question of EE cert vs CA cert as a trust anchor is >>>>> about >>>>> what should happen if the chain being validated consists >> of only the >>>>> trust anchor. Independent of any questions concerning key usage, >>>>> constraints or anything else. >>>>> >>>>> - max >>>>> >>>>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> The text you cite does not apply to trust anchor. >> Please see X.509 >>>>>> and >>>>>> RFC 5280 path validation text. Nothing needs to be >> verified from a >>>>>> trust anchor. >>>>>> >>>>>> -----Original Message----- >>>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>>>> To: Santosh Chokhani >>>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>>> Subject: Re: RFC 5280 Question >>>>>> >>>>>> >>>>>> Santosh, >>>>>> >>>>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>>>> The cA boolean indicates whether the certified public key may be >>>>>>> used >>>>>>> to verify certificate signatures. If the cA boolean is not >>>>>>> asserted, >>>>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>>>> asserted. If the basic constraints extension is not >> present in a >>>>>>> version 3 certificate, or the extension is present but the cA >>>>>>> boolean >>>>>>> is not asserted, then the certified public key MUST NOT >> be used to >>>>>>> verify certificate signatures. >>>>>> An EE certificate being in the trust store would not cause >>>>>> confusion >>>>>> about this. >>>>>> >>>>>> - max >>>>>> >>>>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>>>> >>>>>>> Max, >>>>>>> >>>>>>> I do not agree with your point on item 2. Once a >> certificate is a >>>>>>> trust >>>>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>>>> being a >>>>>>> issuer. >>>>>>> >>>>>>> Furthermore, path length constraint if present in the >> self-signed >>>>>>> certificate can be ignored by relying parties. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: owner-ietf-pkix@mail.imc.org >>>>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>>>> ] >>>>>>> On Behalf Of max pritikin >>>>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>>>> To: Tim Polk >>>>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>>>> Subject: Re: RFC 5280 Question >>>>>>> >>>>>>> >>>>>>> >>>>>>> A few comments on this thread: >>>>>>> >>>>>>> 1) Any entry in the trust anchor store would seem to be >> "directly >>>>>>> trusted". If so an additional flag isn't needed so much as a >>>>>>> statement >>>>>>> about how path validation proceeds if, during path discovery, it >>>>>>> turns >>>>>>> out the certificate being validated is already directly trusted. >>>>>>> >>>>>>> 2) Inclusion into the trust anchor store doesn't imply that a >>>>>>> cert >>>>>>> is >>>>>>> trusted to issue certificates -- that is directly >> controlled by >>>>>>> the >>>>>>> values within the certificate (chain). >>>>>>> >>>>>>> 3) The out-of-band mechanism is out of scope for >> 5280/3280 but has >>>>>>> been the subject of recent BoF work (and more?). It >> would nice if >>>>>>> that >>>>>>> work also addressed this question. >>>>>>> >>>>>>> Issues related to this come up on a regular basis. Look at the >>>>>>> various >>>>>>> ways browser deal with caching EE certificates to >> "trust this site >>>>>>> always" etc. I think Bob has raised a good point. >>>>>>> >>>>>>> - max >>>>>>> >>>>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>>>> >>>>>>>> Bob, >>>>>>>> >>>>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>>>> Wen- >>>>>>>> Chen Wang have already provided a lot of good feedback. I >>>>>>>> decided >>>>>>>> to respond to the original message because I would like to go >>>>>>>> back >>>>>>>> to the perceived requirement.] >>>>>>>> >>>>>>>> It sounds like you want to construct a list of >> directly trusted >>>>>>>> EE >>>>>>>> certificates, but are trying to satisfy this >> requirement using >>>>>>>> the >>>>>>>> application's trust anchor store. There is nothing inherently >>>>>>>> wrong >>>>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>>>> trusting >>>>>>>> an EE certificate), but you really need a different - and far >>>>>>>> simpler - mechanism. The trust anchor store is >> implicitly linked >>>>>>>> to >>>>>>>> path discovery and validation, which are not relevant here >>>>>>>> since a >>>>>>>> directly trusted certificate cannot be validated. With a >>>>>>>> directly >>>>>>>> trusted certificate, there is also no mechanism to validate >>>>>>>> status >>>>>>>> information. >>>>>>>> >>>>>>>> To further complicate matters, storing the certificate >> you wish >>>>>>>> to >>>>>>>> directly trust in the trust anchor store implies that it is >>>>>>>> trusted >>>>>>>> to issue certificates as well. The path validation inputs >>>>>>>> specified >>>>>>>> in 6.1.1 (d) consider only four aspects of a trust >> anchor (name, >>>>>>>> public key algorithm, public key, and parameters if >> needed). The >>>>>>>> assumption is that the trust anchor's authority to issue >>>>>>>> certificates was verified based on an out-of-band >> trust mechanism >>>>>>>> (which is out of scope for 5280). This makes sense >> since a trust >>>>>>>> anchor might have distributed a v1 certificate (which does not >>>>>>>> include extensions). >>>>>>>> >>>>>>>> As others have noted, direct trust also implies an out-of-band >>>>>>>> trust >>>>>>>> mechanism. I received the EE certificate from a trusted source >>>>>>>> so I >>>>>>>> can trust the binding between the subject name and the key; >>>>>>>> issuer >>>>>>>> name and the signature are irrelevant. If the certificate >>>>>>>> status >>>>>>>> matters, I am also depending on an out-of-band mechanism to >>>>>>>> inform >>>>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>>>> local storage provide the basis for security in this system... >>>>>>>> >>>>>>>> Trying to combine these two mechanisms using a single >> certificate >>>>>>>> store probably requires an additional flag on every entry to >>>>>>>> differentiate between directly trusted certificates and trust >>>>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Tim Polk >>>>>>>> >>>>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>>>> >>>>>>>>> Folks- >>>>>>>>> >>>>>>>>> I am hoping someone can give me the answer to this. Does RFC >>>>>>>>> 5280 >>>>>>>>> adress the case where an end-entity certificate (not >> a CA cert) >>>>>>>>> is >>>>>>>>> installed in the trust anchor list by the user accepting the >>>>>>>>> presented cert as authoritative and then the cert is >>>>>>>>> subsequently >>>>>>>>> presented (in a later access to the site). There should be no >>>>>>>>> path >>>>>>>>> search, since the presented cert is in the trust >> anchor list. >>>>>>>>> So, >>>>>>>>> where is it defined to accept the end-entity cert? >>>>>>>>> >>>>>>>>> Thanks ---- Bob >>>>>>>>> >>>>>>>>> Bob Bell >>>>>>>>> Cisco Systems, Inc. >>>>>>>>> 576 S. Brentwood Ln. >>>>>>>>> Bountiful, UT 84010 >>>>>>>>> 801-294-3034 (v) >>>>>>>>> 801-294-3023 (f) >>>>>>>>> 801-971-4200 (c) >>>>>>>>> rtbell@cisco.com >>>>>>>>> >> From owner-ietf-pkix@mail.imc.org Fri Jun 13 04:19:10 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5973A6845 for ; Fri, 13 Jun 2008 04:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSOBpvbvujia for ; Fri, 13 Jun 2008 04:19:08 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F0FFA3A6810 for ; Fri, 13 Jun 2008 04:19:07 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DAaxL5038529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 03:36:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DAaxkk038528; Fri, 13 Jun 2008 03:36:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5DAavfW038522 for ; Fri, 13 Jun 2008 03:36:58 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 2101 invoked from network); 13 Jun 2008 10:26:38 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Jun 2008 10:26:38 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Jun 2008 10:26:37 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 06:36:55 -0400 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0034_01C8CD1F.DA0F3890" Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjM4R2FGr+XJh/aR3icrE8p2IycgQACdOqgAAQzQhAAEVhCQA== References: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , "Max Pritikin (pritikin)" Cc: "Tim Polk" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C8CD1F.DA0F3890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bob, If basic constraints is absent or false, a certificate is not a CA certificate. The problem comes in with trust anchors. Any requirements to process trust anchors is a change in the standard and raises backward compatibility issues. -----Original Message----- From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] Sent: Thursday, June 12, 2008 10:21 PM To: Santosh Chokhani; Max Pritikin (pritikin) Cc: Tim Polk; ietf-pkix@imc.org Subject: RE: RFC 5280 Question Santosh - I would recommend that the definition be broadened slightly to indicate that regardless of whether basic constraints are present (as long as the CA bit is false or non-existent), and that the keyCertSign bit is false. This, at least as I read the definitions, defines the cert as an end-entity cert. That kind of a cert in the trust store is what is causing problems for me. Bob > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani > Sent: Thursday, 12 June, 2008 18:21 > To: Max Pritikin (pritikin) > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > > Max, > > So, are you saying that you wanted to explore the implication > of a self-signed certificate that does not have basic > constraints extension in it and does not set keyCertSign bit > in the key usage? I ask because that is the certificate Bob sent me. > > Please provide a clear, concise and complete description of > your issues so that we have the same point of reference for > discussions. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Thursday, June 12, 2008 7:07 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > I think Bob's question touched on an important issue. The > inclusion of > self-signed or EE certificates into the certificate store. > > For an example one should experiment with how the various major web > browsers handle "trust this certificate" (sometimes called > "trust this > web page" etc). They all do it differently. > > - max > > On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: > > > > > Max, > > > > I do not understand from your posting what the specific concern or > > issue > > you want to bring to the attention of PKIX. > > > > We have had lot of digressions on this topic. > > > > Please restate what your concerns are. > > > > -----Original Message----- > > From: max pritikin [mailto:pritikin@cisco.com] > > Sent: Tuesday, June 10, 2008 11:11 PM > > To: Santosh Chokhani > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > Subject: Re: RFC 5280 Question > > > > > > I'm not sure what Bob's goals are, perhaps just to ask the question. > > We don't work very closely together. > > > > This just struck a note with me because I've seen it raised as a > > problem in other cases as well. > > > > - max > > > > On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > > >> > >> Max, > >> > >> I am just responding to inaccuracies in what you are saying. > >> > >> Can you and Bob tell me why you started this thread and > what you are > >> seeking from the PKIX community? > >> > >> I for sure am clueless except for pointing out inaccuracies in your > >> assertions and/or conclusions. > >> > >> -----Original Message----- > >> From: max pritikin [mailto:pritikin@cisco.com] > >> Sent: Tuesday, June 10, 2008 6:51 PM > >> To: Santosh Chokhani > >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >> Subject: Re: RFC 5280 Question > >> > >> > >> Santosh, you've moved the conversation back to a discussion of item > >> (3) in my comments below: out-of-scope population of the trust > >> anchors. I think this is orthogonal to a discussion of dealing with > >> trust-anchors that exactly match a single certificate being > >> validated. > >> > >> - max > >> > >> > >> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > >> > >>> > >>> Max, > >>> > >>> I do not have any problem with successfully verifying > signature made > >>> by > >>> a trust anchor. > >>> > >>> As I said a day or two back in this chain, if the relying > party who > >>> installs the certificate as a trust anchor and does not make > >>> additional > >>> checks of basic constraints, is susceptible to undetected > compromise > >>> of > >>> this end entity certificate spawning an entire PKI hierarchy. > >>> > >>> -----Original Message----- > >>> From: max pritikin [mailto:pritikin@cisco.com] > >>> Sent: Tuesday, June 10, 2008 6:17 PM > >>> To: Santosh Chokhani > >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >>> Subject: Re: RFC 5280 Question > >>> > >>> > >>> We're into the realm of discussing _how_ one would modify > >>> Certificate > >>> Path Validation to support EE certificates as a trust > anchor where > >>> my > >>> intention was only to support the concept as a discussion point. > >>> > >>> Santosh, it isn't that the constraints/extensions are > ever applied > >>> to > >>> the trust anchor credential itself. It is that they are > applied when > >>> validating the chain. Take for example Name Constraints or Policy > >>> Constraints or other Basic Constraints fields such as > >>> pathLenConstraint which are all in the trust anchor > certificate and > >>> then taken into account when validating a certificate > chain. If the > >>> trust anchor certificate does not have keyCertSign set then > >>> logically > >>> no 'chained' certificates would be valid; just like if the > >>> pathLenConstraint was '1' but the chain being verified has a path > >>> length of something greater. > >>> > >>> I think this question of EE cert vs CA cert as a trust anchor is > >>> about > >>> what should happen if the chain being validated consists > of only the > >>> trust anchor. Independent of any questions concerning key usage, > >>> constraints or anything else. > >>> > >>> - max > >>> > >>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > >>> > >>>> > >>>> Max, > >>>> > >>>> The text you cite does not apply to trust anchor. > Please see X.509 > >>>> and > >>>> RFC 5280 path validation text. Nothing needs to be > verified from a > >>>> trust anchor. > >>>> > >>>> -----Original Message----- > >>>> From: max pritikin [mailto:pritikin@cisco.com] > >>>> Sent: Tuesday, June 10, 2008 4:47 PM > >>>> To: Santosh Chokhani > >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >>>> Subject: Re: RFC 5280 Question > >>>> > >>>> > >>>> Santosh, > >>>> > >>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: > >>>>> The cA boolean indicates whether the certified public key may be > >>>>> used > >>>>> to verify certificate signatures. If the cA boolean is not > >>>>> asserted, > >>>>> then the keyCertSign bit in the key usage extension MUST NOT be > >>>>> asserted. If the basic constraints extension is not > present in a > >>>>> version 3 certificate, or the extension is present but the cA > >>>>> boolean > >>>>> is not asserted, then the certified public key MUST NOT > be used to > >>>>> verify certificate signatures. > >>>> > >>>> An EE certificate being in the trust store would not cause > >>>> confusion > >>>> about this. > >>>> > >>>> - max > >>>> > >>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > >>>> > >>>>> Max, > >>>>> > >>>>> I do not agree with your point on item 2. Once a > certificate is a > >>>>> trust > >>>>> anchor, neither X.509 not 5280 have any constraints on it from > >>>>> being a > >>>>> issuer. > >>>>> > >>>>> Furthermore, path length constraint if present in the > self-signed > >>>>> certificate can be ignored by relying parties. > >>>>> > >>>>> -----Original Message----- > >>>>> From: owner-ietf-pkix@mail.imc.org > >>>> [mailto:owner-ietf-pkix@mail.imc.org > >>>>> ] > >>>>> On Behalf Of max pritikin > >>>>> Sent: Tuesday, June 10, 2008 2:35 PM > >>>>> To: Tim Polk > >>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org > >>>>> Subject: Re: RFC 5280 Question > >>>>> > >>>>> > >>>>> > >>>>> A few comments on this thread: > >>>>> > >>>>> 1) Any entry in the trust anchor store would seem to be > "directly > >>>>> trusted". If so an additional flag isn't needed so much as a > >>>>> statement > >>>>> about how path validation proceeds if, during path discovery, it > >>>>> turns > >>>>> out the certificate being validated is already directly trusted. > >>>>> > >>>>> 2) Inclusion into the trust anchor store doesn't imply that a > >>>>> cert > >>>>> is > >>>>> trusted to issue certificates -- that is directly > controlled by > >>>>> the > >>>>> values within the certificate (chain). > >>>>> > >>>>> 3) The out-of-band mechanism is out of scope for > 5280/3280 but has > >>>>> been the subject of recent BoF work (and more?). It > would nice if > >>>>> that > >>>>> work also addressed this question. > >>>>> > >>>>> Issues related to this come up on a regular basis. Look at the > >>>>> various > >>>>> ways browser deal with caching EE certificates to > "trust this site > >>>>> always" etc. I think Bob has raised a good point. > >>>>> > >>>>> - max > >>>>> > >>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > >>>>> > >>>>>> > >>>>>> Bob, > >>>>>> > >>>>>> [I realize I am late to the party, and that Santosh, Steve, and > >>>>>> Wen- > >>>>>> Chen Wang have already provided a lot of good feedback. I > >>>>>> decided > >>>>>> to respond to the original message because I would like to go > >>>>>> back > >>>>>> to the perceived requirement.] > >>>>>> > >>>>>> It sounds like you want to construct a list of > directly trusted > >>>>>> EE > >>>>>> certificates, but are trying to satisfy this > requirement using > >>>>>> the > >>>>>> application's trust anchor store. There is nothing inherently > >>>>>> wrong > >>>>>> with direct trust (and RFC 5280 does not preclude directly > >>>>>> trusting > >>>>>> an EE certificate), but you really need a different - and far > >>>>>> simpler - mechanism. The trust anchor store is > implicitly linked > >>>>>> to > >>>>>> path discovery and validation, which are not relevant here > >>>>>> since a > >>>>>> directly trusted certificate cannot be validated. With a > >>>>>> directly > >>>>>> trusted certificate, there is also no mechanism to validate > >>>>>> status > >>>>>> information. > >>>>>> > >>>>>> To further complicate matters, storing the certificate > you wish > >>>>>> to > >>>>>> directly trust in the trust anchor store implies that it is > >>>>>> trusted > >>>>>> to issue certificates as well. The path validation inputs > >>>>>> specified > >>>>>> in 6.1.1 (d) consider only four aspects of a trust > anchor (name, > >>>>>> public key algorithm, public key, and parameters if > needed). The > >>>>>> assumption is that the trust anchor's authority to issue > >>>>>> certificates was verified based on an out-of-band > trust mechanism > >>>>>> (which is out of scope for 5280). This makes sense > since a trust > >>>>>> anchor might have distributed a v1 certificate (which does not > >>>>>> include extensions). > >>>>>> > >>>>>> As others have noted, direct trust also implies an out-of-band > >>>>>> trust > >>>>>> mechanism. I received the EE certificate from a trusted source > >>>>>> so I > >>>>>> can trust the binding between the subject name and the key; > >>>>>> issuer > >>>>>> name and the signature are irrelevant. If the certificate > >>>>>> status > >>>>>> matters, I am also depending on an out-of-band mechanism to > >>>>>> inform > >>>>>> me! The out-of-band mechanism(s) in combination with protected > >>>>>> local storage provide the basis for security in this system... > >>>>>> > >>>>>> Trying to combine these two mechanisms using a single > certificate > >>>>>> store probably requires an additional flag on every entry to > >>>>>> differentiate between directly trusted certificates and trust > >>>>>> anchors. Two separate stores might be cleaner in the long run. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Tim Polk > >>>>>> > >>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > >>>>>> > >>>>>>> Folks- > >>>>>>> > >>>>>>> I am hoping someone can give me the answer to this. Does RFC > >>>>>>> 5280 > >>>>>>> adress the case where an end-entity certificate (not > a CA cert) > >>>>>>> is > >>>>>>> installed in the trust anchor list by the user accepting the > >>>>>>> presented cert as authoritative and then the cert is > >>>>>>> subsequently > >>>>>>> presented (in a later access to the site). There should be no > >>>>>>> path > >>>>>>> search, since the presented cert is in the trust > anchor list. > >>>>>>> So, > >>>>>>> where is it defined to accept the end-entity cert? > >>>>>>> > >>>>>>> Thanks ---- Bob > >>>>>>> > >>>>>>> Bob Bell > >>>>>>> Cisco Systems, Inc. > >>>>>>> 576 S. Brentwood Ln. > >>>>>>> Bountiful, UT 84010 > >>>>>>> 801-294-3034 (v) > >>>>>>> 801-294-3023 (f) > >>>>>>> 801-971-4200 (c) > >>>>>>> rtbell@cisco.com > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > ------=_NextPart_000_0034_01C8CD1F.DA0F3890 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCCA60w ggKVoAMCAQICBECEF1YwDQYJKoZIhvcNAQEFBQAwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5 Z25hY29tMB4XDTA0MDQxOTE3NDYwMVoXDTI0MDQxOTE4MTYwMVowIDELMAkGA1UEBhMCdXMxETAP BgNVBAoTCGN5Z25hY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuw8jjNSH/3qx UShITC4+vYJG8TZsE2f4pbGUhcXe+v0PChxtWvVpOAVqXm/7y1hdBKKMjdg98Xo/jmVtFPGlKXhV v9FYyK1zxydN1YgEjRzmuSd9RNNm9YL2rgg2Q/TtT3hDwDiT4rj62ukIKYTlZHNLm1t7uYa8K/44 F5jJvo6zPkWtRqrKBFJfBblKFaPteEXU5JIKX8cbwIF3HJx9+P15S0wRngCKb0+1/d9pIuwS4Frg 1R98hG+jRXiS8klB6TncucWH2w1OqYouzUGSncb+o+EVx4PHwsE7kKxIMAsQC6zbHsAS0CAOb6hw JW7P+dtaR/9Gi8NdKsgkFlQjbQIDAQABo4HuMIHrMEIGA1UdHwQ7MDkwN6A1oDOkMTAvMQswCQYD VQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20xDTALBgNVBAMTBENSTDEwKwYDVR0QBCQwIoAPMjAw NDA0MTkxNzQ2MDFagQ8yMDI0MDQxOTE4MTYwMVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFHqT o3DI3p2/kOS+O6DeN/DUalp5MB0GA1UdDgQWBBR6k6NwyN6dv5Dkvjug3jfw1GpaeTAMBgNVHRME BTADAQH/MB0GCSqGSIb2fQdBAAQQMA4bCFY3LjA6NC4wAwIEkDANBgkqhkiG9w0BAQUFAAOCAQEA aHtrFA6rDnATj2GxfNuRLFVrsWBLSCYUdMs6YbssKI2f/Fh/o382eAnvvcpI76koLijn4Cbj482A tkWgw6hOhgESamFWaY951O0nUrk43KG5Nv4KQjXiNArFwf1ATEtB6KTeiaffh2vVbUWodZ+uwnTh X6ZlPmVooWFcB9NH+9GteR7zIJA/Eq0p0CHiCozIhOp1QGJ2cXTtHQk4Cq+sYh8du6ry0xRB3b5Z Jw/iewtxAoge2e/vh0f46mgrSdmCuPzjVLvyLg63ktN9hJe8Iiy4JiKqplnsMGizW2lxKwl/Ys0L alsltxYuLF1jytrzGJEit+5acGcjhdhijL0IojCCA7cwggKfoAMCAQICBECEfaYwDQYJKoZIhvcN AQEFBQAwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tMB4XDTA4MDIwNDE5MzE1N1oX DTExMDIwNDIwMDE1N1owOzELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tMRkwFwYDVQQD ExBTYW50b3NoIENob2toYW5pMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs9o3aeGJ DZDK4g4sEFFK6w+OkEcGHDQjYRCIuqh7uC3mVnPAk3lyUaRoVXJtZw3w8kD0XVbSH86u090X60cP zAtgW4irh9vEKQ/B2ze/D9DHjNp6y5t3Eq/LyPYLPFFivWfccVygX0ufdgJ37z2lXZhg+mVIms48 PxBOtRWGH66wNc75+NkmpRDgi4byKUOKcfy8Fm52lUrnN4GEuv/fFBSBQAWdbafCHbuDJp/KZMEX lEqnQ1GemkuAbMmj37dcP5Vw57UQlF2LILXswfmTH2JQdqTXz635HlPfJQS9yuX/MP+upkPGRToy RMFrufttu7M3mmPofNW7kFgT0jL+eQIDAQABo4HdMIHaMCEGA1UdEQQaMBiBFnNjaG9raGFuaUBj eWduYWNvbS5jb20wQgYDVR0fBDswOTA3oDWgM6QxMC8xCzAJBgNVBAYTAnVzMREwDwYDVQQKEwhj eWduYWNvbTENMAsGA1UEAxMEQ1JMMTALBgNVHQ8EBAMCBSAwHwYDVR0jBBgwFoAUepOjcMjenb+Q 5L47oN438NRqWnkwHQYDVR0OBBYEFN3Oy0J5Tcq3swE9ftXJsWLGkP/RMAkGA1UdEwQCMAAwGQYJ KoZIhvZ9B0EABAwwChsEVjcuMAMCBJAwDQYJKoZIhvcNAQEFBQADggEBABhU71iFvfdyRs+fo+it Pum3CUTu4aufARo9Rva+r/fmeBFyFc/jryqFtqoqS17dATYAgjr/7Yk12g72o4TsKN5ganteAM2r r61E5+4h2ucGHLfWykqZtKg2w84n5wbIGXG6PgAaFxk9KwbQEhcHKGRESN9HszXdonYBjMwQLqb2 VSzP+PDD0ACSHPlaL4KdaQ+pnUtdmHpTK1Yr0HoxQ6vc8xXdKQvFV6xmrAJBDGFkHf5INrkSBMhP W1xf+ogv94VptXt0DLW06mhvkp3sniARXFFWKFfPxqsLAsmR2c/uJfr4zjSi4t2h6L41NgeM5+AN ezuwuorXARAk+uaOC5MwggPmMIICzqADAgECAgRAhH2oMA0GCSqGSIb3DQEBBQUAMCAxCzAJBgNV BAYTAnVzMREwDwYDVQQKEwhjeWduYWNvbTAeFw0wODAyMDQxOTM1NTlaFw0xMTAyMDQyMDA1NTla MDsxCzAJBgNVBAYTAnVzMREwDwYDVQQKEwhjeWduYWNvbTEZMBcGA1UEAxMQU2FudG9zaCBDaG9r aGFuaTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ1rEVGyPcyt6QIby/uVXD9cMpBF wYLQjOM6dNXMzQIEUXRtcT0W8tC41xHPKyFLWAp9FYz6S8bLV59/M0+yi+fTRFvz0Nzpp8Gl4XZD xE5oucsywODMnZUnPyEjasL6v02CDu5Q4MEGNu0Wg1VeryppZrK2IZ0BEwK1Of2bgLWkPfbJuflS 9QOAMwKhSpJ6rb1o8WCqms6CC3Y9hf3HG7yYfc8k7gievsnZhSUWTOChPul963Q4qLxvC6MDxF2O kM+bnGW5WY7EpneZAsM8K/B/8VTg8YnBcQJdVrhQkoBMhJc7m3YPU3zGFpjhjzWDL3nHsxSSw85O QI52kMxU1J0CAwEAAaOCAQswggEHMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDA4MDIwNDE5 MzU1OVqBDzIwMTAwMzEzMDAwNTU5WjAhBgNVHREEGjAYgRZzY2hva2hhbmlAY3lnbmFjb20uY29t MEIGA1UdHwQ7MDkwN6A1oDOkMTAvMQswCQYDVQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20xDTAL BgNVBAMTBENSTDEwHwYDVR0jBBgwFoAUepOjcMjenb+Q5L47oN438NRqWnkwHQYDVR0OBBYEFMpd jcqM0dS0T98qfQfCqOQmoEhLMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMAMCBLAw DQYJKoZIhvcNAQEFBQADggEBAA/ZNrruYd642E8uMJ1EIDbQNsbPuNO7KXZpTcRT9DxntFCfMFkR hnIZDETqQaIVtCCMRd0kOk+rf8PCYhyqybY0S/fovU3zW3LIVLICCN01CgUpQwejJxVsGFBVPdtK AwOHneG99t6Etr2NuWCGKR6Z4pRtYjLsI80NoZz8pC5WnjFuClbse5S/PQ1L9PhdLTS/xk2bn/Rx +wYMamRki4Ec6Wgu47ud3JfmNhrmmN5TuGocHG7XwS6JtXb3wG0qcXlzg8sNlqk1doswxsMTQHUt eqK8JASKjmkIl5MusXaZRvSD6DJQzkQxpJeEujTsUrPUtCHVHoYmQGKseTEc8CkxggKNMIICiQIB ATAoMCAxCzAJBgNVBAYTAnVzMREwDwYDVQQKEwhjeWduYWNvbQIEQIR9qDAJBgUrDgMCGgUAoIIB OjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MTMxMDM2NDZa MCMGCSqGSIb3DQEJBDEWBBRyWpM0QzCxpNvt6n7asY9OCWWffzA3BgkrBgEEAYI3EAQxKjAoMCAx CzAJBgNVBAYTAnVzMREwDwYDVQQKEwhjeWduYWNvbQIEQIR9pjA5BgsqhkiG9w0BCRACCzEqoCgw IDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tAgRAhH2mMGcGCSqGSIb3DQEJDzFaMFgw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAB78wXuLV7x2 mNUW3wFO9Ga8hSTgTy64EwvEVWHtYfj21rTRJuD7ldaxPecp6hH2fMVRb7mPA5Fuqu8njtAOmO4r 0U9i7ynxSES9/zId4aR516SPyLIsiUtFSfxRkU09lTgDnSbGhmf8aKxxWMWShByr6Q5iQFGX6WYS YJ4FARrX7Xqs+HGxy25aqnp6k/dpebSC/kEY3fpGkT26pT8ro02Z1EISRsJO1YQIPLIJjkxYOarB RGUQTvyPsJ5VoXRMgVsyZi0ij8LGjYVJ4jTsnjoaGLCpCsTneinOgILHK8b4Lu9RRX6S7LtWXKTm 83ba4wkxPTJNpaXeo5wvJajQGZIAAAAAAAA= ------=_NextPart_000_0034_01C8CD1F.DA0F3890-- From owner-ietf-pkix@mail.imc.org Fri Jun 13 04:42:13 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1545F3A67F4 for ; Fri, 13 Jun 2008 04:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwn5VSVP-5YF for ; Fri, 13 Jun 2008 04:42:12 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id CC7123A63CB for ; Fri, 13 Jun 2008 04:42:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DAtBJK042183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 03:55:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DAtBJ6042182; Fri, 13 Jun 2008 03:55:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5DAt9QX042165 for ; Fri, 13 Jun 2008 03:55:10 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 2193 invoked from network); 13 Jun 2008 10:44:51 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Jun 2008 10:44:51 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Jun 2008 10:44:50 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 06:55:08 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjNQ48rVMCZ7gAGTDW/c9JnYbl/+QAAEVXw References: From: "Santosh Chokhani" To: "pgut001" , Cc: , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: So you agree that standard does not require it and changing it is a change in standard. And assuming that clients check it, is risky albeit many may check. -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Friday, June 13, 2008 6:52 AM To: pritikin@cisco.com; Santosh Chokhani Cc: ietf-pkix@imc.org; rtbell@cisco.com; tim.polk@nist.gov Subject: RE: RFC 5280 Question "Santosh Chokhani" writes: >The text you cite does not apply to trust anchor. Please see X.509 and RFC >5280 path validation text. Nothing needs to be verified from a trust anchor. Right, but when I checked about two years ago a significant number of PKI=20 implementors weren't even aware that this crazy requirement exists, let alone=20 implemented it in their code (when alerted to the requirement, several said=20 they would explicitly not implement it because it constituted broken behaviour=20 and they didn't want to deal with the customer support issues). The only=20 reason I know it exists was because someone on the X.509 standards committee=20 told me about it. I asked for a reference, because I couldn't believe that=20 explicitly ignoring everything in a root cert was required by the standard,=20 and they said they'd get back to me. Two weeks later they'd managed to find=20 it in the spec, and this was one of the people responsible for writing it! So in general proceeding under the assumption that many (most?)=20 implementations aren't going to do ignore checking of root certs/trust anchors=20 is safe. Or if you want to be strict about it, proceeding under the=20 assumption that whether an implementation checks or not is pretty much a coin-toss is safe. Peter. From owner-ietf-pkix@mail.imc.org Fri Jun 13 04:53:12 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFFE3A693A for ; Fri, 13 Jun 2008 04:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buhDlsDIfyVW for ; Fri, 13 Jun 2008 04:53:11 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 585323A6810 for ; Fri, 13 Jun 2008 04:53:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DAqMoP041907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 03:52:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DAqMJC041906; Fri, 13 Jun 2008 03:52:22 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DAqJsE041899 for ; Fri, 13 Jun 2008 03:52:22 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0A1FE9C60C; Fri, 13 Jun 2008 22:52:10 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKqaKyEjUcrk; Fri, 13 Jun 2008 22:52:09 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EF6239C5FB; Fri, 13 Jun 2008 22:52:08 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id DE47F19EC0BA; Fri, 13 Jun 2008 22:52:01 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1K76sz-00084o-Pz; Fri, 13 Jun 2008 22:52:01 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pritikin@cisco.com, SChokhani@cygnacom.com Subject: RE: RFC 5280 Question Cc: ietf-pkix@imc.org, rtbell@cisco.com, tim.polk@nist.gov In-Reply-To: Message-Id: Date: Fri, 13 Jun 2008 22:52:01 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Santosh Chokhani" writes: >The text you cite does not apply to trust anchor. Please see X.509 and RFC >5280 path validation text. Nothing needs to be verified from a trust anchor. Right, but when I checked about two years ago a significant number of PKI implementors weren't even aware that this crazy requirement exists, let alone implemented it in their code (when alerted to the requirement, several said they would explicitly not implement it because it constituted broken behaviour and they didn't want to deal with the customer support issues). The only reason I know it exists was because someone on the X.509 standards committee told me about it. I asked for a reference, because I couldn't believe that explicitly ignoring everything in a root cert was required by the standard, and they said they'd get back to me. Two weeks later they'd managed to find it in the spec, and this was one of the people responsible for writing it! So in general proceeding under the assumption that many (most?) implementations aren't going to do ignore checking of root certs/trust anchors is safe. Or if you want to be strict about it, proceeding under the assumption that whether an implementation checks or not is pretty much a coin-toss is safe. Peter. From owner-ietf-pkix@mail.imc.org Fri Jun 13 05:27:42 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150113A698B for ; Fri, 13 Jun 2008 05:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+xShGzID6DT for ; Fri, 13 Jun 2008 05:27:41 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DBCA33A63CB for ; Fri, 13 Jun 2008 05:27:40 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DBaHrR050453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 04:36:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DBaHB6050452; Fri, 13 Jun 2008 04:36:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DBaG0M050437 for ; Fri, 13 Jun 2008 04:36:16 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 91E814809AB; Fri, 13 Jun 2008 23:36:15 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSgHAlefXh2h; Fri, 13 Jun 2008 23:36:15 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2DF974809A8; Fri, 13 Jun 2008 23:36:15 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id A6AF019EC0BA; Fri, 13 Jun 2008 23:36:08 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1K77Zg-0001qr-HN; Fri, 13 Jun 2008 23:36:08 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, pritikin@cisco.com, SChokhani@cygnacom.com Subject: RE: RFC 5280 Question Cc: ietf-pkix@imc.org, rtbell@cisco.com, tim.polk@nist.gov In-Reply-To: Message-Id: Date: Fri, 13 Jun 2008 23:36:08 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Santosh Chokhani" writes: >So you agree that standard does not require it and changing it is a change in >standard. I was told by the X.509 person that the standard does require it, and from the text they forwarded me I would agree that it does. OTOH it doesn't make any sense for the standard to require it, and it seems to (from my informal survey) do the complete opposite of what customers expect. In other words it violates the principle of least surprise. >And assuming that clients check it, is risky albeit many may check. Again, from an informal survey I'd say that the majority don't check, and that the developers of the apps don't even know of this requirement. In my case I do know of it but since the response from users about whether they wanted (or would ever expect) this behaviour was 100% negative, I explicitly don't implement it. Peter. From owner-ietf-pkix@mail.imc.org Fri Jun 13 06:21:31 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CD43A682F for ; Fri, 13 Jun 2008 06:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFPhp4NfcjxW for ; Fri, 13 Jun 2008 06:21:25 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 613173A67B3 for ; Fri, 13 Jun 2008 06:21:25 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DBdmmi051212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 04:39:48 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DBdm53051211; Fri, 13 Jun 2008 04:39:48 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5DBdkkj051198 for ; Fri, 13 Jun 2008 04:39:47 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 2452 invoked from network); 13 Jun 2008 11:29:27 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Jun 2008 11:29:27 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Jun 2008 11:29:27 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 07:39:45 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjNSbJckqAY98ZpRRWG76P16dRz0QAAEsjg References: From: "Santosh Chokhani" To: "pgut001" , Cc: , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Are you saying that the standard requires you to check and enforce constraints in a trust anchor which is a self-signed X.509 certificate? -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Friday, June 13, 2008 7:36 AM To: pgut001@cs.auckland.ac.nz; pritikin@cisco.com; Santosh Chokhani Cc: ietf-pkix@imc.org; rtbell@cisco.com; tim.polk@nist.gov Subject: RE: RFC 5280 Question "Santosh Chokhani" writes: >So you agree that standard does not require it and changing it is a change in >standard. I was told by the X.509 person that the standard does require it, and from the=20 text they forwarded me I would agree that it does. OTOH it doesn't make any=20 sense for the standard to require it, and it seems to (from my informal=20 survey) do the complete opposite of what customers expect. In other words it=20 violates the principle of least surprise. >And assuming that clients check it, is risky albeit many may check. Again, from an informal survey I'd say that the majority don't check, and that the developers of the apps don't even know of this requirement. In my case I do know of it but since the response from users about whether they wanted (or would ever expect) this behaviour was 100% negative, I explicitly don't implement it. Peter. From owner-ietf-pkix@mail.imc.org Fri Jun 13 07:10:53 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E5E3A68CF for ; Fri, 13 Jun 2008 07:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbySPV8qx9Ue for ; Fri, 13 Jun 2008 07:10:52 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 312D13A6883 for ; Fri, 13 Jun 2008 07:10:51 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DDSpXr073447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 06:28:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DDSpuu073446; Fri, 13 Jun 2008 06:28:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5DDSnOO073431 for ; Fri, 13 Jun 2008 06:28:50 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 3263 invoked from network); 13 Jun 2008 13:18:30 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Jun 2008 13:18:30 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Jun 2008 13:18:30 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 09:28:48 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjNUnn99vETX4vJSAmOfi3qJ34J7AABsZiA References: From: "Santosh Chokhani" To: "pgut001" , Cc: , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We agree on the standard's required behavior, which has been the focus of my posts in this thread. -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Friday, June 13, 2008 8:39 AM To: pgut001@cs.auckland.ac.nz; pritikin@cisco.com; Santosh Chokhani Cc: ietf-pkix@imc.org; rtbell@cisco.com; tim.polk@nist.gov Subject: RE: RFC 5280 Question SChokhani@cygnacom.com writes: >Are you saying that the standard requires you to check and enforce >constraints in a trust anchor which is a self-signed X.509 certificate? No, the standard requires that you not check trust anchors. This is completely contrary to what users (and implementors) seem to expect. Peter. From owner-ietf-pkix@mail.imc.org Fri Jun 13 07:19:55 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D867C3A6883 for ; Fri, 13 Jun 2008 07:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcAIgENsHmfC for ; Fri, 13 Jun 2008 07:19:54 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 664FF3A68AF for ; Fri, 13 Jun 2008 07:19:54 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DCdA9V064173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 05:39:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DCdA5g064171; Fri, 13 Jun 2008 05:39:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DCd8l1064142 for ; Fri, 13 Jun 2008 05:39:09 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2BA289C5BE; Sat, 14 Jun 2008 00:39:08 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSngzkJThewf; Sat, 14 Jun 2008 00:39:08 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7A78E9C5BC; Sat, 14 Jun 2008 00:39:07 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id F31D919EC0BA; Sat, 14 Jun 2008 00:39:02 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1K78YY-0004kk-Rp; Sat, 14 Jun 2008 00:39:02 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, pritikin@cisco.com, SChokhani@cygnacom.com Subject: RE: RFC 5280 Question Cc: ietf-pkix@imc.org, rtbell@cisco.com, tim.polk@nist.gov In-Reply-To: Message-Id: Date: Sat, 14 Jun 2008 00:39:02 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: SChokhani@cygnacom.com writes: >Are you saying that the standard requires you to check and enforce >constraints in a trust anchor which is a self-signed X.509 certificate? No, the standard requires that you not check trust anchors. This is completely contrary to what users (and implementors) seem to expect. Peter. From owner-ietf-pkix@mail.imc.org Fri Jun 13 07:42:15 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8233A6817 for ; Fri, 13 Jun 2008 07:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrmtToMJXroW for ; Fri, 13 Jun 2008 07:42:14 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3DBF73A680B for ; Fri, 13 Jun 2008 07:42:13 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DE2lxb079281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 07:02:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DE2lCN079280; Fri, 13 Jun 2008 07:02:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DE2kwA079265 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 13 Jun 2008 07:02:46 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,638,1204531200"; d="p7s'?scan'208";a="56697871" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 13 Jun 2008 07:02:44 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5DE2iIe022558; Fri, 13 Jun 2008 07:02:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5DE2i5p005962; Fri, 13 Jun 2008 14:02:44 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 07:02:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 07:02:39 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000D_01C8CD2B.D95540F0" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjM4R2FGr+XJh/aR3icrE8p2IycgQACdOqgAAQzQhAAEVhCQAAHF8BA References: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , "Max Pritikin (pritikin)" Cc: "Tim Polk" , X-OriginalArrivalTime: 13 Jun 2008 14:02:44.0349 (UTC) FILETIME=[26E91AD0:01C8CD5E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19706; t=1213365764; x=1214229764; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=mzHWFQEhcVTROb58tGxYSv7g36wK04d5ltaveasniQ4=; b=HvPLmHfEejf3OeA+S/M9WnMPtGbjwGv3kjk812hiT+U7DbvGq/jCrsx6/w 58V6EKKZQWwmoQa0HZoGJuB4gyfo1B1MlkpdrLIYPykLd+9zc3S6mHyv2BiX w43DaSZcj6; Authentication-Results: sj-dkim-4; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C8CD2B.D95540F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - The only thing I was referring to in verifying the basic constraints was to limit the use of the certificate if the basic constraint CA bit was false and/or the keyCertSign bit was false. In these cases, you cannot use the certificate to validate another certificate. It does not prevent you from validating itself. On the other hand, it was never my intent to cause this much controversy. My original intent was to try to determine which of the interpretations that I and another engineer had concerning 5280 was correct or if they both were flawed. I think I got my answer to that question. I appreciate all of the comments that others have made. Bob > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani > Sent: Friday, 13 June, 2008 04:37 > To: Bob Bell (rtbell); Max Pritikin (pritikin) > Cc: Tim Polk; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Bob, > > If basic constraints is absent or false, a certificate is not > a CA certificate. > > The problem comes in with trust anchors. Any requirements to > process trust anchors is a change in the standard and raises > backward compatibility issues. > > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Thursday, June 12, 2008 10:21 PM > To: Santosh Chokhani; Max Pritikin (pritikin) > Cc: Tim Polk; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Santosh - > > I would recommend that the definition be broadened slightly > to indicate that regardless of whether basic constraints are > present (as long as the CA bit is false or non-existent), and > that the keyCertSign bit is false. This, at least as I read > the definitions, defines the cert as an end-entity cert. > That kind of a cert in the trust store is what is causing > problems for me. > > Bob > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani > > Sent: Thursday, 12 June, 2008 18:21 > > To: Max Pritikin (pritikin) > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > > > > > > Max, > > > > So, are you saying that you wanted to explore the implication of a > > self-signed certificate that does not have basic > constraints extension > > in it and does not set keyCertSign bit in the key usage? I ask > > because that is the certificate Bob sent me. > > > > Please provide a clear, concise and complete description of your > > issues so that we have the same point of reference for discussions. > > > > -----Original Message----- > > From: max pritikin [mailto:pritikin@cisco.com] > > Sent: Thursday, June 12, 2008 7:07 PM > > To: Santosh Chokhani > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > Subject: Re: RFC 5280 Question > > > > > > I think Bob's question touched on an important issue. The > inclusion of > > self-signed or EE certificates into the certificate store. > > > > For an example one should experiment with how the various major web > > browsers handle "trust this certificate" (sometimes called > "trust this > > web page" etc). They all do it differently. > > > > - max > > > > On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: > > > > > > > > Max, > > > > > > I do not understand from your posting what the specific > concern or > > > issue you want to bring to the attention of PKIX. > > > > > > We have had lot of digressions on this topic. > > > > > > Please restate what your concerns are. > > > > > > -----Original Message----- > > > From: max pritikin [mailto:pritikin@cisco.com] > > > Sent: Tuesday, June 10, 2008 11:11 PM > > > To: Santosh Chokhani > > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > > Subject: Re: RFC 5280 Question > > > > > > > > > I'm not sure what Bob's goals are, perhaps just to ask > the question. > > > We don't work very closely together. > > > > > > This just struck a note with me because I've seen it raised as a > > > problem in other cases as well. > > > > > > - max > > > > > > On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > > > > >> > > >> Max, > > >> > > >> I am just responding to inaccuracies in what you are saying. > > >> > > >> Can you and Bob tell me why you started this thread and > > what you are > > >> seeking from the PKIX community? > > >> > > >> I for sure am clueless except for pointing out > inaccuracies in your > > >> assertions and/or conclusions. > > >> > > >> -----Original Message----- > > >> From: max pritikin [mailto:pritikin@cisco.com] > > >> Sent: Tuesday, June 10, 2008 6:51 PM > > >> To: Santosh Chokhani > > >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > >> Subject: Re: RFC 5280 Question > > >> > > >> > > >> Santosh, you've moved the conversation back to a > discussion of item > > >> (3) in my comments below: out-of-scope population of the trust > > >> anchors. I think this is orthogonal to a discussion of > dealing with > > >> trust-anchors that exactly match a single certificate being > > >> validated. > > >> > > >> - max > > >> > > >> > > >> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > > >> > > >>> > > >>> Max, > > >>> > > >>> I do not have any problem with successfully verifying > > signature made > > >>> by > > >>> a trust anchor. > > >>> > > >>> As I said a day or two back in this chain, if the relying > > party who > > >>> installs the certificate as a trust anchor and does not make > > >>> additional checks of basic constraints, is susceptible to > > >>> undetected > > compromise > > >>> of > > >>> this end entity certificate spawning an entire PKI hierarchy. > > >>> > > >>> -----Original Message----- > > >>> From: max pritikin [mailto:pritikin@cisco.com] > > >>> Sent: Tuesday, June 10, 2008 6:17 PM > > >>> To: Santosh Chokhani > > >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > >>> Subject: Re: RFC 5280 Question > > >>> > > >>> > > >>> We're into the realm of discussing _how_ one would modify > > >>> Certificate Path Validation to support EE certificates > as a trust > > anchor where > > >>> my > > >>> intention was only to support the concept as a discussion point. > > >>> > > >>> Santosh, it isn't that the constraints/extensions are > > ever applied > > >>> to > > >>> the trust anchor credential itself. It is that they are > > applied when > > >>> validating the chain. Take for example Name Constraints > or Policy > > >>> Constraints or other Basic Constraints fields such as > > >>> pathLenConstraint which are all in the trust anchor > > certificate and > > >>> then taken into account when validating a certificate > > chain. If the > > >>> trust anchor certificate does not have keyCertSign set then > > >>> logically no 'chained' certificates would be valid; > just like if > > >>> the pathLenConstraint was '1' but the chain being > verified has a > > >>> path length of something greater. > > >>> > > >>> I think this question of EE cert vs CA cert as a trust > anchor is > > >>> about what should happen if the chain being validated consists > > of only the > > >>> trust anchor. Independent of any questions concerning > key usage, > > >>> constraints or anything else. > > >>> > > >>> - max > > >>> > > >>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > > >>> > > >>>> > > >>>> Max, > > >>>> > > >>>> The text you cite does not apply to trust anchor. > > Please see X.509 > > >>>> and > > >>>> RFC 5280 path validation text. Nothing needs to be > > verified from a > > >>>> trust anchor. > > >>>> > > >>>> -----Original Message----- > > >>>> From: max pritikin [mailto:pritikin@cisco.com] > > >>>> Sent: Tuesday, June 10, 2008 4:47 PM > > >>>> To: Santosh Chokhani > > >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > >>>> Subject: Re: RFC 5280 Question > > >>>> > > >>>> > > >>>> Santosh, > > >>>> > > >>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: > > >>>>> The cA boolean indicates whether the certified public > key may be > > >>>>> used to verify certificate signatures. If the cA > boolean is not > > >>>>> asserted, then the keyCertSign bit in the key usage extension > > >>>>> MUST NOT be asserted. If the basic constraints > extension is not > > present in a > > >>>>> version 3 certificate, or the extension is present but the cA > > >>>>> boolean is not asserted, then the certified public > key MUST NOT > > be used to > > >>>>> verify certificate signatures. > > >>>> > > >>>> An EE certificate being in the trust store would not cause > > >>>> confusion about this. > > >>>> > > >>>> - max > > >>>> > > >>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > > >>>> > > >>>>> Max, > > >>>>> > > >>>>> I do not agree with your point on item 2. Once a > > certificate is a > > >>>>> trust > > >>>>> anchor, neither X.509 not 5280 have any constraints > on it from > > >>>>> being a issuer. > > >>>>> > > >>>>> Furthermore, path length constraint if present in the > > self-signed > > >>>>> certificate can be ignored by relying parties. > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: owner-ietf-pkix@mail.imc.org > > >>>> [mailto:owner-ietf-pkix@mail.imc.org > > >>>>> ] > > >>>>> On Behalf Of max pritikin > > >>>>> Sent: Tuesday, June 10, 2008 2:35 PM > > >>>>> To: Tim Polk > > >>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org > > >>>>> Subject: Re: RFC 5280 Question > > >>>>> > > >>>>> > > >>>>> > > >>>>> A few comments on this thread: > > >>>>> > > >>>>> 1) Any entry in the trust anchor store would seem to be > > "directly > > >>>>> trusted". If so an additional flag isn't needed so much as a > > >>>>> statement about how path validation proceeds if, during path > > >>>>> discovery, it turns out the certificate being validated is > > >>>>> already directly trusted. > > >>>>> > > >>>>> 2) Inclusion into the trust anchor store doesn't > imply that a > > >>>>> cert is trusted to issue certificates -- that is directly > > controlled by > > >>>>> the > > >>>>> values within the certificate (chain). > > >>>>> > > >>>>> 3) The out-of-band mechanism is out of scope for > > 5280/3280 but has > > >>>>> been the subject of recent BoF work (and more?). It > > would nice if > > >>>>> that > > >>>>> work also addressed this question. > > >>>>> > > >>>>> Issues related to this come up on a regular basis. > Look at the > > >>>>> various ways browser deal with caching EE certificates to > > "trust this site > > >>>>> always" etc. I think Bob has raised a good point. > > >>>>> > > >>>>> - max > > >>>>> > > >>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > > >>>>> > > >>>>>> > > >>>>>> Bob, > > >>>>>> > > >>>>>> [I realize I am late to the party, and that Santosh, > Steve, and > > >>>>>> Wen- > > >>>>>> Chen Wang have already provided a lot of good feedback. I > > >>>>>> decided to respond to the original message because I > would like > > >>>>>> to go back to the perceived requirement.] > > >>>>>> > > >>>>>> It sounds like you want to construct a list of > > directly trusted > > >>>>>> EE > > >>>>>> certificates, but are trying to satisfy this > > requirement using > > >>>>>> the > > >>>>>> application's trust anchor store. There is nothing > inherently > > >>>>>> wrong with direct trust (and RFC 5280 does not preclude > > >>>>>> directly trusting an EE certificate), but you really need a > > >>>>>> different - and far simpler - mechanism. The trust anchor > > >>>>>> store is > > implicitly linked > > >>>>>> to > > >>>>>> path discovery and validation, which are not relevant here > > >>>>>> since a directly trusted certificate cannot be > validated. With > > >>>>>> a directly trusted certificate, there is also no > mechanism to > > >>>>>> validate status information. > > >>>>>> > > >>>>>> To further complicate matters, storing the certificate > > you wish > > >>>>>> to > > >>>>>> directly trust in the trust anchor store implies that it is > > >>>>>> trusted to issue certificates as well. The path validation > > >>>>>> inputs specified in 6.1.1 (d) consider only four > aspects of a > > >>>>>> trust > > anchor (name, > > >>>>>> public key algorithm, public key, and parameters if > > needed). The > > >>>>>> assumption is that the trust anchor's authority to issue > > >>>>>> certificates was verified based on an out-of-band > > trust mechanism > > >>>>>> (which is out of scope for 5280). This makes sense > > since a trust > > >>>>>> anchor might have distributed a v1 certificate > (which does not > > >>>>>> include extensions). > > >>>>>> > > >>>>>> As others have noted, direct trust also implies an > out-of-band > > >>>>>> trust mechanism. I received the EE certificate from > a trusted > > >>>>>> source so I can trust the binding between the > subject name and > > >>>>>> the key; issuer > > >>>>>> name and the signature are irrelevant. If the certificate > > >>>>>> status > > >>>>>> matters, I am also depending on an out-of-band mechanism to > > >>>>>> inform me! The out-of-band mechanism(s) in combination with > > >>>>>> protected local storage provide the basis for > security in this > > >>>>>> system... > > >>>>>> > > >>>>>> Trying to combine these two mechanisms using a single > > certificate > > >>>>>> store probably requires an additional flag on every entry to > > >>>>>> differentiate between directly trusted certificates > and trust > > >>>>>> anchors. Two separate stores might be cleaner in > the long run. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> > > >>>>>> Tim Polk > > >>>>>> > > >>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > > >>>>>> > > >>>>>>> Folks- > > >>>>>>> > > >>>>>>> I am hoping someone can give me the answer to this. > Does RFC > > >>>>>>> 5280 adress the case where an end-entity certificate (not > > a CA cert) > > >>>>>>> is > > >>>>>>> installed in the trust anchor list by the user > accepting the > > >>>>>>> presented cert as authoritative and then the cert is > > >>>>>>> subsequently presented (in a later access to the > site). There > > >>>>>>> should be no path search, since the presented cert > is in the > > >>>>>>> trust > > anchor list. > > >>>>>>> So, > > >>>>>>> where is it defined to accept the end-entity cert? > > >>>>>>> > > >>>>>>> Thanks ---- Bob > > >>>>>>> > > >>>>>>> Bob Bell > > >>>>>>> Cisco Systems, Inc. > > >>>>>>> 576 S. Brentwood Ln. > > >>>>>>> Bountiful, UT 84010 > > >>>>>>> 801-294-3034 (v) > > >>>>>>> 801-294-3023 (f) > > >>>>>>> 801-971-4200 (c) > > >>>>>>> rtbell@cisco.com > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > > > > > ------=_NextPart_000_000D_01C8CD2B.D95540F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTMxNDAyMzlaMCMGCSqGSIb3DQEJBDEWBBTNcw0dIyKqY3YeZt2o 3s6NnbK0ezBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYAo/GyL2x66z20CSnaQzRN/6i5ssy+pEj2+HcFlTkw3JniNv06K4uXquDgb18yecFnJ6jdb LKBNhqYUqauKcAnBjDs16pI8QmzqLFgf4CQD3XT5vi87XEa1XTmqllFfEROOldZl4F1hn4VEXmhY YF3Sk+8Of/+lgU0KD9Mo2eBh6gAAAAAAAA== ------=_NextPart_000_000D_01C8CD2B.D95540F0-- From owner-ietf-pkix@mail.imc.org Fri Jun 13 08:46:18 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A373A67A4 for ; Fri, 13 Jun 2008 08:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy-ubfcGcEgp for ; Fri, 13 Jun 2008 08:46:17 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 92C313A698D for ; Fri, 13 Jun 2008 08:46:16 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DFCBJH093385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 08:12:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DFCBHS093384; Fri, 13 Jun 2008 08:12:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DFCAUc093378 for ; Fri, 13 Jun 2008 08:12:11 -0700 (MST) (envelope-from mike-list@pobox.com) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 0994D3830 for ; Fri, 13 Jun 2008 11:12:10 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id AB7DC382F for ; Fri, 13 Jun 2008 11:12:07 -0400 (EDT) Message-ID: <48528E43.4060103@pobox.com> Date: Fri, 13 Jun 2008 08:12:03 -0700 From: Mike User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: RFC 5280 Question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 181BCDB8-395B-11DD-A5E5-F9737025C2AA-38729857!a-sasl-fastnet.pobox.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Fortunately RFC 5280 says in a couple places: Some communities will need to supplement, or possibly replace, this profile in order to meet the requirements of specialized application domains or environments with additional authorization, assurance, or operational requirements. So if you want to check your trust anchors, it seems that you can -- just claim that you are part of a community. If a trust anchor certificate has extensions, what justification is there for just ignoring them? Somebody put them there, and not just for grins. Mike > We agree on the standard's required behavior, which has been the focus > of my posts in this thread. > > -----Original Message----- > From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] > Sent: Friday, June 13, 2008 8:39 AM > To: pgut001@cs.auckland.ac.nz; pritikin@cisco.com; Santosh Chokhani > Cc: ietf-pkix@imc.org; rtbell@cisco.com; tim.polk@nist.gov > Subject: RE: RFC 5280 Question > > SChokhani@cygnacom.com writes: > >> Are you saying that the standard requires you to check and enforce >> constraints in a trust anchor which is a self-signed X.509 certificate? > > No, the standard requires that you not check trust anchors. This is > completely contrary to what users (and implementors) seem to expect. > > Peter. From owner-ietf-pkix@mail.imc.org Fri Jun 13 09:54:32 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6413D3A67F5 for ; Fri, 13 Jun 2008 09:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IadIrQd+hFIE for ; Fri, 13 Jun 2008 09:54:31 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 248DB3A682D for ; Fri, 13 Jun 2008 09:54:30 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DFjcag000379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 08:45:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DFjcnU000378; Fri, 13 Jun 2008 08:45:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DFjbE9000362 for ; Fri, 13 Jun 2008 08:45:38 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1K7BT6-0001yt-5R for ietf-pkix@imc.org; Fri, 13 Jun 2008 11:45:36 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 13 Jun 2008 11:45:52 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: Re: RFC 5280 question Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, Yes, I too have been disappointed that the X.509 path validation algorithm says to not use constraints from the TA. I brought this point up on the list a few years ago, because I felt that this was especially bad in the case of name constraints. I agree that such behavior is contrary to user expectations. However, there is a relatively simple way around this that is consistent with the standards. One can extract the contents of a self-signed cert that has been provided as a TA, and issue a new cert under a TA managed locally. This could be done with minimal user effort for most folks, and advanced users could be provided with a menu that allowed more direct control over the process. Any extensions contained in this new cert (which is no longer a TA), will be used to control path validation, as specified by the X.509 and PKIX standards. I have always preferred this model for dealing with TA material, as it also allows an RP to impose constraints (via extensions) on TA material provided by an outside source, even if the source did not put such constraints into the self-signed cert it offered. Steve From owner-ietf-pkix@mail.imc.org Fri Jun 13 09:59:59 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636413A693B for ; Fri, 13 Jun 2008 09:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYRgtYeYc-8C for ; Fri, 13 Jun 2008 09:59:55 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id AC3C03A682D for ; Fri, 13 Jun 2008 09:59:54 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DGRL57007919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 09:27:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DGRLkA007918; Fri, 13 Jun 2008 09:27:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DGRJmC007912 for ; Fri, 13 Jun 2008 09:27:20 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id m5DGRJjB028277 for ; Fri, 13 Jun 2008 12:27:19 -0400 (EDT) X-AuditID: 90333308-000013cc00000188-48-48529fe72121 Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 12:27:18 -0400 Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 12:27:18 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 12:27:18 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjNUnn99vETX4vJSAmOfi3qJ34J7AABsZiAAAW+/LA= References: From: "Kemp, David P." To: X-OriginalArrivalTime: 13 Jun 2008 16:27:18.0958 (UTC) FILETIME=[596164E0:01C8CD72] X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The standard defines a trust anchor to be the four items of information needed to validate the first certificate in a chain. The fact that those items can be extracted from a certificate, and for convenience are often transmitted in the form of a self-signed certificate, confuses users into believing that a self-signed certificate is itself a trust anchor. PKIX could have (and should have) eliminated that confusion by defining an unsigned trust anchor data structure, but it's a bit late for that now. Confusion is the natural and expected result of using the same data structure to represent two semantically different objects. Dave -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Friday, June 13, 2008 9:29 AM To: pgut001; pritikin@cisco.com Cc: ietf-pkix@imc.org; rtbell@cisco.com; tim.polk@nist.gov Subject: RE: RFC 5280 Question We agree on the standard's required behavior, which has been the focus of my posts in this thread. -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Friday, June 13, 2008 8:39 AM To: pgut001@cs.auckland.ac.nz; pritikin@cisco.com; Santosh Chokhani Cc: ietf-pkix@imc.org; rtbell@cisco.com; tim.polk@nist.gov Subject: RE: RFC 5280 Question SChokhani@cygnacom.com writes: >Are you saying that the standard requires you to check and enforce >constraints in a trust anchor which is a self-signed X.509 certificate? No, the standard requires that you not check trust anchors. This is completely contrary to what users (and implementors) seem to expect. Peter. From owner-ietf-pkix@mail.imc.org Fri Jun 13 11:57:19 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490A83A6851 for ; Fri, 13 Jun 2008 11:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBhzkFVKR0B2 for ; Fri, 13 Jun 2008 11:57:18 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 93DA23A6826 for ; Fri, 13 Jun 2008 11:57:17 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DIJDTd031495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 11:19:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DIJDOr031494; Fri, 13 Jun 2008 11:19:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from helios.bolet.org (helios.bolet.org [88.191.25.203]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DIJAwG031487 for ; Fri, 13 Jun 2008 11:19:11 -0700 (MST) (envelope-from pornin@helios.bolet.org) Received: by helios.bolet.org (Postfix, from userid 1000) id 24067D986C7; Fri, 13 Jun 2008 20:19:10 +0200 (CEST) Date: Fri, 13 Jun 2008 20:19:10 +0200 From: Thomas Pornin To: ietf-pkix@imc.org Subject: Re: RFC 5280 Question Message-ID: <20080613181910.GA17653@localhost.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Jun 13, 2008 at 12:27:18PM -0400, Kemp, David P. wrote: > The standard defines a trust anchor to be the four items of information > needed to validate the first certificate in a chain. Actually, RFC 5280 does not really define what a trust anchor is. It defines the "trust anchor information", which is the set of four items which is input into the path validation algorithm. The wording of RFC 5280 seems to imply that these items are obtained from some entity called a "trust anchor", which is more alluded to than actually explained. At the end of 6.2, one may find the following two paragraphs: << An implementation MAY augment the algorithm presented in Section 6.1 to further limit the set of valid certification paths that begin with a particular trust anchor. For example, an implementation MAY modify the algorithm to apply a path length constraint to a specific trust anchor during the initialization phase, or the application MAY require the presence of a particular alternative name form in the target certificate, or the application MAY impose requirements on application-specific extensions. Thus, the path validation algorithm presented in Section 6.1 defines the minimum conditions for a path to be considered valid. Where a CA distributes self-signed certificates to specify trust anchor information, certificate extensions can be used to specify recommended inputs to path validation. For example, a policy constraints extension could be included in the self-signed certificate to indicate that paths beginning with this trust anchor should be trusted only for the specified policies. Similarly, a name constraints extension could be included to indicate that paths beginning with this trust anchor should be trusted only for the specified name spaces. The path validation algorithm presented in Section 6.1 does not assume that trust anchor information is provided in self-signed certificates and does not specify processing rules for additional information included in such certificates. Implementations that use self-signed certificates to specify trust anchor information are free to process or ignore such information. >> This somehow settles it. The trust anchor information _may_ be transfered under the guise of self-signed certificates but this is mostly out of scope of RFC 5280. However, RFC 5280 does not _mandate_ that extra information provided along the trust anchor is to be ignored. It explicitely states that implementations are free to enforce additional restrictions on certificate paths. RFC 5280 even explains that nothing prevents such information to be serialized with the trust anchor information as what usually happens to be certificate extensions. Therefore, if an application wishes to use an "augmented trust anchor" which is a set of trust anchor information together with some additional usage restrictions (e.g. maximum path length, explicit policies or name constraints) to be applied when the said trust anchor is used in path validation, then it is free to do so. Moreover, if the said application wishes to receive and/or store this augmented trust anchor as a "self-signed certificate" with the additional restrictions using the format of certificate extensions, then by all means it can, and RFC 5280 even explicitely states that it does not mind. In other words, such an implementation can still claim to be conforming to RFC 5280. Hence there is little problem here. There is a problem, however, in _other_ standard documents (not RFC 5280), such as those presenting signature validation policies. Such policies may include trust anchors, encoded as self-signed certificates. And there is no document anywhere which really defines how you should transform a self-signed certificate into a proper set of inputs for the validation algorithm. It is _customary_ to use the "subjectDN" as trust anchor name, and the "subjectPublicKeyInfo" as public key information (with key type and key parameters, when applicable). Beyond conforming to the Tradition, it is also a quite natural choice. But there is nothing which explicitely defines such usage. And when it comes to how certificate extensions present in that "self-signed certificate" must be interpreted and used, then Tradition is somewhat at a loss, and differing interpretations exist. Theoretically, CA should distribute their public keys along with a "Certificate Policy Statement" which defines (in human language) what they do and thus, indrectly, how paths originating from them as trust anchors should be validated. Human languages are fine for humans but computers are known to be quite thick and literal and often require a more easily and unambiguously decodeable representation of such information. And there is no standard on that. Even worse, there is a widespread practice of using self-signed certificates which implementors often erroneously assume to be sanctioned by RFC 5280 -- and they do not all do so in the same way, of course. Various disasters ensue. Hence the problem with self-signed certificates at trust anchors is NOT that RFC 5280 forbids implementations to use information from the self-signed certificate. To the contrary, RFC 5280 explicitely allows it. The problem is that there is a need for a standard definition of how this extended information may be used; and RFC 5280 explicitely denies having anything to say on that matter. Note that I do NOT claim that RFC 5280 should include such a definition; I merely point out that applications which use path validation often have a need which is often assumed to be fulfilled by RFC 5280, whereas in fact it is not. --Thomas Pornin From owner-ietf-pkix@mail.imc.org Fri Jun 13 14:24:17 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96F83A689E for ; Fri, 13 Jun 2008 14:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4SL0hoASB4Q for ; Fri, 13 Jun 2008 14:24:15 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B34A63A6885 for ; Fri, 13 Jun 2008 14:24:14 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DKTav0053643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 13:29:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DKTaP3053642; Fri, 13 Jun 2008 13:29:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DKTYKI053632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 13 Jun 2008 13:29:35 -0700 (MST) (envelope-from tgindin@us.ibm.com) X-VirusChecked: Checked X-Env-Sender: tgindin@us.ibm.com X-Msg-Ref: server-13.tower-87.messagelabs.com!1213388971!44596343!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 25650 invoked from network); 13 Jun 2008 20:29:32 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-13.tower-87.messagelabs.com with AES256-SHA encrypted SMTP; 13 Jun 2008 20:29:32 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id m5DKUWkp029899; Fri, 13 Jun 2008 16:30:32 -0400 In-Reply-To: <48522C3F.4050103@cryptolog.com> To: Julien Stern , Santosh Chokhani Cc: ietf-pkix@imc.org, "Max Pritikin (pritikin)" , "Bob Bell (rtbell)" , Tim Polk MIME-Version: 1.0 Subject: Re: RFC 5280 Question X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Tom Gindin Message-ID: Date: Fri, 13 Jun 2008 16:29:25 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1|February 07, 2008) at 06/13/2008 04:32:23 PM, Serialize complete at 06/13/2008 04:32:23 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Julien, Santosh: Actually, I think I have an idea why Max and Bob are using terms in a way that is at odds with many of the rest of us. The term "Trust Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it wasn't used in 2459 or X.509v3), a certificate issuer at the beginning of a chain of trusted certificates. However, in draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such a certificate issuer or it may instead be "a public key and associated data used by a relying party to validate a signature on a signed object" where that object is not a public key certificate and cannot be validated using a certification path. Max and Bob are clearly using a definition consistent with that one, rather than with RFC 3280 or 5280. We should do something to clear up this confused usage. Either "trust anchors" must be issuers and the "TA Management" draft needs to reduce its scope or have its name changed (perhaps to "directly trusted keys"), or else "trust anchors" can include EE certificates and the use in 3280 and 5280 should be called "anchor CA's" or something like that. Tom Gindin Julien Stern Sent by: owner-ietf-pkix@mail.imc.org 06/13/2008 04:13 AM To "Bob Bell (rtbell)" cc Santosh Chokhani , "Max Pritikin (pritikin)" , Tim Polk , ietf-pkix@imc.org Subject Re: RFC 5280 Question If I may (briefly) jump into the discussion. There seem to be a misunderstanding regarding "trusted certificates" and "trust store". Neither X.509 nor 5280 define the notion of trust store or trusted certificate. This does not exist and there is no such thing as trusted EE certificates or trusted CA certificates. You can have a "Trust Anchor" that is a DN and a public Key (see X.509 p.6 for the definition) which can be used to verify other certificates. In practice, the DN and the public key, are commonly distributed as an X.509 certificate, but that's to make things simple. Extensions/constraints, etc are not supposed to apply (See validation algorithm in X.509, p.50) Then, you have the notion of "Direct Trust", which is not clearly expressed in X.509 or 5280, but which is natural in a PKI. Direct Trust means that you have verified the binding between a DN and a public key by out of band means. In other words, it means you know the owner of the key. It this owner happens to be a CA, you are essentially in the "Trust Anchor" case. Otherwise, you are also supposed to know (by out of band means) what the public key can be used for. In your specific case, my reading of the standard is the following: 1) you insert a "certificate" in a "trust store" => This means that you insert only the public key and the DN as trusted and as a CA (the rest of the certificate is irrelevant). 2) You want to try to use standard validation mechanisms (and not direct trust). You take your EE cert, and since it is self signed and self-issued, it will validate up to the trust anchor that you have entered. 3) Be warned, however, that the owner of this public key will now be able to issue as many certificates for other DNs that he wishes. Alternative option: you use "direct trust". 1) You insert your certificate in a "direct trust store". 2) When encountering the certificate, you do not perform the X.509 validation if is it "directly trusted" 3) Be warned that you can only revoke by hand. Now, I believe (experts, please correct me if I'm wrong), that you are free to modify the X.509 or the 5280 validation algorithm as long as you are more restrictive. So, I assume you could define a "trust store with constraints" that would be populated with "trust anchors with constraints" in any way you see fit. Hope this helps. Regards, -- Julien Bob Bell (rtbell) wrote: > Santosh - > > I would recommend that the definition be broadened slightly to indicate that > regardless of whether basic constraints are present (as long as the CA bit > is false or non-existent), and that the keyCertSign bit is false. This, at > least as I read the definitions, defines the cert as an end-entity cert. > That kind of a cert in the trust store is what is causing problems for me. > > Bob > >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org >> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani >> Sent: Thursday, 12 June, 2008 18:21 >> To: Max Pritikin (pritikin) >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> >> Max, >> >> So, are you saying that you wanted to explore the implication >> of a self-signed certificate that does not have basic >> constraints extension in it and does not set keyCertSign bit >> in the key usage? I ask because that is the certificate Bob sent me. >> >> Please provide a clear, concise and complete description of >> your issues so that we have the same point of reference for >> discussions. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Thursday, June 12, 2008 7:07 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> I think Bob's question touched on an important issue. The >> inclusion of >> self-signed or EE certificates into the certificate store. >> >> For an example one should experiment with how the various major web >> browsers handle "trust this certificate" (sometimes called >> "trust this >> web page" etc). They all do it differently. >> >> - max >> >> On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: >> >>> Max, >>> >>> I do not understand from your posting what the specific concern or >>> issue >>> you want to bring to the attention of PKIX. >>> >>> We have had lot of digressions on this topic. >>> >>> Please restate what your concerns are. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 11:11 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> I'm not sure what Bob's goals are, perhaps just to ask the question. >>> We don't work very closely together. >>> >>> This just struck a note with me because I've seen it raised as a >>> problem in other cases as well. >>> >>> - max >>> >>> On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I am just responding to inaccuracies in what you are saying. >>>> >>>> Can you and Bob tell me why you started this thread and >> what you are >>>> seeking from the PKIX community? >>>> >>>> I for sure am clueless except for pointing out inaccuracies in your >>>> assertions and/or conclusions. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 6:51 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> Santosh, you've moved the conversation back to a discussion of item >>>> (3) in my comments below: out-of-scope population of the trust >>>> anchors. I think this is orthogonal to a discussion of dealing with >>>> trust-anchors that exactly match a single certificate being >>>> validated. >>>> >>>> - max >>>> >>>> >>>> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I do not have any problem with successfully verifying >> signature made >>>>> by >>>>> a trust anchor. >>>>> >>>>> As I said a day or two back in this chain, if the relying >> party who >>>>> installs the certificate as a trust anchor and does not make >>>>> additional >>>>> checks of basic constraints, is susceptible to undetected >> compromise >>>>> of >>>>> this end entity certificate spawning an entire PKI hierarchy. >>>>> >>>>> -----Original Message----- >>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>> Sent: Tuesday, June 10, 2008 6:17 PM >>>>> To: Santosh Chokhani >>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> We're into the realm of discussing _how_ one would modify >>>>> Certificate >>>>> Path Validation to support EE certificates as a trust >> anchor where >>>>> my >>>>> intention was only to support the concept as a discussion point. >>>>> >>>>> Santosh, it isn't that the constraints/extensions are >> ever applied >>>>> to >>>>> the trust anchor credential itself. It is that they are >> applied when >>>>> validating the chain. Take for example Name Constraints or Policy >>>>> Constraints or other Basic Constraints fields such as >>>>> pathLenConstraint which are all in the trust anchor >> certificate and >>>>> then taken into account when validating a certificate >> chain. If the >>>>> trust anchor certificate does not have keyCertSign set then >>>>> logically >>>>> no 'chained' certificates would be valid; just like if the >>>>> pathLenConstraint was '1' but the chain being verified has a path >>>>> length of something greater. >>>>> >>>>> I think this question of EE cert vs CA cert as a trust anchor is >>>>> about >>>>> what should happen if the chain being validated consists >> of only the >>>>> trust anchor. Independent of any questions concerning key usage, >>>>> constraints or anything else. >>>>> >>>>> - max >>>>> >>>>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> The text you cite does not apply to trust anchor. >> Please see X.509 >>>>>> and >>>>>> RFC 5280 path validation text. Nothing needs to be >> verified from a >>>>>> trust anchor. >>>>>> >>>>>> -----Original Message----- >>>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>>>> To: Santosh Chokhani >>>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>>> Subject: Re: RFC 5280 Question >>>>>> >>>>>> >>>>>> Santosh, >>>>>> >>>>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>>>> The cA boolean indicates whether the certified public key may be >>>>>>> used >>>>>>> to verify certificate signatures. If the cA boolean is not >>>>>>> asserted, >>>>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>>>> asserted. If the basic constraints extension is not >> present in a >>>>>>> version 3 certificate, or the extension is present but the cA >>>>>>> boolean >>>>>>> is not asserted, then the certified public key MUST NOT >> be used to >>>>>>> verify certificate signatures. >>>>>> An EE certificate being in the trust store would not cause >>>>>> confusion >>>>>> about this. >>>>>> >>>>>> - max >>>>>> >>>>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>>>> >>>>>>> Max, >>>>>>> >>>>>>> I do not agree with your point on item 2. Once a >> certificate is a >>>>>>> trust >>>>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>>>> being a >>>>>>> issuer. >>>>>>> >>>>>>> Furthermore, path length constraint if present in the >> self-signed >>>>>>> certificate can be ignored by relying parties. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: owner-ietf-pkix@mail.imc.org >>>>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>>>> ] >>>>>>> On Behalf Of max pritikin >>>>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>>>> To: Tim Polk >>>>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>>>> Subject: Re: RFC 5280 Question >>>>>>> >>>>>>> >>>>>>> >>>>>>> A few comments on this thread: >>>>>>> >>>>>>> 1) Any entry in the trust anchor store would seem to be >> "directly >>>>>>> trusted". If so an additional flag isn't needed so much as a >>>>>>> statement >>>>>>> about how path validation proceeds if, during path discovery, it >>>>>>> turns >>>>>>> out the certificate being validated is already directly trusted. >>>>>>> >>>>>>> 2) Inclusion into the trust anchor store doesn't imply that a >>>>>>> cert >>>>>>> is >>>>>>> trusted to issue certificates -- that is directly >> controlled by >>>>>>> the >>>>>>> values within the certificate (chain). >>>>>>> >>>>>>> 3) The out-of-band mechanism is out of scope for >> 5280/3280 but has >>>>>>> been the subject of recent BoF work (and more?). It >> would nice if >>>>>>> that >>>>>>> work also addressed this question. >>>>>>> >>>>>>> Issues related to this come up on a regular basis. Look at the >>>>>>> various >>>>>>> ways browser deal with caching EE certificates to >> "trust this site >>>>>>> always" etc. I think Bob has raised a good point. >>>>>>> >>>>>>> - max >>>>>>> >>>>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>>>> >>>>>>>> Bob, >>>>>>>> >>>>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>>>> Wen- >>>>>>>> Chen Wang have already provided a lot of good feedback. I >>>>>>>> decided >>>>>>>> to respond to the original message because I would like to go >>>>>>>> back >>>>>>>> to the perceived requirement.] >>>>>>>> >>>>>>>> It sounds like you want to construct a list of >> directly trusted >>>>>>>> EE >>>>>>>> certificates, but are trying to satisfy this >> requirement using >>>>>>>> the >>>>>>>> application's trust anchor store. There is nothing inherently >>>>>>>> wrong >>>>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>>>> trusting >>>>>>>> an EE certificate), but you really need a different - and far >>>>>>>> simpler - mechanism. The trust anchor store is >> implicitly linked >>>>>>>> to >>>>>>>> path discovery and validation, which are not relevant here >>>>>>>> since a >>>>>>>> directly trusted certificate cannot be validated. With a >>>>>>>> directly >>>>>>>> trusted certificate, there is also no mechanism to validate >>>>>>>> status >>>>>>>> information. >>>>>>>> >>>>>>>> To further complicate matters, storing the certificate >> you wish >>>>>>>> to >>>>>>>> directly trust in the trust anchor store implies that it is >>>>>>>> trusted >>>>>>>> to issue certificates as well. The path validation inputs >>>>>>>> specified >>>>>>>> in 6.1.1 (d) consider only four aspects of a trust >> anchor (name, >>>>>>>> public key algorithm, public key, and parameters if >> needed). The >>>>>>>> assumption is that the trust anchor's authority to issue >>>>>>>> certificates was verified based on an out-of-band >> trust mechanism >>>>>>>> (which is out of scope for 5280). This makes sense >> since a trust >>>>>>>> anchor might have distributed a v1 certificate (which does not >>>>>>>> include extensions). >>>>>>>> >>>>>>>> As others have noted, direct trust also implies an out-of-band >>>>>>>> trust >>>>>>>> mechanism. I received the EE certificate from a trusted source >>>>>>>> so I >>>>>>>> can trust the binding between the subject name and the key; >>>>>>>> issuer >>>>>>>> name and the signature are irrelevant. If the certificate >>>>>>>> status >>>>>>>> matters, I am also depending on an out-of-band mechanism to >>>>>>>> inform >>>>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>>>> local storage provide the basis for security in this system... >>>>>>>> >>>>>>>> Trying to combine these two mechanisms using a single >> certificate >>>>>>>> store probably requires an additional flag on every entry to >>>>>>>> differentiate between directly trusted certificates and trust >>>>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Tim Polk >>>>>>>> >>>>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>>>> >>>>>>>>> Folks- >>>>>>>>> >>>>>>>>> I am hoping someone can give me the answer to this. Does RFC >>>>>>>>> 5280 >>>>>>>>> adress the case where an end-entity certificate (not >> a CA cert) >>>>>>>>> is >>>>>>>>> installed in the trust anchor list by the user accepting the >>>>>>>>> presented cert as authoritative and then the cert is >>>>>>>>> subsequently >>>>>>>>> presented (in a later access to the site). There should be no >>>>>>>>> path >>>>>>>>> search, since the presented cert is in the trust >> anchor list. >>>>>>>>> So, >>>>>>>>> where is it defined to accept the end-entity cert? >>>>>>>>> >>>>>>>>> Thanks ---- Bob >>>>>>>>> >>>>>>>>> Bob Bell >>>>>>>>> Cisco Systems, Inc. >>>>>>>>> 576 S. Brentwood Ln. >>>>>>>>> Bountiful, UT 84010 >>>>>>>>> 801-294-3034 (v) >>>>>>>>> 801-294-3023 (f) >>>>>>>>> 801-971-4200 (c) >>>>>>>>> rtbell@cisco.com >>>>>>>>> >> ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-pkix@mail.imc.org Fri Jun 13 17:03:06 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED9C3A6806 for ; Fri, 13 Jun 2008 17:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhYTRKRyXrRj for ; Fri, 13 Jun 2008 17:03:04 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B814B3A67EE for ; Fri, 13 Jun 2008 17:03:03 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DNTZVp089195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 16:29:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DNTZ3S089194; Fri, 13 Jun 2008 16:29:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5DNTY8j089177 for ; Fri, 13 Jun 2008 16:29:34 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 7917 invoked from network); 13 Jun 2008 23:19:14 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Jun 2008 23:19:14 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Jun 2008 23:19:13 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 19:29:31 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjNlDMuDK17XIQcTyCW6IITeiItrwAGPdIg References: <48522C3F.4050103@cryptolog.com> From: "Santosh Chokhani" To: "Tom Gindin" , "Julien Stern" Cc: , "Max Pritikin (pritikin)" , "Bob Bell (rtbell)" , "Tim Polk" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, I am all for moving forward with draft-ietf-pkix-ta-mgmt-problem-statement-01. I am all for clarifying 5280. I even do not mind change as some would like if the implementers (relying party client developers) do not object. -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com]=20 Sent: Friday, June 13, 2008 4:29 PM To: Julien Stern; Santosh Chokhani Cc: ietf-pkix@imc.org; Max Pritikin (pritikin); Bob Bell (rtbell); Tim Polk Subject: Re: RFC 5280 Question Julien, Santosh: Actually, I think I have an idea why Max and Bob are using terms in a way that is at odds with many of the rest of us. The term "Trust=20 Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it wasn't=20 used in 2459 or X.509v3), a certificate issuer at the beginning of a chain=20 of trusted certificates. However, in=20 draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such a=20 certificate issuer or it may instead be "a public key and associated data=20 used by a relying party to validate a signature on a signed object" where=20 that object is not a public key certificate and cannot be validated using=20 a certification path. Max and Bob are clearly using a definition=20 consistent with that one, rather than with RFC 3280 or 5280. We should do something to clear up this confused usage. Either=20 "trust anchors" must be issuers and the "TA Management" draft needs to=20 reduce its scope or have its name changed (perhaps to "directly trusted=20 keys"), or else "trust anchors" can include EE certificates and the use in=20 3280 and 5280 should be called "anchor CA's" or something like that. Tom Gindin Julien Stern =20 Sent by: owner-ietf-pkix@mail.imc.org 06/13/2008 04:13 AM To "Bob Bell (rtbell)" cc Santosh Chokhani , "Max Pritikin (pritikin)"=20 , Tim Polk , ietf-pkix@imc.org Subject Re: RFC 5280 Question If I may (briefly) jump into the discussion. There seem to be a misunderstanding regarding "trusted certificates" and "trust store". Neither X.509 nor 5280 define the notion of trust store or trusted=20 certificate. This does not exist and there is no such thing as trusted=20 EE certificates or trusted CA certificates. You can have a "Trust Anchor" that is a DN and a public Key (see X.509=20 p.6 for the definition) which can be used to verify other certificates.=20 In practice, the DN and the public key, are commonly distributed as an=20 X.509 certificate, but that's to make things simple.=20 Extensions/constraints, etc are not supposed to apply (See validation=20 algorithm in X.509, p.50) Then, you have the notion of "Direct Trust", which is not clearly=20 expressed in X.509 or 5280, but which is natural in a PKI. Direct Trust means that you have verified the binding between a DN and a public key by out of band means. In other words, it means you know the=20 owner of the key. It this owner happens to be a CA, you are essentially in the "Trust=20 Anchor" case. Otherwise, you are also supposed to know (by out of band=20 means) what the public key can be used for. In your specific case, my reading of the standard is the following: 1) you insert a "certificate" in a "trust store" =3D> This means that = you=20 insert only the public key and the DN as trusted and as a CA (the rest=20 of the certificate is irrelevant). 2) You want to try to use standard validation mechanisms (and not direct trust). You take your EE cert, and since it is self signed and=20 self-issued, it will validate up to the trust anchor that you have=20 entered. 3) Be warned, however, that the owner of this public key will now be=20 able to issue as many certificates for other DNs that he wishes. Alternative option: you use "direct trust". 1) You insert your certificate in a "direct trust store". 2) When encountering the certificate, you do not perform the X.509=20 validation if is it "directly trusted" 3) Be warned that you can only revoke by hand. Now, I believe (experts, please correct me if I'm wrong), that you are=20 free to modify the X.509 or the 5280 validation algorithm as long as you are more restrictive. So, I assume you could define a "trust store with=20 constraints" that would be populated with "trust anchors with=20 constraints" in any way you see fit. Hope this helps. Regards, -- Julien Bob Bell (rtbell) wrote: > Santosh - >=20 > I would recommend that the definition be broadened slightly to indicate=20 that > regardless of whether basic constraints are present (as long as the CA bit > is false or non-existent), and that the keyCertSign bit is false. This,=20 at > least as I read the definitions, defines the cert as an end-entity cert. > That kind of a cert in the trust store is what is causing problems for me. >=20 > Bob >=20 >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org=20 >> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani >> Sent: Thursday, 12 June, 2008 18:21 >> To: Max Pritikin (pritikin) >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> >> Max, >> >> So, are you saying that you wanted to explore the implication=20 >> of a self-signed certificate that does not have basic=20 >> constraints extension in it and does not set keyCertSign bit=20 >> in the key usage? I ask because that is the certificate Bob sent me. >> >> Please provide a clear, concise and complete description of=20 >> your issues so that we have the same point of reference for=20 >> discussions. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Thursday, June 12, 2008 7:07 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> I think Bob's question touched on an important issue. The=20 >> inclusion of=20 >> self-signed or EE certificates into the certificate store. >> >> For an example one should experiment with how the various major web=20 >> browsers handle "trust this certificate" (sometimes called=20 >> "trust this=20 >> web page" etc). They all do it differently. >> >> - max >> >> On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: >> >>> Max, >>> >>> I do not understand from your posting what the specific concern or=20 >>> issue >>> you want to bring to the attention of PKIX. >>> >>> We have had lot of digressions on this topic. >>> >>> Please restate what your concerns are. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 11:11 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> I'm not sure what Bob's goals are, perhaps just to ask the question. >>> We don't work very closely together. >>> >>> This just struck a note with me because I've seen it raised as a >>> problem in other cases as well. >>> >>> - max >>> >>> On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I am just responding to inaccuracies in what you are saying. >>>> >>>> Can you and Bob tell me why you started this thread and=20 >> what you are >>>> seeking from the PKIX community? >>>> >>>> I for sure am clueless except for pointing out inaccuracies in your >>>> assertions and/or conclusions. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 6:51 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> Santosh, you've moved the conversation back to a discussion of item >>>> (3) in my comments below: out-of-scope population of the trust >>>> anchors. I think this is orthogonal to a discussion of dealing with >>>> trust-anchors that exactly match a single certificate being=20 >>>> validated. >>>> >>>> - max >>>> >>>> >>>> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I do not have any problem with successfully verifying=20 >> signature made >>>>> by >>>>> a trust anchor. >>>>> >>>>> As I said a day or two back in this chain, if the relying=20 >> party who >>>>> installs the certificate as a trust anchor and does not make >>>>> additional >>>>> checks of basic constraints, is susceptible to undetected=20 >> compromise >>>>> of >>>>> this end entity certificate spawning an entire PKI hierarchy. >>>>> >>>>> -----Original Message----- >>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>> Sent: Tuesday, June 10, 2008 6:17 PM >>>>> To: Santosh Chokhani >>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> We're into the realm of discussing _how_ one would modify=20 >>>>> Certificate >>>>> Path Validation to support EE certificates as a trust=20 >> anchor where=20 >>>>> my >>>>> intention was only to support the concept as a discussion point. >>>>> >>>>> Santosh, it isn't that the constraints/extensions are=20 >> ever applied=20 >>>>> to >>>>> the trust anchor credential itself. It is that they are=20 >> applied when >>>>> validating the chain. Take for example Name Constraints or Policy >>>>> Constraints or other Basic Constraints fields such as >>>>> pathLenConstraint which are all in the trust anchor=20 >> certificate and >>>>> then taken into account when validating a certificate=20 >> chain. If the >>>>> trust anchor certificate does not have keyCertSign set then=20 >>>>> logically >>>>> no 'chained' certificates would be valid; just like if the >>>>> pathLenConstraint was '1' but the chain being verified has a path >>>>> length of something greater. >>>>> >>>>> I think this question of EE cert vs CA cert as a trust anchor is >>>>> about >>>>> what should happen if the chain being validated consists=20 >> of only the >>>>> trust anchor. Independent of any questions concerning key usage, >>>>> constraints or anything else. >>>>> >>>>> - max >>>>> >>>>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> The text you cite does not apply to trust anchor.=20 >> Please see X.509 >>>>>> and >>>>>> RFC 5280 path validation text. Nothing needs to be=20 >> verified from a >>>>>> trust anchor. >>>>>> >>>>>> -----Original Message----- >>>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>>>> To: Santosh Chokhani >>>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>>> Subject: Re: RFC 5280 Question >>>>>> >>>>>> >>>>>> Santosh, >>>>>> >>>>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>>>> The cA boolean indicates whether the certified public key may be >>>>>>> used >>>>>>> to verify certificate signatures. If the cA boolean is not >>>>>>> asserted, >>>>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>>>> asserted. If the basic constraints extension is not=20 >> present in a >>>>>>> version 3 certificate, or the extension is present but the cA >>>>>>> boolean >>>>>>> is not asserted, then the certified public key MUST NOT=20 >> be used to >>>>>>> verify certificate signatures. >>>>>> An EE certificate being in the trust store would not cause=20 >>>>>> confusion >>>>>> about this. >>>>>> >>>>>> - max >>>>>> >>>>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>>>> >>>>>>> Max, >>>>>>> >>>>>>> I do not agree with your point on item 2. Once a=20 >> certificate is a >>>>>>> trust >>>>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>>>> being a >>>>>>> issuer. >>>>>>> >>>>>>> Furthermore, path length constraint if present in the=20 >> self-signed >>>>>>> certificate can be ignored by relying parties. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: owner-ietf-pkix@mail.imc.org >>>>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>>>> ] >>>>>>> On Behalf Of max pritikin >>>>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>>>> To: Tim Polk >>>>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>>>> Subject: Re: RFC 5280 Question >>>>>>> >>>>>>> >>>>>>> >>>>>>> A few comments on this thread: >>>>>>> >>>>>>> 1) Any entry in the trust anchor store would seem to be=20 >> "directly >>>>>>> trusted". If so an additional flag isn't needed so much as a >>>>>>> statement >>>>>>> about how path validation proceeds if, during path discovery, it >>>>>>> turns >>>>>>> out the certificate being validated is already directly trusted. >>>>>>> >>>>>>> 2) Inclusion into the trust anchor store doesn't imply that a=20 >>>>>>> cert >>>>>>> is >>>>>>> trusted to issue certificates -- that is directly=20 >> controlled by=20 >>>>>>> the >>>>>>> values within the certificate (chain). >>>>>>> >>>>>>> 3) The out-of-band mechanism is out of scope for=20 >> 5280/3280 but has >>>>>>> been the subject of recent BoF work (and more?). It=20 >> would nice if >>>>>>> that >>>>>>> work also addressed this question. >>>>>>> >>>>>>> Issues related to this come up on a regular basis. Look at the >>>>>>> various >>>>>>> ways browser deal with caching EE certificates to=20 >> "trust this site >>>>>>> always" etc. I think Bob has raised a good point. >>>>>>> >>>>>>> - max >>>>>>> >>>>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>>>> >>>>>>>> Bob, >>>>>>>> >>>>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>>>> Wen- >>>>>>>> Chen Wang have already provided a lot of good feedback. I=20 >>>>>>>> decided >>>>>>>> to respond to the original message because I would like to go=20 >>>>>>>> back >>>>>>>> to the perceived requirement.] >>>>>>>> >>>>>>>> It sounds like you want to construct a list of=20 >> directly trusted=20 >>>>>>>> EE >>>>>>>> certificates, but are trying to satisfy this=20 >> requirement using=20 >>>>>>>> the >>>>>>>> application's trust anchor store. There is nothing inherently >>>>>>>> wrong >>>>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>>>> trusting >>>>>>>> an EE certificate), but you really need a different - and far >>>>>>>> simpler - mechanism. The trust anchor store is=20 >> implicitly linked >>>>>>>> to >>>>>>>> path discovery and validation, which are not relevant here=20 >>>>>>>> since a >>>>>>>> directly trusted certificate cannot be validated. With a=20 >>>>>>>> directly >>>>>>>> trusted certificate, there is also no mechanism to validate=20 >>>>>>>> status >>>>>>>> information. >>>>>>>> >>>>>>>> To further complicate matters, storing the certificate=20 >> you wish=20 >>>>>>>> to >>>>>>>> directly trust in the trust anchor store implies that it is >>>>>>>> trusted >>>>>>>> to issue certificates as well. The path validation inputs >>>>>>>> specified >>>>>>>> in 6.1.1 (d) consider only four aspects of a trust=20 >> anchor (name, >>>>>>>> public key algorithm, public key, and parameters if=20 >> needed). The >>>>>>>> assumption is that the trust anchor's authority to issue >>>>>>>> certificates was verified based on an out-of-band=20 >> trust mechanism >>>>>>>> (which is out of scope for 5280). This makes sense=20 >> since a trust >>>>>>>> anchor might have distributed a v1 certificate (which does not >>>>>>>> include extensions). >>>>>>>> >>>>>>>> As others have noted, direct trust also implies an out-of-band >>>>>>>> trust >>>>>>>> mechanism. I received the EE certificate from a trusted source >>>>>>>> so I >>>>>>>> can trust the binding between the subject name and the key;=20 >>>>>>>> issuer >>>>>>>> name and the signature are irrelevant. If the certificate=20 >>>>>>>> status >>>>>>>> matters, I am also depending on an out-of-band mechanism to=20 >>>>>>>> inform >>>>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>>>> local storage provide the basis for security in this system... >>>>>>>> >>>>>>>> Trying to combine these two mechanisms using a single=20 >> certificate >>>>>>>> store probably requires an additional flag on every entry to >>>>>>>> differentiate between directly trusted certificates and trust >>>>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Tim Polk >>>>>>>> >>>>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>>>> >>>>>>>>> Folks- >>>>>>>>> >>>>>>>>> I am hoping someone can give me the answer to this. Does RFC=20 >>>>>>>>> 5280 >>>>>>>>> adress the case where an end-entity certificate (not=20 >> a CA cert) >>>>>>>>> is >>>>>>>>> installed in the trust anchor list by the user accepting the >>>>>>>>> presented cert as authoritative and then the cert is=20 >>>>>>>>> subsequently >>>>>>>>> presented (in a later access to the site). There should be no >>>>>>>>> path >>>>>>>>> search, since the presented cert is in the trust=20 >> anchor list.=20 >>>>>>>>> So, >>>>>>>>> where is it defined to accept the end-entity cert? >>>>>>>>> >>>>>>>>> Thanks ---- Bob >>>>>>>>> >>>>>>>>> Bob Bell >>>>>>>>> Cisco Systems, Inc. >>>>>>>>> 576 S. Brentwood Ln. >>>>>>>>> Bountiful, UT 84010 >>>>>>>>> 801-294-3034 (v) >>>>>>>>> 801-294-3023 (f) >>>>>>>>> 801-971-4200 (c) >>>>>>>>> rtbell@cisco.com >>>>>>>>> >> ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ From owner-ietf-pkix@mail.imc.org Mon Jun 16 02:39:31 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1A028C0E7 for ; Mon, 16 Jun 2008 02:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FU8BJlWjyDd1 for ; Mon, 16 Jun 2008 02:39:26 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DDA0028C0F0 for ; Mon, 16 Jun 2008 02:39:25 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5G8sbOT001088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 01:54:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5G8sb8M001087; Mon, 16 Jun 2008 01:54:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (kraid.ipv6.nerim.net [IPv6:2001:7a8:1:1::95]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5G8sZIa001069 for ; Mon, 16 Jun 2008 01:54:35 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id D0FF9CF06F; Mon, 16 Jun 2008 10:54:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id D22854429D; Mon, 16 Jun 2008 10:54:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6O6L2cRmYjc; Mon, 16 Jun 2008 10:54:24 +0200 (CEST) Received: from [10.0.1.15] (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with ESMTP id 1FE184429B; Mon, 16 Jun 2008 10:54:24 +0200 (CEST) Message-ID: <48562A3F.4070103@cryptolog.com> Date: Mon, 16 Jun 2008 10:54:23 +0200 From: Julien Stern User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Tom Gindin Cc: Santosh Chokhani , ietf-pkix@imc.org, "Max Pritikin (pritikin)" , "Bob Bell (rtbell)" , Tim Polk Subject: Re: RFC 5280 Question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, I agree with you there is a confusion, but I would not place it at exactly the same place. IMHO, TrustAnchor is clearly defined by X.509 (but never by 5280, by the way). Taken from X.509 v5: "trust anchor: A trust anchor is a set of the following information in addition to the public key: algorithm identifier, public key parameters (if applicable), distinguished name of the holder of the associated private key (i.e., the subject CA) and optionally a validity period." Now, I believe the problem is that to validate a certificate you need: - a Trust Anchor - the target certificate - a validation algorithm - input parameters for this validation algorithm The first two are clear, but, my reading is that 5280 explicitly allows anyone to use its own validation algorithm and its own input parameters (as long as they are more restrictive than the base algorithm described). So, to take a ridiculous example, I could do the following: say that I have a Trust Anchor distributed as a certificate, my algorithm could check whether there exists an ExtendedKeyUsage specifying OCSP and timestamping at the same time and in that case (and only in that case) restrict the maximum path length of the chain to 4. Well, I'm pretty sure that would be valid with respect to 5280. After all, I'm only restricting the algorithm. Seriously though, we cannot expect to have any consistency among different applications if we allow different algorithms to be used. Either we standardize on one validation algorithm (together with input parameters) or every TA should specify which validation algorithm together with which input parameters should be used to validate its certs. All this being said, and just like Santosh, I'm all for clarifying all that can be clarified :) And I believe that there is no issue with X.509 or 5280 except a _lot_ of flexibility ! Regards, -- Julien Tom Gindin wrote: > Julien, Santosh: > > Actually, I think I have an idea why Max and Bob are using terms > in a way that is at odds with many of the rest of us. The term "Trust > Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it wasn't > used in 2459 or X.509v3), a certificate issuer at the beginning of a chain > of trusted certificates. However, in > draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such a > certificate issuer or it may instead be "a public key and associated data > used by a relying party to validate a signature on a signed object" where > that object is not a public key certificate and cannot be validated using > a certification path. Max and Bob are clearly using a definition > consistent with that one, rather than with RFC 3280 or 5280. > We should do something to clear up this confused usage. Either > "trust anchors" must be issuers and the "TA Management" draft needs to > reduce its scope or have its name changed (perhaps to "directly trusted > keys"), or else "trust anchors" can include EE certificates and the use in > 3280 and 5280 should be called "anchor CA's" or something like that. > > Tom Gindin > > > > > > Julien Stern > Sent by: owner-ietf-pkix@mail.imc.org > 06/13/2008 04:13 AM > > To > "Bob Bell (rtbell)" > cc > Santosh Chokhani , "Max Pritikin (pritikin)" > , Tim Polk , ietf-pkix@imc.org > Subject > Re: RFC 5280 Question > > > > > > > > If I may (briefly) jump into the discussion. > There seem to be a misunderstanding regarding "trusted certificates" and > "trust store". > > Neither X.509 nor 5280 define the notion of trust store or trusted > certificate. This does not exist and there is no such thing as trusted > EE certificates or trusted CA certificates. > > You can have a "Trust Anchor" that is a DN and a public Key (see X.509 > p.6 for the definition) which can be used to verify other certificates. > In practice, the DN and the public key, are commonly distributed as an > X.509 certificate, but that's to make things simple. > Extensions/constraints, etc are not supposed to apply (See validation > algorithm in X.509, p.50) > > Then, you have the notion of "Direct Trust", which is not clearly > expressed in X.509 or 5280, but which is natural in a PKI. > Direct Trust means that you have verified the binding between a DN and a > public key by out of band means. In other words, it means you know the > owner of the key. > > It this owner happens to be a CA, you are essentially in the "Trust > Anchor" case. Otherwise, you are also supposed to know (by out of band > means) what the public key can be used for. > > In your specific case, my reading of the standard is the following: > > 1) you insert a "certificate" in a "trust store" => This means that you > insert only the public key and the DN as trusted and as a CA (the rest > of the certificate is irrelevant). > > 2) You want to try to use standard validation mechanisms (and not direct > trust). You take your EE cert, and since it is self signed and > self-issued, it will validate up to the trust anchor that you have > entered. > > 3) Be warned, however, that the owner of this public key will now be > able to issue as many certificates for other DNs that he wishes. > > Alternative option: you use "direct trust". > > 1) You insert your certificate in a "direct trust store". > 2) When encountering the certificate, you do not perform the X.509 > validation if is it "directly trusted" > 3) Be warned that you can only revoke by hand. > > > Now, I believe (experts, please correct me if I'm wrong), that you are > free to modify the X.509 or the 5280 validation algorithm as long as you > are more restrictive. So, I assume you could define a "trust store with > constraints" that would be populated with "trust anchors with > constraints" in any way you see fit. > > Hope this helps. > > Regards, > > -- > Julien > > Bob Bell (rtbell) wrote: >> Santosh - >> >> I would recommend that the definition be broadened slightly to indicate > that >> regardless of whether basic constraints are present (as long as the CA > bit >> is false or non-existent), and that the keyCertSign bit is false. This, > at >> least as I read the definitions, defines the cert as an end-entity cert. >> That kind of a cert in the trust store is what is causing problems for > me. >> Bob >> >>> -----Original Message----- >>> From: owner-ietf-pkix@mail.imc.org >>> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani >>> Sent: Thursday, 12 June, 2008 18:21 >>> To: Max Pritikin (pritikin) >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: RE: RFC 5280 Question >>> >>> >>> Max, >>> >>> So, are you saying that you wanted to explore the implication >>> of a self-signed certificate that does not have basic >>> constraints extension in it and does not set keyCertSign bit >>> in the key usage? I ask because that is the certificate Bob sent me. >>> >>> Please provide a clear, concise and complete description of >>> your issues so that we have the same point of reference for >>> discussions. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Thursday, June 12, 2008 7:07 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> I think Bob's question touched on an important issue. The >>> inclusion of >>> self-signed or EE certificates into the certificate store. >>> >>> For an example one should experiment with how the various major web >>> browsers handle "trust this certificate" (sometimes called >>> "trust this >>> web page" etc). They all do it differently. >>> >>> - max >>> >>> On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I do not understand from your posting what the specific concern or >>>> issue >>>> you want to bring to the attention of PKIX. >>>> >>>> We have had lot of digressions on this topic. >>>> >>>> Please restate what your concerns are. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 11:11 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> I'm not sure what Bob's goals are, perhaps just to ask the question. >>>> We don't work very closely together. >>>> >>>> This just struck a note with me because I've seen it raised as a >>>> problem in other cases as well. >>>> >>>> - max >>>> >>>> On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I am just responding to inaccuracies in what you are saying. >>>>> >>>>> Can you and Bob tell me why you started this thread and >>> what you are >>>>> seeking from the PKIX community? >>>>> >>>>> I for sure am clueless except for pointing out inaccuracies in your >>>>> assertions and/or conclusions. >>>>> >>>>> -----Original Message----- >>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>> Sent: Tuesday, June 10, 2008 6:51 PM >>>>> To: Santosh Chokhani >>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> Santosh, you've moved the conversation back to a discussion of item >>>>> (3) in my comments below: out-of-scope population of the trust >>>>> anchors. I think this is orthogonal to a discussion of dealing with >>>>> trust-anchors that exactly match a single certificate being >>>>> validated. >>>>> >>>>> - max >>>>> >>>>> >>>>> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> I do not have any problem with successfully verifying >>> signature made >>>>>> by >>>>>> a trust anchor. >>>>>> >>>>>> As I said a day or two back in this chain, if the relying >>> party who >>>>>> installs the certificate as a trust anchor and does not make >>>>>> additional >>>>>> checks of basic constraints, is susceptible to undetected >>> compromise >>>>>> of >>>>>> this end entity certificate spawning an entire PKI hierarchy. >>>>>> >>>>>> -----Original Message----- >>>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>>> Sent: Tuesday, June 10, 2008 6:17 PM >>>>>> To: Santosh Chokhani >>>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>>> Subject: Re: RFC 5280 Question >>>>>> >>>>>> >>>>>> We're into the realm of discussing _how_ one would modify >>>>>> Certificate >>>>>> Path Validation to support EE certificates as a trust >>> anchor where >>>>>> my >>>>>> intention was only to support the concept as a discussion point. >>>>>> >>>>>> Santosh, it isn't that the constraints/extensions are >>> ever applied >>>>>> to >>>>>> the trust anchor credential itself. It is that they are >>> applied when >>>>>> validating the chain. Take for example Name Constraints or Policy >>>>>> Constraints or other Basic Constraints fields such as >>>>>> pathLenConstraint which are all in the trust anchor >>> certificate and >>>>>> then taken into account when validating a certificate >>> chain. If the >>>>>> trust anchor certificate does not have keyCertSign set then >>>>>> logically >>>>>> no 'chained' certificates would be valid; just like if the >>>>>> pathLenConstraint was '1' but the chain being verified has a path >>>>>> length of something greater. >>>>>> >>>>>> I think this question of EE cert vs CA cert as a trust anchor is >>>>>> about >>>>>> what should happen if the chain being validated consists >>> of only the >>>>>> trust anchor. Independent of any questions concerning key usage, >>>>>> constraints or anything else. >>>>>> >>>>>> - max >>>>>> >>>>>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>>>>> >>>>>>> Max, >>>>>>> >>>>>>> The text you cite does not apply to trust anchor. >>> Please see X.509 >>>>>>> and >>>>>>> RFC 5280 path validation text. Nothing needs to be >>> verified from a >>>>>>> trust anchor. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>>>>> To: Santosh Chokhani >>>>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>>>> Subject: Re: RFC 5280 Question >>>>>>> >>>>>>> >>>>>>> Santosh, >>>>>>> >>>>>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>>>>> The cA boolean indicates whether the certified public key may be >>>>>>>> used >>>>>>>> to verify certificate signatures. If the cA boolean is not >>>>>>>> asserted, >>>>>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>>>>> asserted. If the basic constraints extension is not >>> present in a >>>>>>>> version 3 certificate, or the extension is present but the cA >>>>>>>> boolean >>>>>>>> is not asserted, then the certified public key MUST NOT >>> be used to >>>>>>>> verify certificate signatures. >>>>>>> An EE certificate being in the trust store would not cause >>>>>>> confusion >>>>>>> about this. >>>>>>> >>>>>>> - max >>>>>>> >>>>>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>>>>> >>>>>>>> Max, >>>>>>>> >>>>>>>> I do not agree with your point on item 2. Once a >>> certificate is a >>>>>>>> trust >>>>>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>>>>> being a >>>>>>>> issuer. >>>>>>>> >>>>>>>> Furthermore, path length constraint if present in the >>> self-signed >>>>>>>> certificate can be ignored by relying parties. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: owner-ietf-pkix@mail.imc.org >>>>>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>>>>> ] >>>>>>>> On Behalf Of max pritikin >>>>>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>>>>> To: Tim Polk >>>>>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>>>>> Subject: Re: RFC 5280 Question >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A few comments on this thread: >>>>>>>> >>>>>>>> 1) Any entry in the trust anchor store would seem to be >>> "directly >>>>>>>> trusted". If so an additional flag isn't needed so much as a >>>>>>>> statement >>>>>>>> about how path validation proceeds if, during path discovery, it >>>>>>>> turns >>>>>>>> out the certificate being validated is already directly trusted. >>>>>>>> >>>>>>>> 2) Inclusion into the trust anchor store doesn't imply that a >>>>>>>> cert >>>>>>>> is >>>>>>>> trusted to issue certificates -- that is directly >>> controlled by >>>>>>>> the >>>>>>>> values within the certificate (chain). >>>>>>>> >>>>>>>> 3) The out-of-band mechanism is out of scope for >>> 5280/3280 but has >>>>>>>> been the subject of recent BoF work (and more?). It >>> would nice if >>>>>>>> that >>>>>>>> work also addressed this question. >>>>>>>> >>>>>>>> Issues related to this come up on a regular basis. Look at the >>>>>>>> various >>>>>>>> ways browser deal with caching EE certificates to >>> "trust this site >>>>>>>> always" etc. I think Bob has raised a good point. >>>>>>>> >>>>>>>> - max >>>>>>>> >>>>>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>>>>> >>>>>>>>> Bob, >>>>>>>>> >>>>>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>>>>> Wen- >>>>>>>>> Chen Wang have already provided a lot of good feedback. I >>>>>>>>> decided >>>>>>>>> to respond to the original message because I would like to go >>>>>>>>> back >>>>>>>>> to the perceived requirement.] >>>>>>>>> >>>>>>>>> It sounds like you want to construct a list of >>> directly trusted >>>>>>>>> EE >>>>>>>>> certificates, but are trying to satisfy this >>> requirement using >>>>>>>>> the >>>>>>>>> application's trust anchor store. There is nothing inherently >>>>>>>>> wrong >>>>>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>>>>> trusting >>>>>>>>> an EE certificate), but you really need a different - and far >>>>>>>>> simpler - mechanism. The trust anchor store is >>> implicitly linked >>>>>>>>> to >>>>>>>>> path discovery and validation, which are not relevant here >>>>>>>>> since a >>>>>>>>> directly trusted certificate cannot be validated. With a >>>>>>>>> directly >>>>>>>>> trusted certificate, there is also no mechanism to validate >>>>>>>>> status >>>>>>>>> information. >>>>>>>>> >>>>>>>>> To further complicate matters, storing the certificate >>> you wish >>>>>>>>> to >>>>>>>>> directly trust in the trust anchor store implies that it is >>>>>>>>> trusted >>>>>>>>> to issue certificates as well. The path validation inputs >>>>>>>>> specified >>>>>>>>> in 6.1.1 (d) consider only four aspects of a trust >>> anchor (name, >>>>>>>>> public key algorithm, public key, and parameters if >>> needed). The >>>>>>>>> assumption is that the trust anchor's authority to issue >>>>>>>>> certificates was verified based on an out-of-band >>> trust mechanism >>>>>>>>> (which is out of scope for 5280). This makes sense >>> since a trust >>>>>>>>> anchor might have distributed a v1 certificate (which does not >>>>>>>>> include extensions). >>>>>>>>> >>>>>>>>> As others have noted, direct trust also implies an out-of-band >>>>>>>>> trust >>>>>>>>> mechanism. I received the EE certificate from a trusted source >>>>>>>>> so I >>>>>>>>> can trust the binding between the subject name and the key; >>>>>>>>> issuer >>>>>>>>> name and the signature are irrelevant. If the certificate >>>>>>>>> status >>>>>>>>> matters, I am also depending on an out-of-band mechanism to >>>>>>>>> inform >>>>>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>>>>> local storage provide the basis for security in this system... >>>>>>>>> >>>>>>>>> Trying to combine these two mechanisms using a single >>> certificate >>>>>>>>> store probably requires an additional flag on every entry to >>>>>>>>> differentiate between directly trusted certificates and trust >>>>>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Tim Polk >>>>>>>>> >>>>>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>>>>> >>>>>>>>>> Folks- >>>>>>>>>> >>>>>>>>>> I am hoping someone can give me the answer to this. Does RFC >>>>>>>>>> 5280 >>>>>>>>>> adress the case where an end-entity certificate (not >>> a CA cert) >>>>>>>>>> is >>>>>>>>>> installed in the trust anchor list by the user accepting the >>>>>>>>>> presented cert as authoritative and then the cert is >>>>>>>>>> subsequently >>>>>>>>>> presented (in a later access to the site). There should be no >>>>>>>>>> path >>>>>>>>>> search, since the presented cert is in the trust >>> anchor list. >>>>>>>>>> So, >>>>>>>>>> where is it defined to accept the end-entity cert? >>>>>>>>>> >>>>>>>>>> Thanks ---- Bob >>>>>>>>>> >>>>>>>>>> Bob Bell >>>>>>>>>> Cisco Systems, Inc. >>>>>>>>>> 576 S. Brentwood Ln. >>>>>>>>>> Bountiful, UT 84010 >>>>>>>>>> 801-294-3034 (v) >>>>>>>>>> 801-294-3023 (f) >>>>>>>>>> 801-971-4200 (c) >>>>>>>>>> rtbell@cisco.com >>>>>>>>>> > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > From owner-ietf-pkix@mail.imc.org Mon Jun 16 11:15:47 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894163A6A07 for ; Mon, 16 Jun 2008 11:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1fV3tuywx7L for ; Mon, 16 Jun 2008 11:15:46 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 13B783A69F2 for ; Mon, 16 Jun 2008 11:15:45 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5GHUjnx083287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 10:30:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5GHUj3s083284; Mon, 16 Jun 2008 10:30:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5GHUicY083273 for ; Mon, 16 Jun 2008 10:30:45 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id C14783A6879; Mon, 16 Jun 2008 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080616173001.C14783A6879@core3.amsl.com> Date: Mon, 16 Jun 2008 10:30:01 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Author(s) : Q. Dang Filename : draft-ietf-pkix-sha2-dsa-ecdsa-03.txt Pages : 17 Date : 2008-6-16 This document supplements RFC 3279. It specifies algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384 or SHA- 512 as hashing algorithm. This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-sha2-dsa-ecdsa-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-16101907.I-D@ietf.org> --NextPart-- From owner-ietf-pkix@mail.imc.org Tue Jun 17 14:40:45 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768973A6924 for ; Tue, 17 Jun 2008 14:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80JrT26sFyEv for ; Tue, 17 Jun 2008 14:40:37 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 322FC3A690C for ; Tue, 17 Jun 2008 14:40:35 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5HL4cD2064214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jun 2008 14:04:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5HL4cqB064213; Tue, 17 Jun 2008 14:04:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from moses.radium.ncsc.mil (moses.radium.ncsc.mil [144.51.73.129]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5HL4ZCb064172 for ; Tue, 17 Jun 2008 14:04:36 -0700 (MST) (envelope-from r.reddy@radium.ncsc.mil) Received: from exodus.radium.ncsc.mil (exodus.radium.ncsc.mil [144.51.74.11]) by moses.radium.ncsc.mil with ESMTP id m5HLAIWE011843; Tue, 17 Jun 2008 21:10:18 GMT Received: from gust.radium.ncsc.mil by exodus.radium.ncsc.mil (8.11.7p3+Sun/SMI-SVR4) id m5HL4SR03235; Tue, 17 Jun 2008 21:04:29 GMT Received: by gust.radium.ncsc.mil with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Jun 2008 17:04:28 -0400 Message-ID: <6660125B6BE0FF42B65E5C7EEA65C38E027AAF58@gust.radium.ncsc.mil> From: "Reddy, Raksha P." To: "'Santosh Chokhani'" , Tom Gindin , Julien Stern Cc: ietf-pkix@imc.org, "Max Pritikin (pritikin)" , "Bob Bell (rtbell)" , Tim Polk Subject: RE: RFC 5280 Question Date: Tue, 17 Jun 2008 17:04:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI--The concepts described in draft-ietf-pkix-ta-mgmt-problem-statement-01 are being further developed into a requirements document, which is currently being finalized. This document is intended to list requirements that are in this problem space of trust anchor management and acknowledges that a trust anchor should enable certificate path validation in compliance with RFC 5280. I encourage all parties interested in this work to review the document, which will be submitted very soon, and provide feedback accordingly. Raksha Reddy National Security Agency -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Friday, June 13, 2008 7:30 PM To: Tom Gindin; Julien Stern Cc: ietf-pkix@imc.org; Max Pritikin (pritikin); Bob Bell (rtbell); Tim Polk Subject: RE: RFC 5280 Question Tom, I am all for moving forward with draft-ietf-pkix-ta-mgmt-problem-statement-01. I am all for clarifying 5280. I even do not mind change as some would like if the implementers (relying party client developers) do not object. -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Friday, June 13, 2008 4:29 PM To: Julien Stern; Santosh Chokhani Cc: ietf-pkix@imc.org; Max Pritikin (pritikin); Bob Bell (rtbell); Tim Polk Subject: Re: RFC 5280 Question Julien, Santosh: Actually, I think I have an idea why Max and Bob are using terms in a way that is at odds with many of the rest of us. The term "Trust Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it wasn't used in 2459 or X.509v3), a certificate issuer at the beginning of a chain of trusted certificates. However, in draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such a certificate issuer or it may instead be "a public key and associated data used by a relying party to validate a signature on a signed object" where that object is not a public key certificate and cannot be validated using a certification path. Max and Bob are clearly using a definition consistent with that one, rather than with RFC 3280 or 5280. We should do something to clear up this confused usage. Either "trust anchors" must be issuers and the "TA Management" draft needs to reduce its scope or have its name changed (perhaps to "directly trusted keys"), or else "trust anchors" can include EE certificates and the use in 3280 and 5280 should be called "anchor CA's" or something like that. Tom Gindin Julien Stern Sent by: owner-ietf-pkix@mail.imc.org 06/13/2008 04:13 AM To "Bob Bell (rtbell)" cc Santosh Chokhani , "Max Pritikin (pritikin)" , Tim Polk , ietf-pkix@imc.org Subject Re: RFC 5280 Question If I may (briefly) jump into the discussion. There seem to be a misunderstanding regarding "trusted certificates" and "trust store". Neither X.509 nor 5280 define the notion of trust store or trusted certificate. This does not exist and there is no such thing as trusted EE certificates or trusted CA certificates. You can have a "Trust Anchor" that is a DN and a public Key (see X.509 p.6 for the definition) which can be used to verify other certificates. In practice, the DN and the public key, are commonly distributed as an X.509 certificate, but that's to make things simple. Extensions/constraints, etc are not supposed to apply (See validation algorithm in X.509, p.50) Then, you have the notion of "Direct Trust", which is not clearly expressed in X.509 or 5280, but which is natural in a PKI. Direct Trust means that you have verified the binding between a DN and a public key by out of band means. In other words, it means you know the owner of the key. It this owner happens to be a CA, you are essentially in the "Trust Anchor" case. Otherwise, you are also supposed to know (by out of band means) what the public key can be used for. In your specific case, my reading of the standard is the following: 1) you insert a "certificate" in a "trust store" => This means that you insert only the public key and the DN as trusted and as a CA (the rest of the certificate is irrelevant). 2) You want to try to use standard validation mechanisms (and not direct trust). You take your EE cert, and since it is self signed and self-issued, it will validate up to the trust anchor that you have entered. 3) Be warned, however, that the owner of this public key will now be able to issue as many certificates for other DNs that he wishes. Alternative option: you use "direct trust". 1) You insert your certificate in a "direct trust store". 2) When encountering the certificate, you do not perform the X.509 validation if is it "directly trusted" 3) Be warned that you can only revoke by hand. Now, I believe (experts, please correct me if I'm wrong), that you are free to modify the X.509 or the 5280 validation algorithm as long as you are more restrictive. So, I assume you could define a "trust store with constraints" that would be populated with "trust anchors with constraints" in any way you see fit. Hope this helps. Regards, -- Julien Bob Bell (rtbell) wrote: > Santosh - > > I would recommend that the definition be broadened slightly to indicate that > regardless of whether basic constraints are present (as long as the CA bit > is false or non-existent), and that the keyCertSign bit is false. This, at > least as I read the definitions, defines the cert as an end-entity cert. > That kind of a cert in the trust store is what is causing problems for me. > > Bob > >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org >> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani >> Sent: Thursday, 12 June, 2008 18:21 >> To: Max Pritikin (pritikin) >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> >> Max, >> >> So, are you saying that you wanted to explore the implication >> of a self-signed certificate that does not have basic >> constraints extension in it and does not set keyCertSign bit >> in the key usage? I ask because that is the certificate Bob sent me. >> >> Please provide a clear, concise and complete description of >> your issues so that we have the same point of reference for >> discussions. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Thursday, June 12, 2008 7:07 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> I think Bob's question touched on an important issue. The >> inclusion of >> self-signed or EE certificates into the certificate store. >> >> For an example one should experiment with how the various major web >> browsers handle "trust this certificate" (sometimes called >> "trust this >> web page" etc). They all do it differently. >> >> - max >> >> On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: >> >>> Max, >>> >>> I do not understand from your posting what the specific concern or >>> issue >>> you want to bring to the attention of PKIX. >>> >>> We have had lot of digressions on this topic. >>> >>> Please restate what your concerns are. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 11:11 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> I'm not sure what Bob's goals are, perhaps just to ask the question. >>> We don't work very closely together. >>> >>> This just struck a note with me because I've seen it raised as a >>> problem in other cases as well. >>> >>> - max >>> >>> On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I am just responding to inaccuracies in what you are saying. >>>> >>>> Can you and Bob tell me why you started this thread and >> what you are >>>> seeking from the PKIX community? >>>> >>>> I for sure am clueless except for pointing out inaccuracies in your >>>> assertions and/or conclusions. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 6:51 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> Santosh, you've moved the conversation back to a discussion of item >>>> (3) in my comments below: out-of-scope population of the trust >>>> anchors. I think this is orthogonal to a discussion of dealing with >>>> trust-anchors that exactly match a single certificate being >>>> validated. >>>> >>>> - max >>>> >>>> >>>> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I do not have any problem with successfully verifying >> signature made >>>>> by >>>>> a trust anchor. >>>>> >>>>> As I said a day or two back in this chain, if the relying >> party who >>>>> installs the certificate as a trust anchor and does not make >>>>> additional >>>>> checks of basic constraints, is susceptible to undetected >> compromise >>>>> of >>>>> this end entity certificate spawning an entire PKI hierarchy. >>>>> >>>>> -----Original Message----- >>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>> Sent: Tuesday, June 10, 2008 6:17 PM >>>>> To: Santosh Chokhani >>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> We're into the realm of discussing _how_ one would modify >>>>> Certificate >>>>> Path Validation to support EE certificates as a trust >> anchor where >>>>> my >>>>> intention was only to support the concept as a discussion point. >>>>> >>>>> Santosh, it isn't that the constraints/extensions are >> ever applied >>>>> to >>>>> the trust anchor credential itself. It is that they are >> applied when >>>>> validating the chain. Take for example Name Constraints or Policy >>>>> Constraints or other Basic Constraints fields such as >>>>> pathLenConstraint which are all in the trust anchor >> certificate and >>>>> then taken into account when validating a certificate >> chain. If the >>>>> trust anchor certificate does not have keyCertSign set then >>>>> logically >>>>> no 'chained' certificates would be valid; just like if the >>>>> pathLenConstraint was '1' but the chain being verified has a path >>>>> length of something greater. >>>>> >>>>> I think this question of EE cert vs CA cert as a trust anchor is >>>>> about >>>>> what should happen if the chain being validated consists >> of only the >>>>> trust anchor. Independent of any questions concerning key usage, >>>>> constraints or anything else. >>>>> >>>>> - max >>>>> >>>>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> The text you cite does not apply to trust anchor. >> Please see X.509 >>>>>> and >>>>>> RFC 5280 path validation text. Nothing needs to be >> verified from a >>>>>> trust anchor. >>>>>> >>>>>> -----Original Message----- >>>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>>>> To: Santosh Chokhani >>>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>>> Subject: Re: RFC 5280 Question >>>>>> >>>>>> >>>>>> Santosh, >>>>>> >>>>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>>>> The cA boolean indicates whether the certified public key may be >>>>>>> used >>>>>>> to verify certificate signatures. If the cA boolean is not >>>>>>> asserted, >>>>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>>>> asserted. If the basic constraints extension is not >> present in a >>>>>>> version 3 certificate, or the extension is present but the cA >>>>>>> boolean >>>>>>> is not asserted, then the certified public key MUST NOT >> be used to >>>>>>> verify certificate signatures. >>>>>> An EE certificate being in the trust store would not cause >>>>>> confusion >>>>>> about this. >>>>>> >>>>>> - max >>>>>> >>>>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>>>> >>>>>>> Max, >>>>>>> >>>>>>> I do not agree with your point on item 2. Once a >> certificate is a >>>>>>> trust >>>>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>>>> being a >>>>>>> issuer. >>>>>>> >>>>>>> Furthermore, path length constraint if present in the >> self-signed >>>>>>> certificate can be ignored by relying parties. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: owner-ietf-pkix@mail.imc.org >>>>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>>>> ] >>>>>>> On Behalf Of max pritikin >>>>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>>>> To: Tim Polk >>>>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>>>> Subject: Re: RFC 5280 Question >>>>>>> >>>>>>> >>>>>>> >>>>>>> A few comments on this thread: >>>>>>> >>>>>>> 1) Any entry in the trust anchor store would seem to be >> "directly >>>>>>> trusted". If so an additional flag isn't needed so much as a >>>>>>> statement >>>>>>> about how path validation proceeds if, during path discovery, it >>>>>>> turns >>>>>>> out the certificate being validated is already directly trusted. >>>>>>> >>>>>>> 2) Inclusion into the trust anchor store doesn't imply that a >>>>>>> cert >>>>>>> is >>>>>>> trusted to issue certificates -- that is directly >> controlled by >>>>>>> the >>>>>>> values within the certificate (chain). >>>>>>> >>>>>>> 3) The out-of-band mechanism is out of scope for >> 5280/3280 but has >>>>>>> been the subject of recent BoF work (and more?). It >> would nice if >>>>>>> that >>>>>>> work also addressed this question. >>>>>>> >>>>>>> Issues related to this come up on a regular basis. Look at the >>>>>>> various >>>>>>> ways browser deal with caching EE certificates to >> "trust this site >>>>>>> always" etc. I think Bob has raised a good point. >>>>>>> >>>>>>> - max >>>>>>> >>>>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>>>> >>>>>>>> Bob, >>>>>>>> >>>>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>>>> Wen- >>>>>>>> Chen Wang have already provided a lot of good feedback. I >>>>>>>> decided >>>>>>>> to respond to the original message because I would like to go >>>>>>>> back >>>>>>>> to the perceived requirement.] >>>>>>>> >>>>>>>> It sounds like you want to construct a list of >> directly trusted >>>>>>>> EE >>>>>>>> certificates, but are trying to satisfy this >> requirement using >>>>>>>> the >>>>>>>> application's trust anchor store. There is nothing inherently >>>>>>>> wrong >>>>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>>>> trusting >>>>>>>> an EE certificate), but you really need a different - and far >>>>>>>> simpler - mechanism. The trust anchor store is >> implicitly linked >>>>>>>> to >>>>>>>> path discovery and validation, which are not relevant here >>>>>>>> since a >>>>>>>> directly trusted certificate cannot be validated. With a >>>>>>>> directly >>>>>>>> trusted certificate, there is also no mechanism to validate >>>>>>>> status >>>>>>>> information. >>>>>>>> >>>>>>>> To further complicate matters, storing the certificate >> you wish >>>>>>>> to >>>>>>>> directly trust in the trust anchor store implies that it is >>>>>>>> trusted >>>>>>>> to issue certificates as well. The path validation inputs >>>>>>>> specified >>>>>>>> in 6.1.1 (d) consider only four aspects of a trust >> anchor (name, >>>>>>>> public key algorithm, public key, and parameters if >> needed). The >>>>>>>> assumption is that the trust anchor's authority to issue >>>>>>>> certificates was verified based on an out-of-band >> trust mechanism >>>>>>>> (which is out of scope for 5280). This makes sense >> since a trust >>>>>>>> anchor might have distributed a v1 certificate (which does not >>>>>>>> include extensions). >>>>>>>> >>>>>>>> As others have noted, direct trust also implies an out-of-band >>>>>>>> trust >>>>>>>> mechanism. I received the EE certificate from a trusted source >>>>>>>> so I >>>>>>>> can trust the binding between the subject name and the key; >>>>>>>> issuer >>>>>>>> name and the signature are irrelevant. If the certificate >>>>>>>> status >>>>>>>> matters, I am also depending on an out-of-band mechanism to >>>>>>>> inform >>>>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>>>> local storage provide the basis for security in this system... >>>>>>>> >>>>>>>> Trying to combine these two mechanisms using a single >> certificate >>>>>>>> store probably requires an additional flag on every entry to >>>>>>>> differentiate between directly trusted certificates and trust >>>>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Tim Polk >>>>>>>> >>>>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>>>> >>>>>>>>> Folks- >>>>>>>>> >>>>>>>>> I am hoping someone can give me the answer to this. Does RFC >>>>>>>>> 5280 >>>>>>>>> adress the case where an end-entity certificate (not >> a CA cert) >>>>>>>>> is >>>>>>>>> installed in the trust anchor list by the user accepting the >>>>>>>>> presented cert as authoritative and then the cert is >>>>>>>>> subsequently >>>>>>>>> presented (in a later access to the site). There should be no >>>>>>>>> path >>>>>>>>> search, since the presented cert is in the trust >> anchor list. >>>>>>>>> So, >>>>>>>>> where is it defined to accept the end-entity cert? >>>>>>>>> >>>>>>>>> Thanks ---- Bob >>>>>>>>> >>>>>>>>> Bob Bell >>>>>>>>> Cisco Systems, Inc. >>>>>>>>> 576 S. Brentwood Ln. >>>>>>>>> Bountiful, UT 84010 >>>>>>>>> 801-294-3034 (v) >>>>>>>>> 801-294-3023 (f) >>>>>>>>> 801-971-4200 (c) >>>>>>>>> rtbell@cisco.com >>>>>>>>> >> ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From owner-ietf-pkix@mail.imc.org Wed Jun 18 06:23:44 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2175C3A6821 for ; Wed, 18 Jun 2008 06:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E-czeg9bOm4 for ; Wed, 18 Jun 2008 06:23:42 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 531AC3A69D7 for ; Wed, 18 Jun 2008 06:23:42 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5ICdPnJ000877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 05:39:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5ICdP5e000876; Wed, 18 Jun 2008 05:39:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5ICdMW4000836 for ; Wed, 18 Jun 2008 05:39:23 -0700 (MST) (envelope-from bodomoeller@googlemail.com) Received: by fg-out-1718.google.com with SMTP id l26so120580fgb.26 for ; Wed, 18 Jun 2008 05:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=oZ6I7iR3H7wOeUbIPIMF9KQ5g+pfvt5JLot8xz19OwU=; b=ms3yNonnvHXJ87W0TMUOFHCLH+ypC/w8q7lN5hQPOi90iZqRkIW+TyO4mJ5sz6WVCh 98wJ4TGPHMvKPl24UkSkqTtdTRNoOEAmBmcJuyzU5b3R3e6frsIX6EvNMZwX1obACoFK mdt494i5FLDduAt326xReTXLfKrjUbyMLbRzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=knUncAZU0vEFNKWMrguI7bKbarXUwA8pj5m36KJJuv8OUlL3JuvWS8/EXnw2SoMAk6 dm6RA0PjiwrqfhKh37yovtafZKqtcmcmFJ3BUNmUkGY+6Zimo2nyM1KLqlLshyg3b9m8 tNJY0cM0xKe6dNs4VWvEJVzM/keL5ShWBIb6E= Received: by 10.86.26.11 with SMTP id 11mr629586fgz.23.1213792762022; Wed, 18 Jun 2008 05:39:22 -0700 (PDT) Received: by 10.86.87.8 with HTTP; Wed, 18 Jun 2008 05:39:21 -0700 (PDT) Message-ID: <47015c2b0806180539q287a9c65kafc0167c342f6e5c@mail.gmail.com> Date: Wed, 18 Jun 2008 14:39:21 +0200 From: "Bodo Moeller" To: "Peter Gutmann" Subject: Re: RFC 5280 Question Cc: pritikin@cisco.com, SChokhani@cygnacom.com, ietf-pkix@imc.org, rtbell@cisco.com, tim.polk@nist.gov In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 054d6235e9ae9771 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Jun 13, 2008 at 12:52 PM, Peter Gutmann wrote: > "Santosh Chokhani" writes: >>The text you cite does not apply to trust anchor. Please see X.509 and RFC >>5280 path validation text. Nothing needs to be verified from a trust anchor. > Right, but when I checked about two years ago a significant number of PKI > implementors weren't even aware that this crazy requirement exists, let alone > implemented it in their code (when alerted to the requirement, several said > they would explicitly not implement it because it constituted broken behaviour > and they didn't want to deal with the customer support issues). I don't think that there is a *requirement* not to verify anything for the trust anchor. It's just that a self-signed certificate contains various fields beyond what constitutes the actual trust anchor. If you decide to interpret these fields in some context, this would be part of the out-of-bands handling of trust anchors. Alternatively, use the self-signed certificate twice: First, extract just the trust anchor information from it; second, include the complete certificate into the certification path that you are going to validate. Then you'll verify the self-signed certificate using the trust anchor information obtained from itself, in a way uniform with how any other certificate would be handled. Is there anything in the specifications that would disallow this behavior? I think it's just not mandated -- despite this: > The only > reason I know it exists was because someone on the X.509 standards committee > told me about it. I asked for a reference, because I couldn't believe that > explicitly ignoring everything in a root cert was required by the standard, > and they said they'd get back to me. Two weeks later they'd managed to find > it in the spec, and this was one of the people responsible for writing it! which is somewhat unspecific and doesn't necessarily sound like you got definitive information. > So in general proceeding under the assumption that many (most?) > implementations aren't going to do ignore checking of root certs/trust anchors > is safe. Or if you want to be strict about it, proceeding under the > assumption that whether an implementation checks or not is pretty much a > coin-toss is safe. If, as a CA, you want to make sure that every bit of information in your CA certificate gets checked just like a certificate in the certification path without having to rely on out-of-band information, do put it (the information) into the certification path by using an intermediate CA certificate with appropriate settings. Otherwise anyone could reasonably strip down the self-signed certificate to just the trust anchor information and use just that for validiation. Bodo From owner-ietf-pkix@mail.imc.org Wed Jun 18 06:57:10 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75D33A680D for ; Wed, 18 Jun 2008 06:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trzcHCwj70Rv for ; Wed, 18 Jun 2008 06:57:07 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A02903A67E2 for ; Wed, 18 Jun 2008 06:57:06 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IDGLDd014783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 06:16:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IDGLgo014781; Wed, 18 Jun 2008 06:16:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp131.rog.mail.re2.yahoo.com (smtp131.rog.mail.re2.yahoo.com [206.190.53.36]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5IDGJpx014764 for ; Wed, 18 Jun 2008 06:16:20 -0700 (MST) (envelope-from thierry.moreau@connotech.com) Received: (qmail 48403 invoked from network); 18 Jun 2008 13:16:19 -0000 Received: from unknown (HELO connotech.com) (t2i6@rogers.com@209.148.165.15 with plain) by smtp131.rog.mail.re2.yahoo.com with SMTP; 18 Jun 2008 13:16:19 -0000 X-YMail-OSG: lTWEM.sVM1kR1158iyY_j6mfRQF9g8w1uI2AKqqeeZqMQU4cAf2UOpqCvfOp.3Bv.w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48590B2F.3030000@connotech.com> Date: Wed, 18 Jun 2008 08:18:39 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bodo Moeller CC: Peter Gutmann , pritikin@cisco.com, SChokhani@cygnacom.com, ietf-pkix@imc.org, rtbell@cisco.com, tim.polk@nist.gov Subject: Re: RFC 5280 Question References: <47015c2b0806180539q287a9c65kafc0167c342f6e5c@mail.gmail.com> In-Reply-To: <47015c2b0806180539q287a9c65kafc0167c342f6e5c@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bodo Moeller wrote: > > Alternatively, use the self-signed certificate twice: First, extract > just the trust anchor information from it; second, include the > complete certificate into the certification path that you are going to > validate. Then you'll verify the self-signed certificate using the > trust anchor information obtained from itself, in a way uniform with > how any other certificate would be handled. Is there anything in the > specifications that would disallow this behavior? See X.509 (I checked the 08/2005 edition), section 10.5.1 "Basic Certificate Checks": "Self-signed certificates, if encountered in the path, are ignored" -- - Thierry Moreau From owner-ietf-pkix@mail.imc.org Wed Jun 18 07:49:25 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88DBF3A67AC for ; Wed, 18 Jun 2008 07:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pheDRL5lFNr for ; Wed, 18 Jun 2008 07:49:24 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E84783A680D for ; Wed, 18 Jun 2008 07:49:23 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IEBGS2027832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 07:11:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IEBGlC027831; Wed, 18 Jun 2008 07:11:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from maiev.nerim.net (maiev.ipv6.nerim.net [IPv6:2001:7a8:1:1::89]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IEBEKq027814 for ; Wed, 18 Jun 2008 07:11:15 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by maiev.nerim.net (Postfix) with ESMTP id 0480AB8229; Wed, 18 Jun 2008 16:11:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id DCF994429C; Wed, 18 Jun 2008 16:11:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHfr65FpGxI8; Wed, 18 Jun 2008 16:11:04 +0200 (CEST) Received: from [10.0.1.15] (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with ESMTP id EBC354429B; Wed, 18 Jun 2008 16:11:03 +0200 (CEST) Message-ID: <48591777.4060609@cryptolog.com> Date: Wed, 18 Jun 2008 16:11:03 +0200 From: Julien Stern User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Peter Gutmann Cc: bmoeller@acm.org, ietf-pkix@imc.org, pritikin@cisco.com, rtbell@cisco.com, SChokhani@cygnacom.com, tim.polk@nist.gov Subject: Re: RFC 5280 Question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Gutmann wrote: > "Bodo Moeller" writes: > >> I don't think that there is a *requirement* not to verify anything for the >> trust anchor. > > Nor did I, until the X.509 person told me there was. See section 3.3.60 of > the spec: > > 3.3.60 trust anchor: A trust anchor is a set of the following information in > addition to the public key: algorithm identifier, public key parameters (if > applicable), distinguished name of the holder of the associated private key > (i.e., the subject CA) and optionally a validity period. The trust anchor > may be provided in the form of a self-signed certificate. A trust anchor is > trusted by a certificate using system and used for validating certificates > in certification paths. > > Since trust anchors are typically provided in the form of self-signed CA roots > (as the text points out), what the text in effect says is "Ignore everything > in the CA root cert except the key and DN (and optionally validity)". > > This requirement has come as a considerable surprise to pretty much everyone > I've pointed it out to. Peter, Sorry to say it this way, but they have probably then never read X.509, nor RFC 3280, nor RFC 5280 :) From RFC 3280: Among the 7 inputs to the validation algorithms: ------ (d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor information includes: (1) the trusted issuer name, (2) the trusted public key algorithm, (3) the trusted public key, and (4) optionally, the trusted public key parameters associated with the public key. The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate. The trusted anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure. If the trusted public key algorithm requires parameters, then the parameters are provided along with the trusted public key. ------ However, I believe their considerable surprise may come from two sources: 1) RFC 2459 was not exactly crystal clear on trust anchors 2) In RFC 5280, page 90, it says: An implementation MAY augment the algorithm presented in Section 6.1 to further limit the set of valid certification paths that begin with a particular trust anchor... Thus, the path validation algorithm presented in Section 6.1 defines the minimum conditions for a path to be considered valid. So, my reading is that in RFC 5280 nothing PREVENTS you from using all the information contained in a certificate used as an envelope for a Trust Anchor. Note that this actually differs from X.509 as far as my understanding goes: X.509 does not state that one may augment the algorithm to restrict the valid outputs to the validation algorithm. All in all, what can cause "considerable surprise" in my humble opinion, is that one is *allowed* to use the certificate information you mentioned by RFC 5280, but not by X.509. >> Alternatively, use the self-signed certificate twice: First, extract just the >> trust anchor information from it; second, include the complete certificate >> into the certification path that you are going to validate. Unfortunately, you are supposed to ignore self-issued certificates during path processing, so this does not work. > That requires that you know that this craziness even exists. > > Peter. Regards, -- Julien From owner-ietf-pkix@mail.imc.org Wed Jun 18 08:51:33 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D933A67DD for ; Wed, 18 Jun 2008 08:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+hW-zki8tPe for ; Wed, 18 Jun 2008 08:51:32 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7CAE13A6A28 for ; Wed, 18 Jun 2008 08:51:31 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IF2REQ048274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 08:02:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IF2R0M048273; Wed, 18 Jun 2008 08:02:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IF2OCw048265 for ; Wed, 18 Jun 2008 08:02:26 -0700 (MST) (envelope-from bodomoeller@googlemail.com) Received: by fg-out-1718.google.com with SMTP id l26so156362fgb.26 for ; Wed, 18 Jun 2008 08:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=31av3imGKFV8vMx3XeCRY63aofJ6o79UJsyte29GdQc=; b=WImffoL0cANWbn3GsOkUqorWVpGF2QslnShkpqSsRGrABcDp6KSMF5utrGfOe+M1MH 1LmNvs+ZEW2NxISns0IpbprG/QU125kh5rkYaHske7mIfl/qSRZXseSRcs9kFIc+c4Jd s1tUDEGAdbPEnN3GFJTHlAunxcTFMGfohqW84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=AMb0kI8SqyyWyBkuG3I2VeMYbZfM0r/Ck4hhaiYib5+xFzovWgH/s0TYX7+582zRxd XhuHoRPvUtVoP/GGq1CKkrn75QlMV2FVzPk4b6lp2mDzRZ45Qxl4hFxxOKGeXRnAsAt/ Q2spdO4k5Rw6mrAa2sHmxKjGaMSI/8+G1ljSw= Received: by 10.86.80.5 with SMTP id d5mr766583fgb.26.1213801343940; Wed, 18 Jun 2008 08:02:23 -0700 (PDT) Received: by 10.86.87.8 with HTTP; Wed, 18 Jun 2008 08:02:23 -0700 (PDT) Message-ID: <47015c2b0806180802m6a4c8bcaladebbad051f85106@mail.gmail.com> Date: Wed, 18 Jun 2008 17:02:23 +0200 From: "Bodo Moeller" To: "Thierry Moreau" Subject: Re: RFC 5280 Question Cc: "Peter Gutmann" , pritikin@cisco.com, SChokhani@cygnacom.com, ietf-pkix@imc.org, rtbell@cisco.com, tim.polk@nist.gov In-Reply-To: <48590B2F.3030000@connotech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47015c2b0806180539q287a9c65kafc0167c342f6e5c@mail.gmail.com> <48590B2F.3030000@connotech.com> X-Google-Sender-Auth: 979a4812faceea0f Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jun 18, 2008 at 3:18 PM, Thierry Moreau wrote: > Bodo Moeller wrote: >> Alternatively, use the self-signed certificate twice: First, extract >> just the trust anchor information from it; second, include the >> complete certificate into the certification path that you are going to >> validate. Then you'll verify the self-signed certificate using the >> trust anchor information obtained from itself, in a way uniform with >> how any other certificate would be handled. Is there anything in the >> specifications that would disallow this behavior? > See X.509 (I checked the 08/2005 edition), section 10.5.1 "Basic Certificate > Checks": "Self-signed certificates, if encountered in the path, are ignored" This text wasn't present in the 03/2000 edition that I was looking at (it just has the obvious stuff about not counting them for pathLenConstraints). However, I've been able to track it down to the following Defect Report: http://www.x500standard.com/uploads/Defects/DR_285.pdf The Defect Report claims that the requirement to ignore self-signed certificates follows from clause 8.1.5, which reads as follows: 8.1.5 Self-issued certificates There are three circumstances under which a certification authority may issue a certificate to itself: a) as a convenient way of encoding its public key for communication to, and storage by, its certificate users; b) for certifying key usages other than certificate and CRL signing (such as time-stamping); and c) for replacing its own expired certificates. These types of certificate are called self-issued certificates, and they can be recognized by the fact that the issuer and subject names present in them are identical. For purposes of path validation, self-issued certificates of type a) are verified with the public key contained in them, and if they are encountered in the path, they shall be ignored. Self-issued certificates of type b) may only appear as end certificates in a path, and shall be processed as end certificates. Self-issued certificates of type c) (also known as self-issued intermediate certificates) may appear as intermediate certificates in a path. As a matter of good practice, when replacing a key that is on the point of expiration, a certification authority should request the issuance of any in-bound cross-certificates that it requires for its replacement public key before using the key. Nevertheless, if self-issued certificates are encountered in the path, they shall be processed as intermediate certificates, with the following exception: they do not contribute to the path length for purposes of processing the pathLenConstraint component of the basicConstraints extension and the skip-certificates values associated with the policy-mapping-inhibit-pending and explicit-policy-pending indicators. How would you tell apart a type a) self-signed certificate from a type c) self-signed certificate? Type a) would have to be ignored, type c) not. The Technical Corrigendum resulting from the Defect Report doesn't change the wording in 8.1.5. Why would you even need reason c) given that the dates in the original certificate would be ignored by the prescribed handling for type a) self-signed certificates? Does the 08/2005 edition still say that you must process type c) self-signed certifcates (8.1.5) except that you must ignore them (10.5.1)? The only thing that is clear form this is that CAs creating self-signed certificates in the intent to convey any information beyond their public key, key usages, and possibly key expiration operate outside of the scope of X.509. Anything else would not be one of the "circumstances under which a certification authority may issue a certificate to itself". Bodo From owner-ietf-pkix@mail.imc.org Wed Jun 18 09:00:45 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAEF43A6AF5 for ; Wed, 18 Jun 2008 09:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.819 X-Spam-Level: X-Spam-Status: No, score=0.819 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO3esCEpF8Kz for ; Wed, 18 Jun 2008 09:00:44 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 092303A6A28 for ; Wed, 18 Jun 2008 09:00:43 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IFFsRW052204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 08:15:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IFFseZ052203; Wed, 18 Jun 2008 08:15:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IFFq5C052188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jun 2008 08:15:53 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5IFFgV1010376 for ; Wed, 18 Jun 2008 11:15:43 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m5IFFe7v004608 for ; Wed, 18 Jun 2008 11:15:40 -0400 Message-ID: <48592651.8040600@nist.gov> Date: Wed, 18 Jun 2008 11:14:25 -0400 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.12 (X11/20080306) MIME-Version: 1.0 To: pkix Subject: Re: RFC 5280 Question References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter,

The text that you quoted does not constitute a *requirement* to ignore everything in the self-signed certificate other than name and key information.

The X.509 path validation algorithm specifies several inputs (e.g., initial-policy-mapping-inhibit, initial-permitted-subtrees-set, etc.).  The final paragraph of section 6.2 of RFC 5280 notes that implementations may choose to use the contents of extensions in self-signed "trust anchor" certificates as the basis for determining the values of these inputs, and there is nothing in X.509 that contradicts this.  It is true, however, that the self-signed certificate is not supposed to be processed as if it were the first certificate in the certification path and any use of the certificate except as the source of trust anchor information (name and key information) is outside the scope of the path validation algorithm.

Bodo Moeller wrote:
If, as a CA, you want to make sure that every bit of information in
your CA certificate gets checked just like a certificate in the
certification path without having to rely on out-of-band information,
do put it (the information) into the certification path by using an
intermediate CA certificate with appropriate settings.  Otherwise
anyone could reasonably strip down the self-signed certificate to just
the trust anchor information and use just that for validiation.

There is no need to create an intermediate CA for the sole purpose of issuing it an "intermediate CA certificate with appropriate settings".  Rather than placing a nameConstraints extension in a self-signed "trust anchor" certificate and relying on clients to process that extension, the CA may simply (1) place such an extension in every cross-certificate it issues and (2) refrain from issuing any certificates with subject names that do not satisfy the name constraint.  Rather than placing a basicConstraints extension with a pathLenConstraint of 0 in a self-signed certificate, the CA may simply refrain from issuing any cross-certificates (for a pathLenConstraint of 1 or more, the CA would simply need to impose the appropriate pathLenConstraint in any cross-certificates it issues).

This is why I see no benefit in including information other than name and key information in the self-signed certificate and why I see no benefit in processing that information. The first certificate in the certification path will always be issued by the CA that generated the self-signed certificate, and there is no reason that the CA needs to place information in the self-signed certificate to impose constraints on itself.

Dave

Peter Gutmann wrote: 
"Bodo Moeller" <bmoeller@acm.org> writes:
 don't think that there is a *requirement* not to verify anything for the
trust anchor.
    

Nor did I, until the X.509 person told me there was.  See section 3.3.60 of
the spec:

  3.3.60 trust anchor: A trust anchor is a set of the following information in
  addition to the public key: algorithm identifier, public key parameters (if
  applicable), distinguished name of the holder of the associated private key
  (i.e., the subject CA) and optionally a validity period. The trust anchor
  may be provided in the form of a self-signed certificate. A trust anchor is
  trusted by a certificate using system and used for validating certificates
  in certification paths.

Since trust anchors are typically provided in the form of self-signed CA roots 
(as the text points out), what the text in effect says is "Ignore everything 
in the CA root cert except the key and DN (and optionally validity)".

This requirement has come as a considerable surprise to pretty much everyone
I've pointed it out to.
  
Alternatively, use the self-signed certificate twice: First, extract just the
trust anchor information from it; second, include the complete certificate
into the certification path that you are going to validate.
    

That requires that you know that this craziness even exists.

Peter.
From owner-ietf-pkix@mail.imc.org Wed Jun 18 09:01:52 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7C33A6B03 for ; Wed, 18 Jun 2008 09:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZcIZncFFd0t for ; Wed, 18 Jun 2008 09:01:51 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F1E4D3A6AFD for ; Wed, 18 Jun 2008 09:01:50 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IFJWtk053104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 08:19:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IFJVMZ053103; Wed, 18 Jun 2008 08:19:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IFJTtQ053048 for ; Wed, 18 Jun 2008 08:19:30 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 09C194808C7; Thu, 19 Jun 2008 03:19:29 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dih5IS6Y87LG; Thu, 19 Jun 2008 03:19:28 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 296A74808C5; Thu, 19 Jun 2008 03:19:28 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D41F919EC0BA; Thu, 19 Jun 2008 03:19:18 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1K8zRO-0006yK-Og; Thu, 19 Jun 2008 03:19:18 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bmoeller@acm.org, thierry.moreau@connotech.com Subject: Re: RFC 5280 Question Cc: ietf-pkix@imc.org, pgut001@cs.auckland.ac.nz, pritikin@cisco.com, rtbell@cisco.com, SChokhani@cygnacom.com, tim.polk@nist.gov In-Reply-To: <47015c2b0806180802m6a4c8bcaladebbad051f85106@mail.gmail.com> Message-Id: Date: Thu, 19 Jun 2008 03:19:18 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Bodo Moeller" writes: >The only thing that is clear form this is that CAs creating self-signed >certificates in the intent to convey any information beyond their public key, >key usages, and possibly key expiration operate outside of the scope of X.509. I think you've got it reversed, it's more that X.509 is operating outside the scope of reality :-). I'm not really sure how to reconcile the two [0], although perhaps the spec could at least include a warning that the behaviour of real-world implementations is unlikely to correspond to the spec. People should at least be made aware of the fact that it's more or less random whether any given implementation does this (although the random outcome does seem strongly biased towards "No"). Peter. [0] Well, I have a pretty good idea how it'll work out based on long-standing precedent: X.509 will continue to require bizarre behaviour and most of the world will continue to ignore it, in this case because they don't even know that the requirement for the behaviour exists. From owner-ietf-pkix@mail.imc.org Wed Jun 18 10:50:59 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146CA3A68D2 for ; Wed, 18 Jun 2008 10:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmQsYmbETEa5 for ; Wed, 18 Jun 2008 10:50:58 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7C3743A67D9 for ; Wed, 18 Jun 2008 10:50:57 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IHFr00094308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 10:15:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IHFrwm094307; Wed, 18 Jun 2008 10:15:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IHFpZn094282 for ; Wed, 18 Jun 2008 10:15:52 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id F417528C0E9; Wed, 18 Jun 2008 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-tac-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080618171501.F417528C0E9@core3.amsl.com> Date: Wed, 18 Jun 2008 10:15:01 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Traceable Anonymous Certificate Author(s) : S. Park, H. Park, Y. Won, J. Lee, S. Kent Filename : draft-ietf-pkix-tac-00.txt Pages : 21 Date : 2008-6-4 Public Key Infrastructure (PKI) provides a powerful means of authenticating individuals, organizations, and computers (e.g., web servers). However, when individuals use certificates to access resources on the public Internet, there are legitimate concerns about personal privacy, and thus there are increasing demands for privacy enhancing techniques on the Internet. In a PKI, an authorized entity such as a certification Authority (CA) or a Registration Authority (RA) may be perceived, from a privacy perspective, as a "big brother," even when a CA issues a certificate containing a Subject name that is a pseudonym. This is because such entities can always map a pseudonym in a certificate they issued to the name of the real user to whom it was issued. This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request protocols such as PKCS10 [2] CRMF [3]. The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Anonymous Issuer) and the other for validating the contents of a certificate (Blind Issuer). The end-entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-tac-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-tac-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-18101128.I-D@ietf.org> --NextPart-- From owner-ietf-pkix@mail.imc.org Wed Jun 18 10:54:33 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47D83A699C for ; Wed, 18 Jun 2008 10:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JckbrhdsmhxA for ; Wed, 18 Jun 2008 10:54:33 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 46C4E3A687E for ; Wed, 18 Jun 2008 10:54:31 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IDOvpt016055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 06:24:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IDOvZV016054; Wed, 18 Jun 2008 06:24:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IDOtSK016036 for ; Wed, 18 Jun 2008 06:24:56 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D6F674808B3; Thu, 19 Jun 2008 01:24:54 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMve4j2sj503; Thu, 19 Jun 2008 01:24:54 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 16A784808A5; Thu, 19 Jun 2008 01:24:53 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 15EC119EC0BA; Thu, 19 Jun 2008 01:24:47 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1K8xeY-0001Q4-UI; Thu, 19 Jun 2008 01:24:46 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bmoeller@acm.org, pgut001@cs.auckland.ac.nz Subject: Re: RFC 5280 Question Cc: ietf-pkix@imc.org, pritikin@cisco.com, rtbell@cisco.com, SChokhani@cygnacom.com, tim.polk@nist.gov In-Reply-To: <47015c2b0806180539q287a9c65kafc0167c342f6e5c@mail.gmail.com> Message-Id: Date: Thu, 19 Jun 2008 01:24:46 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Bodo Moeller" writes: >I don't think that there is a *requirement* not to verify anything for the >trust anchor. Nor did I, until the X.509 person told me there was. See section 3.3.60 of the spec: 3.3.60 trust anchor: A trust anchor is a set of the following information in addition to the public key: algorithm identifier, public key parameters (if applicable), distinguished name of the holder of the associated private key (i.e., the subject CA) and optionally a validity period. The trust anchor may be provided in the form of a self-signed certificate. A trust anchor is trusted by a certificate using system and used for validating certificates in certification paths. Since trust anchors are typically provided in the form of self-signed CA roots (as the text points out), what the text in effect says is "Ignore everything in the CA root cert except the key and DN (and optionally validity)". This requirement has come as a considerable surprise to pretty much everyone I've pointed it out to. >Alternatively, use the self-signed certificate twice: First, extract just the >trust anchor information from it; second, include the complete certificate >into the certification path that you are going to validate. That requires that you know that this craziness even exists. Peter. From owner-ietf-pkix@mail.imc.org Wed Jun 18 12:10:58 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51BC3A68F6 for ; Wed, 18 Jun 2008 12:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jc9exWQ3W-eB for ; Wed, 18 Jun 2008 12:10:57 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 08B6D3A68D2 for ; Wed, 18 Jun 2008 12:10:56 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IId3il020611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 11:39:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IId3Y8020610; Wed, 18 Jun 2008 11:39:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IId2jb020603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jun 2008 11:39:03 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5IIcv0Y004412 for ; Wed, 18 Jun 2008 14:38:57 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m5IIcrHL031844 for ; Wed, 18 Jun 2008 14:38:53 -0400 Message-ID: <485955F0.7080403@nist.gov> Date: Wed, 18 Jun 2008 14:37:36 -0400 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.12 (X11/20080306) MIME-Version: 1.0 To: pkix Subject: Re: RFC 5280 Question References: <48594263.8000100@pobox.com> In-Reply-To: <48594263.8000100@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This again does not contradict X.509, since the authorityKeyIdentifier and subjectKeyIdentifier extensions are not processed during path validation. They are only used to add in path discovery. The same is true of the id-ad-caIssuers access method of the authorityInfoAccess extension and the id-ad-caRepository access method of the subjectInfoAccess extension. Despite Peter's claim, there is nothing in either X.509 or RFC 5280 that says that client software must not make use of extension information in self-signed certificates. X.509 doesn't even prevent the use of this information in a way that would affect the outcome of path validation. However, the only way to use this information *in path validation* in a manner that is consistent to the path validation algorithm in X.509 is to use the information as a basis for deciding what values to specify for the path validation inputs (e.g., initial-policy-mapping-inhibit, initial-permitted-subtrees-set, etc.). The X.509 path validation algorithm specifies 8 inputs in addition to the certification path and the trust anchor information (name and key information), and it says nothing about what basis a client may use for deciding what values to specify for these inputs. There is nothing in X.509 to prevent a client from choosing a value for initial-policy-mapping-inhibit based on the outcome of a coin flip (even though that would be a very odd implementation decision). Similarly, there is nothing in X.509 to prevent a client from choosing a value for initial-policy-mapping-inhibit based on the presence or absence of a policyConstraints extension in the self-signed certificate from which trust anchor information was extracted. Mike wrote: > I think that more implementations of PKIX will use the other > information in > self-signed certificates than not. Consider the text in section 4.2.1.1 > about the Authority Key Identifier: > > The keyIdentifier field of the authorityKeyIdentifier extension MUST > be included in all certificates generated by conforming CAs to > facilitate certification path construction. There is one exception; > where a CA distributes its public key in the form of a "self-signed" > certificate, the authority key identifier MAY be omitted. The > signature on a self-signed certificate is generated with the private > key associated with the certificate's subject public key. (This > proves that the issuer possesses both the public and private keys.) > In this case, the subject and authority key identifiers would be > identical, but only the subject key identifier is needed for > certification path building. > > This implies that self-signed certificates will have at least a > subject key > identifier, and optionally an authority key identifier. So even the > authors > of RFC 5280 seem to believe you should make use of the extension > information > in self-signed certificates. > > Mike From owner-ietf-pkix@mail.imc.org Wed Jun 18 13:28:23 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF783A6914 for ; Wed, 18 Jun 2008 13:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUzRUkjQOXnh for ; Wed, 18 Jun 2008 13:27:47 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3F5C228C1D3 for ; Wed, 18 Jun 2008 13:27:46 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IHFln2094259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 10:15:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IHFlT4094258; Wed, 18 Jun 2008 10:15:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IHFj3q094239 for ; Wed, 18 Jun 2008 10:15:46 -0700 (MST) (envelope-from mike-list@pobox.com) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 7D15715081; Wed, 18 Jun 2008 13:15:44 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 9AFE21503E; Wed, 18 Jun 2008 13:15:26 -0400 (EDT) Message-ID: <48594263.8000100@pobox.com> Date: Wed, 18 Jun 2008 10:14:11 -0700 From: Mike User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Peter Gutmann CC: bmoeller@acm.org, thierry.moreau@connotech.com, ietf-pkix@imc.org, pritikin@cisco.com, rtbell@cisco.com, SChokhani@cygnacom.com, tim.polk@nist.gov Subject: Re: RFC 5280 Question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 2F8B3AA8-3D5A-11DD-9506-CE28B26B55AE-38729857!a-sasl-fastnet.pobox.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> The only thing that is clear form this is that CAs creating self-signed >> certificates in the intent to convey any information beyond their public key, >> key usages, and possibly key expiration operate outside of the scope of X.509. > > I think you've got it reversed, it's more that X.509 is operating outside the > scope of reality :-). I'm not really sure how to reconcile the two [0], > although perhaps the spec could at least include a warning that the behaviour > of real-world implementations is unlikely to correspond to the spec. People > should at least be made aware of the fact that it's more or less random > whether any given implementation does this (although the random outcome does > seem strongly biased towards "No"). I think that more implementations of PKIX will use the other information in self-signed certificates than not. Consider the text in section 4.2.1.1 about the Authority Key Identifier: The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction. There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted. The signature on a self-signed certificate is generated with the private key associated with the certificate's subject public key. (This proves that the issuer possesses both the public and private keys.) In this case, the subject and authority key identifiers would be identical, but only the subject key identifier is needed for certification path building. This implies that self-signed certificates will have at least a subject key identifier, and optionally an authority key identifier. So even the authors of RFC 5280 seem to believe you should make use of the extension information in self-signed certificates. Mike > Peter. > > [0] Well, I have a pretty good idea how it'll work out based on long-standing > precedent: X.509 will continue to require bizarre behaviour and most of > the world will continue to ignore it, in this case because they don't > even know that the requirement for the behaviour exists. From owner-ietf-pkix@mail.imc.org Thu Jun 19 11:51:47 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF933A698B for ; Thu, 19 Jun 2008 11:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daHQ8V3L43Da for ; Thu, 19 Jun 2008 11:51:45 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 57FD03A6992 for ; Thu, 19 Jun 2008 11:51:44 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5JHuhTg003739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2008 10:56:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5JHuh68003738; Thu, 19 Jun 2008 10:56:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5JHuf2U003722 for ; Thu, 19 Jun 2008 10:56:42 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1K9ONE-0000eP-5R for ietf-pkix@imc.org; Thu, 19 Jun 2008 13:56:40 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 19 Jun 2008 13:57:04 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: "other certs" extension straw poll Content-Type: multipart/alternative; boundary="============_-998224270==_ma============" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --============_-998224270==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, Back in December, Stephen Farrell sent a message to PKIX noting a problem that had been identified in the W3C, and proposing a solution in the form of a proposed extension. He published an individual I-D at this time. There was a little discussion on the list about this proposal in January, (a total of about a dozen messages). Stephen made a presentation on his proposal at the Phildelphia meeting in March and in response to some of the comments he received, Stephen revised his proposal to include additional details. There was agreement at the meeting that the discussion should be moved to the list, to determine of the work should proceed as a PKIX WG item, and if so, whether it would become experimental, standards track, or whatever. The I-D, which was released at the 02 rev level after the meeting, triggered additional discussion on the list that month, a total of 15 messages from a set of 5 individuals (including Stephen). Most of the messages in this thread were not supportive of the proposal for various reasons, e.g., argument about why one could not use the permanent identifier extension, or some other SAN, etc. I raised concerns about the lack of details for how an RP would use the data in this extension. Stephen has asked that we conduct a straw poll on the topic of accepting this as a WG item. I suggest that PKIX members review the current rev of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from April, and then send a message to this list over the next two weeks. (The straw poll will close on July 4.) This poll is not deciding whether the I-D in its current form will be adopted, but rather whether the I-D addresses a problem that PKIX wants to address AND that the document provides a suitable basis to begin addressing the problem. I request that poll responses be of the form: YES (to both questions) NO (to the first question) YES-BUT (yes to the first question, but NO to the second question) Thanks, Steve --============_-998224270==_ma============ Content-Type: text/html; charset="us-ascii" "other certs" extension straw poll
Folks,

Back in December, Stephen Farrell sent a message to PKIX noting a problem that had been identified in the W3C, and proposing a solution in the form of a proposed extension. He published an individual I-D at this time. There was a little discussion on the list about this proposal in January, (a total of about a dozen messages). Stephen made a presentation on his proposal at the Phildelphia meeting in March and in response to some of the comments he received, Stephen revised his proposal to include additional details.  There was agreement at the meeting that the discussion should be moved to the list, to determine of the work should proceed as a PKIX WG item, and if so, whether it would become experimental, standards track, or whatever.

The I-D, which was released at the 02 rev level after the meeting, triggered  additional discussion on the list that month, a total of 15 messages from a set of 5 individuals (including Stephen). Most of the messages in this thread were not supportive of the proposal for various reasons, e.g., argument about why one could not use the permanent identifier extension, or some other SAN, etc. I raised concerns about the lack of details for how an RP would use the data in this extension.

Stephen has asked that we conduct a straw poll on the topic of accepting this as a WG item.  I suggest that PKIX members review the current rev of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from April, and then send a message to this list over the next two weeks.  (The straw poll will close on July 4.)

This poll is not deciding whether the I-D in its current form will be adopted, but rather whether the I-D addresses a problem that PKIX wants to address AND that the document provides a suitable basis to begin addressing the problem.

I request that poll responses be of the form:

        YES (to both questions)
        NO (to the first question)
        YES-BUT (yes to the first question, but NO to the second question)

Thanks,

Steve



--============_-998224270==_ma============-- From owner-ietf-pkix@mail.imc.org Thu Jun 19 15:46:37 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE2F3A698D for ; Thu, 19 Jun 2008 15:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od+0FpI0bCJO for ; Thu, 19 Jun 2008 15:46:36 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 496CF3A693A for ; Thu, 19 Jun 2008 15:46:33 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5JLj5RL072665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2008 14:45:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5JLj5fG072664; Thu, 19 Jun 2008 14:45:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5JLj3Ei072647 for ; Thu, 19 Jun 2008 14:45:04 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 4AAE23A69EB; Thu, 19 Jun 2008 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080619214502.4AAE23A69EB@core3.amsl.com> Date: Thu, 19 Jun 2008 14:45:02 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Author(s) : Q. Dang Filename : draft-ietf-pkix-sha2-dsa-ecdsa-04.txt Pages : 17 Date : 2008-6-19 This document supplements RFC 3279. It specifies algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384 or SHA- 512 as hashing algorithm. This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-sha2-dsa-ecdsa-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-19144431.I-D@ietf.org> --NextPart-- From owner-ietf-pkix@mail.imc.org Fri Jun 20 01:44:11 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6273A69BF for ; Fri, 20 Jun 2008 01:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igMyU9Z9Oijq for ; Fri, 20 Jun 2008 01:44:10 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7E3C53A68D0 for ; Fri, 20 Jun 2008 01:44:09 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5K88uqN081631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 01:08:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5K88uLV081630; Fri, 20 Jun 2008 01:08:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5K88qM3081592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 20 Jun 2008 01:08:54 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id 1F8B53278A; Fri, 20 Jun 2008 09:08:52 +0100 (IST) Received: from [10.87.48.6] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id m5K88mqR024979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Jun 2008 09:08:48 +0100 Message-ID: <485B659B.9040905@cs.tcd.ie> Date: Fri, 20 Jun 2008 09:08:59 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Stephen Kent CC: ietf-pkix@imc.org Subject: Re: "other certs" extension straw poll References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Canit-Stats-ID: 27841058 - 3f33528006ad (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: YES (to both). I think for balance I should point out that there have also been folks who've been supportive of this as well as those, (presumably including Steve:-), who have concerns. Basically, its a simple proposal to handle a particular problem for consumers of PKI, Stephen. Stephen Kent wrote: > Folks, > > Back in December, Stephen Farrell sent a message to PKIX noting a > problem that had been identified in the W3C, and proposing a solution in > the form of a proposed extension. He published an individual I-D at this > time. There was a little discussion on the list about this proposal in > January, (a total of about a dozen messages). Stephen made a > presentation on his proposal at the Phildelphia meeting in March and in > response to some of the comments he received, Stephen revised his > proposal to include additional details. There was agreement at the > meeting that the discussion should be moved to the list, to determine of > the work should proceed as a PKIX WG item, and if so, whether it would > become experimental, standards track, or whatever. > > The I-D, which was released at the 02 rev level after the meeting, > triggered additional discussion on the list that month, a total of 15 > messages from a set of 5 individuals (including Stephen). Most of the > messages in this thread were not supportive of the proposal for various > reasons, e.g., argument about why one could not use the permanent > identifier extension, or some other SAN, etc. I raised concerns about > the lack of details for how an RP would use the data in this extension. > > Stephen has asked that we conduct a straw poll on the topic of accepting > this as a WG item. I suggest that PKIX members review the current rev > of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from > April, and then send a message to this list over the next two weeks. > (The straw poll will close on July 4.) > > This poll is not deciding whether the I-D in its current form will be > adopted, but rather whether the I-D addresses a problem that PKIX wants > to address AND that the document provides a suitable basis to begin > addressing the problem. > > I request that poll responses be of the form: > > YES (to both questions) > NO (to the first question) > YES-BUT (yes to the first question, but NO to the second question) > > Thanks, > > Steve > > > From owner-ietf-pkix@mail.imc.org Fri Jun 20 09:37:35 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCAC3A685A for ; Fri, 20 Jun 2008 09:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48F8JVHrVDzg for ; Fri, 20 Jun 2008 09:37:29 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id CB2FE3A63D2 for ; Fri, 20 Jun 2008 09:37:28 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KFcXxt088633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 08:38:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5KFcX7Z088632; Fri, 20 Jun 2008 08:38:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KFcWYh088620 for ; Fri, 20 Jun 2008 08:38:33 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id m5KFcVTD025546 for ; Fri, 20 Jun 2008 11:38:31 -0400 (EDT) X-AuditID: 90333308-00001138000007c8-30-485bcef717f9 Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 11:38:31 -0400 Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jun 2008 11:38:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D2EB.B14EED05" Subject: RE: "other certs" extension straw poll Date: Fri, 20 Jun 2008 11:38:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "other certs" extension straw poll Thread-Index: AcjScyWAUSVAz9TwRJqdWP4hSIh3MQAdNWuA References: From: "Kemp, David P." To: X-OriginalArrivalTime: 20 Jun 2008 15:38:31.0244 (UTC) FILETIME=[B137F0C0:01C8D2EB] X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D2EB.B14EED05 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "The use of the new extension provides a way for the CA to signal to the application that the same end entity is involved, regardless of name changes. The new extension could also allow the web site operator to more easily change CA when renewing its certificate." =20 YES-BUT. =20 As previously discussed, I believe that the way for a CA to signal that the same entity is involved is to use the same unique name for that entity, regardless of any changes in other (e.g., DNS-based) names also assigned to that entity by that CA or other CAs. =20 Dave =20 =20 _____ =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Thursday, June 19, 2008 1:57 PM To: ietf-pkix@imc.org Subject: "other certs" extension straw poll =20 Folks, =20 Back in December, Stephen Farrell sent a message to PKIX noting a problem that had been identified in the W3C, and proposing a solution in the form of a proposed extension. He published an individual I-D at this time. There was a little discussion on the list about this proposal in January, (a total of about a dozen messages). Stephen made a presentation on his proposal at the Phildelphia meeting in March and in response to some of the comments he received, Stephen revised his proposal to include additional details. There was agreement at the meeting that the discussion should be moved to the list, to determine of the work should proceed as a PKIX WG item, and if so, whether it would become experimental, standards track, or whatever. =20 The I-D, which was released at the 02 rev level after the meeting, triggered additional discussion on the list that month, a total of 15 messages from a set of 5 individuals (including Stephen). Most of the messages in this thread were not supportive of the proposal for various reasons, e.g., argument about why one could not use the permanent identifier extension, or some other SAN, etc. I raised concerns about the lack of details for how an RP would use the data in this extension. =20 Stephen has asked that we conduct a straw poll on the topic of accepting this as a WG item. I suggest that PKIX members review the current rev of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from April, and then send a message to this list over the next two weeks. (The straw poll will close on July 4.) =20 This poll is not deciding whether the I-D in its current form will be adopted, but rather whether the I-D addresses a problem that PKIX wants to address AND that the document provides a suitable basis to begin addressing the problem. =20 I request that poll responses be of the form: =20 YES (to both questions) NO (to the first question) YES-BUT (yes to the first question, but NO to the second question) =20 Thanks, =20 Steve =20 =20 =20 ------_=_NextPart_001_01C8D2EB.B14EED05 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "other certs" extension straw poll

   = “The use of the new extension provides a way for the CA to signal = to

   the = application that the same end entity is involved, regardless = of

   = name changes.  The new extension could also allow the web site

   = operator to more easily change CA when renewing its = certificate.”

 

YES-BUT.

 

As previously discussed, I believe = that the way for a CA to signal that the same entity is involved is to use = the same unique name for that entity, regardless of any changes in other (e.g., = DNS-based) names also assigned to that entity by that CA or other = CAs.

 

Dave

 

 

From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent
Sent: Thursday, June 19, = 2008 1:57 PM
To: ietf-pkix@imc.org
Subject: "other = certs" extension straw poll

 

Folks,

 

Back in December, Stephen Farrell sent a message to PKIX noting = a problem that had been identified in the W3C, and proposing a solution in = the form of a proposed extension. He published an individual I-D at this = time. There was a little discussion on the list about this proposal in = January, (a total of about a dozen messages). Stephen made a presentation on his = proposal at the Phildelphia meeting in March and in response to some of the = comments he received, Stephen revised his proposal to include additional = details.  There was agreement at the meeting that the discussion should be moved = to the list, to determine of the work should proceed as a PKIX WG item, and if = so, whether it would become experimental, standards track, or = whatever.

 

The I-D, which was released at the 02 rev level after the = meeting, triggered  additional discussion on the list that month, a total of = 15 messages from a set of 5 individuals (including Stephen). Most of the = messages in this thread were not supportive of the proposal for various reasons, = e.g., argument about why one could not use the permanent identifier extension, = or some other SAN, etc. I raised concerns about the lack of details for how = an RP would use the data in this extension.

 

Stephen has asked that we conduct a straw poll on the topic of accepting this as a WG item.  I suggest that PKIX members review = the current rev of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from April, and then send a message to this list over = the next two weeks.  (The straw poll will close on July = 4.)

 

This poll is not deciding whether the I-D in its current form = will be adopted, but rather whether the I-D addresses a problem that PKIX wants = to address AND that the document provides a suitable basis to begin = addressing the problem.

 

I request that poll responses be of the = form:

 

        YES (to both questions)

        NO (to the = first question)

        YES-BUT (yes = to the first question, but NO to the second = question)

 

Thanks,

 

Steve

 

 

 

------_=_NextPart_001_01C8D2EB.B14EED05-- From owner-ietf-pkix@mail.imc.org Fri Jun 20 11:10:37 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAEF3A69DA for ; Fri, 20 Jun 2008 11:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MErq8B+dnbBJ for ; Fri, 20 Jun 2008 11:10:35 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 27BF13A699E for ; Fri, 20 Jun 2008 11:10:34 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KHc28k047505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 10:38:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5KHc2xn047504; Fri, 20 Jun 2008 10:38:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KHc1rf047490 for ; Fri, 20 Jun 2008 10:38:02 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id m5KHc15W003571 for ; Fri, 20 Jun 2008 13:38:01 -0400 (EDT) X-AuditID: 90333308-00001360000007c8-51-485beaf81be2 Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 13:38:00 -0400 Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jun 2008 13:38:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC 5280 Question Date: Fri, 20 Jun 2008 13:37:58 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjNnQc9+VKC384aThyaKi3ydMRsJQFU7jXg References: <48522C3F.4050103@cryptolog.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 20 Jun 2008 17:38:00.0946 (UTC) FILETIME=[62B1A520:01C8D2FC] X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Agreed. The distinction between a CA (a business entity) and a Certificate (a data object produced by that entity) seems obvious. Unlike "Certification Authority", "Trust Anchor" does not sound to me like the name of a business entity, so I would prefer to go with the TA Management definition of TA. If the entity that produces trust anchors needs a name, call it something else. But it's not clear that the TA-generating entity needs a name. The issuer of a self-signed certificate is a CA, and the properties of the CA do not suddenly change when that certificate is installed as a TA by the first relying party. When a path is validated using a certificate or just the four items of TA information specified in 5280, the TA is not "issued", it is configured by the application vendor, administrator, or user. I vote for Tom's second option. If it is necessary to explicitly refer to the generator of a certificate used as a TA, call it a TA Issuer, Anchor CA, or whatever. Dave -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Friday, June 13, 2008 4:29 PM To: Julien Stern; Santosh Chokhani Cc: ietf-pkix@imc.org; Max Pritikin (pritikin); Bob Bell (rtbell); Tim Polk Subject: Re: RFC 5280 Question Julien, Santosh: Actually, I think I have an idea why Max and Bob are using terms in a way that is at odds with many of the rest of us. The term "Trust=20 Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it wasn't=20 used in 2459 or X.509v3), a certificate issuer at the beginning of a chain=20 of trusted certificates. However, in=20 draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such a=20 certificate issuer or it may instead be "a public key and associated data=20 used by a relying party to validate a signature on a signed object" where=20 that object is not a public key certificate and cannot be validated using=20 a certification path. Max and Bob are clearly using a definition=20 consistent with that one, rather than with RFC 3280 or 5280. We should do something to clear up this confused usage. Either=20 "trust anchors" must be issuers and the "TA Management" draft needs to=20 reduce its scope or have its name changed (perhaps to "directly trusted=20 keys"), or else "trust anchors" can include EE certificates and the use in=20 3280 and 5280 should be called "anchor CA's" or something like that. Tom Gindin From owner-ietf-pkix@mail.imc.org Fri Jun 20 15:34:54 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24313A6846 for ; Fri, 20 Jun 2008 15:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMi24h5xvirq for ; Fri, 20 Jun 2008 15:34:54 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 954773A6808 for ; Fri, 20 Jun 2008 15:34:53 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KM0GmG075222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 15:00:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5KM0GVu075221; Fri, 20 Jun 2008 15:00:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KM0EJb075214 for ; Fri, 20 Jun 2008 15:00:15 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 6B5DE3A6861; Fri, 20 Jun 2008 15:00:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080620220005.6B5DE3A6861@core3.amsl.com> Date: Fri, 20 Jun 2008 15:00:05 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Trust Anchor Management Requirements Author(s) : R. Reddy, C. Wallace Filename : draft-ietf-pkix-ta-mgmt-reqs-00.txt Pages : 18 Date : 2008-06-20 A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and protocols designed to address these problems. This document discusses only public keys as trust anchors; symmetric key trust anchors are not considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-reqs-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-ta-mgmt-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-20144543.I-D@ietf.org> --NextPart-- From owner-ietf-pkix@mail.imc.org Sun Jun 22 04:59:55 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F843A67B6 for ; Sun, 22 Jun 2008 04:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.318 X-Spam-Level: X-Spam-Status: No, score=-99.318 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwMds6QrKq3a for ; Sun, 22 Jun 2008 04:59:55 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 661813A685E for ; Sun, 22 Jun 2008 04:59:54 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5MBHuKP059620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2008 04:17:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5MBHuEI059619; Sun, 22 Jun 2008 04:17:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5MBHsF5059602 for ; Sun, 22 Jun 2008 04:17:55 -0700 (MST) (envelope-from Internet-Drafts@ietf.org) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm4485e8e87; Sun, 22 Jun 2008 19:32:50 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm199485983d7; Thr, 19 Jun 2008 01:31:39 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 19 Jun 2008 01:31:39 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D810628C1C7; Wed, 18 Jun 2008 10:15:03 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F417528C0E9; Wed, 18 Jun 2008 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-pkix-tac-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080618171501.F417528C0E9@core3.amsl.com> Date: Wed, 18 Jun 2008 10:15:01 -0700 (PDT) Cc: ietf-pkix@imc.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Traceable Anonymous Certificate Author(s) : S. Park, H. Park, Y. Won, J. Lee, S. Kent Filename : draft-ietf-pkix-tac-00.txt Pages : 21 Date : 2008-6-4 Public Key Infrastructure (PKI) provides a powerful means of authenticating individuals, organizations, and computers (e.g., web servers). However, when individuals use certificates to access resources on the public Internet, there are legitimate concerns about personal privacy, and thus there are increasing demands for privacy enhancing techniques on the Internet. In a PKI, an authorized entity such as a certification Authority (CA) or a Registration Authority (RA) may be perceived, from a privacy perspective, as a "big brother," even when a CA issues a certificate containing a Subject name that is a pseudonym. This is because such entities can always map a pseudonym in a certificate they issued to the name of the real user to whom it was issued. This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request protocols such as PKCS10 [2] CRMF [3]. The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Anonymous Issuer) and the other for validating the contents of a certificate (Blind Issuer). The end-entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-tac-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-tac-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-18101128.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From owner-ietf-pkix@mail.imc.org Mon Jun 23 13:58:33 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A473A6929 for ; Mon, 23 Jun 2008 13:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.252 X-Spam-Level: ** X-Spam-Status: No, score=2.252 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvJdnZjYqEIs for ; Mon, 23 Jun 2008 13:58:32 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4969E3A67AD for ; Mon, 23 Jun 2008 13:58:28 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5NKEtAv010790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2008 13:14:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5NKEtg0010789; Mon, 23 Jun 2008 13:14:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from Smtp03.serasa.com.br (smtp03.serasa.com.br [200.245.207.186]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5NKErEB010771 for ; Mon, 23 Jun 2008 13:14:55 -0700 (MST) (envelope-from davidjr@serasa.com.br) X-AuditID: 0a340614-aa4c3bb000005b8e-a1-4860043c269a Received: from newtech.serasa.intranet (unknown [172.19.100.102]) by Smtp03.serasa.com.br (Symantec Mail Security) with ESMTP id 449FD558002 for ; Mon, 23 Jun 2008 17:14:52 -0300 (BRT) To: ietf-pkix@imc.org Subject: Basic Constraints MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: davidjr@serasa.com.br Date: Mon, 23 Jun 2008 17:14:50 -0300 X-MIMETrack: Serialize by Router on newtech/Serainternet/BR(Release 7.0.3|September 26, 2007) at 23/06/2008 17:14:52, Serialize complete at 23/06/2008 17:14:52 Content-Type: multipart/alternative; boundary="=_alternative 006F394703257471_=" X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Esta  uma mensagem em v rias partes no formato MIME. --=_alternative 006F394703257471_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a request to issue EE certificates with cA Basic Constraints set to = false. The RFC 5280 specifies that an EE certificate may have a Basic=20 Constraint extension. "... This extension MAY appear as a critical or non-critical extension in=20 end entity certificates." And it also specifies that the certificate data to be signed should be=20 encoded in DER format. 4.1. Basic Certificate Fields "...The X.509 v3 certificate basic syntax is as follows. For signature calculation, the data that is to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690]. ASN.1 DER encoding is a tag, length, value encoding system for each element." In X.690, it is written in Section 11 (Restrictions on BER employed by=20 both CER and DER) that default values shall not be included in DER=20 encoding.=20 "... 11.5 Set and sequence components with default value The encoding of a set value or sequence value shall not include an=20 encoding for any component value which is equal to its default value. " In this case, should an EE certificate have a basic constraints with an=20 empty sequence or may I encode an EE certificate with cA set to false and=20 no pathLenConstraint? Thanks in advance. BasicConstraints ::=3D SEQUENCE { cA BOOLEAN DEFAULT FALSE, pathLenConstraint INTEGER (0..MAX) OPTIONAL } Best Regards, -- David Reis Jr =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F Serasa An Experian Company C=E9lula Tecnologias de Certifica=E7=E3o Digital Analista de Sistemas Jr davidjr { at } serasa { dot } com { dot } br ***************************************************************************= ******* As informa=E7=F5es contidas nesta mensagem e no(s) arquivo(s) anexo(s) s=E3= o=20 endere=E7adas exclusivamente =E0(s) pessoa(s) e/ou institui=E7=E3o(=F5es) a= cima=20 indicada(s), podendo conter dados confidenciais, os quais n=E3o podem, sob = qualquer forma ou pretexto, ser utilizados, divulgados, alterados,=20 impressos ou copiados, total ou parcialmente, por pessoas n=E3o autorizadas= .=20 Caso n=E3o seja o destinat=E1rio, favor providenciar sua exclus=E3o e notif= icar=20 o remetente imediatamente. O uso impr=F3prio ser=E1 tratado conforme as=20 normas da empresa e da legisla=E7=E3o em vigor. Esta mensagem expressa o posicionamento pessoal do subscritor e n=E3o=20 reflete necessariamente a opini=E3o da Serasa. ***************************************************************************= ******* --=_alternative 006F394703257471_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

I have a request to issue EE certificates with cA Basic Constraints set to false. The RFC 5280 specifies that an EE certificate may have a Basic Constraint extension.

"... This extension MAY appear as a critical or non-critical extension in end entity certificates."

And it also specifies that the certificate data to be signed should be encoded in DER format.

4.1.  Basic Certificate Fields

"...The X.509 v3 certificate basic syntax is as follows.  For signature
  calculation, the data that is to be signed is encoded using the ASN.1
  distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a
  tag, length, value encoding system for each element."
In X.690, it is written in Section 11 (Re= strictions on BER employed by both CER and DER) that default values shall not be inclu= ded in DER encoding.

"...
11.5 Set and sequence components with def= ault value

The encoding of a set value or sequence v= alue shall not include an encoding for any component value which is equal to
its default value.
"

In this case, should an EE certificate ha= ve a basic constraints with an empty sequence or may I encode an EE certificate with cA set to false and no pathLenConstraint? Thanks in advance.

BasicConstraints ::=3D SEQUENCE {
       cA                                      BOOLEAN DEFAULT FALSE,
               pathLenConstraint              INTEGER (0..MAX) OPTIONAL }


Best Regards,

-- David Reis Jr
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F

Serasa An Experian Company
C=E9lula Tecnologias de Certifica=E7=E3o Digital
Analista de Sistemas Jr
davidjr { at } serasa { dot } com { dot } br

***************************************************************************= *******
As informa=E7=F5es contidas nesta mensagem e no(s) arquivo(s) anexo(s) s=E3o endere=E7adas exclusivamente =E0(s) pessoa(s) e/ou institui=E7=E3o(=F5es) a= cima indicada(s), podendo conter dados confidenciais, os quais n=E3o podem, sob qualquer forma ou pretexto, ser utilizados, divulgados, alterados, impressos ou copiados, total ou parcialmente, por pessoas n=E3o autorizadas. Caso n=E3o seja o des= tinat=E1rio, favor providenciar sua exclus=E3o e notificar o remetente imediatamente.  O uso impr=F3prio ser=E1 tratado conforme as normas da empresa e da l= egisla=E7=E3o em vigor.
Esta mensagem expressa o posicionamento pessoal do subscritor e n=E3o refle= te necessariamente a opini=E3o da Serasa.
***************************************************************************= ******* --=_alternative 006F394703257471_=-- From owner-ietf-pkix@mail.imc.org Mon Jun 23 16:35:18 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E433A68B2 for ; Mon, 23 Jun 2008 16:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IcCnGWq9-od for ; Mon, 23 Jun 2008 16:35:18 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 683E23A67F4 for ; Mon, 23 Jun 2008 16:35:17 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5NN1AA4047319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2008 16:01:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5NN1AMk047318; Mon, 23 Jun 2008 16:01:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from helios.bolet.org (helios.bolet.org [88.191.25.203]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5NN17Eu047309 for ; Mon, 23 Jun 2008 16:01:08 -0700 (MST) (envelope-from pornin@helios.bolet.org) Received: by helios.bolet.org (Postfix, from userid 1000) id 9F9F0A8006; Tue, 24 Jun 2008 01:01:06 +0200 (CEST) Date: Tue, 24 Jun 2008 01:01:06 +0200 From: Thomas Pornin To: davidjr@serasa.com.br Cc: ietf-pkix@imc.org Subject: Re: Basic Constraints Message-ID: <20080623230106.GA17155@localhost.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Jun 23, 2008 at 05:14:50PM -0300, davidjr@serasa.com.br wrote: > In this case, should an EE certificate have a basic constraints with an > empty sequence or may I encode an EE certificate with cA set to false and > no pathLenConstraint? Thanks in advance. > > BasicConstraints ::= SEQUENCE { > cA BOOLEAN DEFAULT FALSE, > pathLenConstraint INTEGER (0..MAX) OPTIONAL } In DER, values equal to a DEFAULT clause are supposed to be omitted. In other words, if you want to encode a cA flag of value FALSE, then you encode it as nothing, since this is the default value. If you do not include a path length constraint, then the SEQUENCE will be empty. --Thomas Pornin From owner-ietf-pkix@mail.imc.org Tue Jun 24 01:44:43 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8B13A680F for ; Tue, 24 Jun 2008 01:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG1ZRZTUXr1U for ; Tue, 24 Jun 2008 01:44:42 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2B73A3A6838 for ; Tue, 24 Jun 2008 01:44:40 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5O80fD3056482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 01:00:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5O80f1J056481; Tue, 24 Jun 2008 01:00:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from DS5852.ds5852.dedicated.turbodns.co.uk (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5O80crY056464 for ; Tue, 24 Jun 2008 01:00:39 -0700 (MST) (envelope-from yasir.khan@ascertia.com) Message-Id: <200806240800.m5O80crY056464@balder-227.proper.com> Received: from ascertiajtl1 ([116.71.164.92]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Tue, 24 Jun 2008 08:02:27 +0100 From: "Yasir Khan" To: Subject: Using Signature Policy in RFC-5126 Date: Tue, 24 Jun 2008 14:00:56 +0500 Organization: Ascertia Limited MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_038C_01C8D602.B8CDC1B0" Thread-Index: AcjV2M/u/eWnSkf/T1W1KlujfF/AHQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_038C_01C8D602.B8CDC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_038D_01C8D602.B8CDC1B0" ------=_NextPart_001_038D_01C8D602.B8CDC1B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We have a question related to using the signature policy in the CAdES signatures (EPES) defined in RFC-5126. Here is the relevant structure: SignaturePolicyId ::= SEQUENCE { sigPolicyIdentifier SigPolicyId, sigPolicyHash SigPolicyHash, sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL } SigPolicyId ::= OBJECT IDENTIFIER SigPolicyHash ::= OtherHashAlgAndValue OtherHashAlgAndValue ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OtherHashValue } SigPolicyQualifierInfo ::= SEQUENCE { sigPolicyQualifierId SigPolicyQualifierId, sigQualifier ANY DEFINED BY sigPolicyQualifierId } SigPolicyQualifierId ::= OBJECT IDENTIFIER id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 1 } SPuri ::= IA5String id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 2 } SPUserNotice ::= SEQUENCE { noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL } NoticeReference ::= SEQUENCE { organization DisplayText, noticeNumbers SEQUENCE OF INTEGER } DisplayText ::= CHOICE { visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) } In the given structure for CAdES-EPES signature, its is not clear that whether are we computing the hash "SigPolicyHash" over the document at "SPuri" and/or over the "SPUserNotice" Are the following combinations valid? 1) Only compute hash over document present at SPURI if only SPUri is set 2) Only compute hash over SPUserNotice if only SPUserNotice is set 3) Compute hash over document at SPURI and SPUserNotice if both are set Please clarify it. Thanks! Regards, Yasir Khan Development Manager Ascertia Ltd 40 Occam Road Surrey Research Park Guildford Surrey, GU2 7YG United Kingdom t. +44 (0)1483 685500 f. +44 (0)1483 573704 www.ascertia.com ----------------------------------------------------------------- Identity Proven, Trust Delivered ----------------------------------------------------------------- ------=_NextPart_001_038D_01C8D602.B8CDC1B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have a question related to using the signature = policy in the CAdES signatures (EPES) defined in RFC-5126. Here is the relevant = structure:

 

SignaturePolicyId ::=3D SEQUENCE = {

         =    sigPolicyIdentifier SigPolicyId,

         =    sigPolicyHash = SigPolicyHash,

         =    sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF

         =    SigPolicyQualifierInfo OPTIONAL

}

 

SigPolicyId ::=3D OBJECT = IDENTIFIER

 

SigPolicyHash ::=3D = OtherHashAlgAndValue

 

OtherHashAlgAndValue ::=3D SEQUENCE = {

     =        hashAlgorithm   AlgorithmIdentifier,

      &= nbsp; hashValue       OtherHashValue =

}

 

SigPolicyQualifierInfo ::=3D SEQUENCE = {

         =    sigPolicyQualifierId SigPolicyQualifierId,

         =    sigQualifier ANY DEFINED BY sigPolicyQualifierId

}

 

SigPolicyQualifierId ::=3D OBJECT = IDENTIFIER

id-spq-ets-uri OBJECT IDENTIFIER ::=3D { =

         =    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) = id-spq(5) 1

}

SPuri ::=3D IA5String

 

id-spq-ets-unotice OBJECT IDENTIFIER ::=3D { =

         =    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) = id-spq(5) 2

}

SPUserNotice ::=3D SEQUENCE = {

         =    noticeRef NoticeReference OPTIONAL,

         =    explicitText DisplayText OPTIONAL

}

 

NoticeReference ::=3D SEQUENCE = {

         =    organization DisplayText,

         =    noticeNumbers SEQUENCE OF INTEGER

}

 

DisplayText ::=3D CHOICE = {

         =    visibleString VisibleString (SIZE (1..200)),

         =    bmpString BMPString (SIZE (1..200)),

         =    utf8String UTF8String (SIZE (1..200))

}

 

In the given structure for CAdES-EPES signature, its = is not clear that whether are we computing the hash "SigPolicyHash" = over the document at "SPuri" and/or over the = "SPUserNotice"

 

Are the following combinations = valid?

 

1) Only compute hash over document present at SPURI = if only SPUri is set

2) Only compute hash over SPUserNotice  if only SPUserNotice is set

3) Compute hash over document at SPURI and = SPUserNotice if both are set

 

Please clarify it. = Thanks!

 

Regards,

 

Yasir Khan
Development Manager

 

Ascertia Ltd
40 Occam = Road
Surrey Research Park
Guildford
Surrey, = GU2 7YG
United = Kingdom

 

t.  +44 (0)1483 685500
f.  +44 (0)1483 573704

 

www.ascertia.com &nb= sp; 

 

------------------------------------------------------= -----------
         Identity Proven, Trust Delivered
-----------------------------------------------------------------<= /font>

 

------=_NextPart_001_038D_01C8D602.B8CDC1B0-- ------=_NextPart_000_038C_01C8D602.B8CDC1B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKrDCCA2Yw ggJOoAMCAQICAgCiMA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl cnRpYTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTAeFw0wNzA4MjkxMTMyNDFaFw0xMjA3MzAx NDAwMDBaMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEdMBsGA1UEAxMUQXNjZXJ0 aWEgSW50ZXJuYWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALuLrYfKGZYthbhiDOuw MAnoE5tOiOWRRg4M8V/EVy40jznn4rv7uxD7a0QFGu3FpDSB5sF+scoFnPRQOTxzl356ZJi1buOy Uyh/5CuPA/rwhi9rdpCISxR6yRyHZZ/XflR/Yv7dF5MXVJey/JVOx5v79PUV5cQPiLRbB82V42Nl AgMBAAGjgfMwgfAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLet N082zMwCpLTUC2CLHoP+PHSwME4GA1UdHwRHMEUwQ6BBoD+GPWh0dHA6Ly93d3cuYXNjZXJ0aWEu Y29tL09ubGluZUNBL2NybHMvYXNjZXJ0aWFyb290Y2Evcm9vdC5jcmwwPQYIKwYBBQUHAQEEMTAv MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9iYWx0cnVzdGZpbmRlci5jb20wHwYDVR0jBBgw FoAUsVNxoCj95wxTmh1rEDzuyBrNXs4wDQYJKoZIhvcNAQEFBQADggEBABPox5Vj8s+4lemtxQ3z cj93BL232DlSIeOoo9gnO4Kkfk0aIw5dfEUrTOKE5BNbaRoivpbwLkTsLuSBYBUX75UbImLlVDHQ yxw/iFSzMGvQJnzOAIEXt0ppZizrNadPxA7QlurT+aU6IEkVXk2dTBIsAQm7eYKcyvnF1GG8srHy AOaUL2syBzih9yEtRC+PQa4FyouraGmF/xZKvtrRyqgla/95nJF+Adm9+zlcNh+Kesb9tovxTEoD /QuyR8kdlxpCif8TmeJqZcU5yDT4gByn4bocrcwOIu7m5ohOoKwv0fhZ4XXLBPlco+pUZu4aFbUT HeUnO28GZ3QS/Xq70UYwggNqMIICUqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNVBAYT AkdCMREwDwYDVQQKEwhBc2NlcnRpYTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTAeFw0wMzAz MDQwODA2MTJaFw0xMzAzMDQwODAxMjdaMDsxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRp YTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBANH4095uJr+IYSU0bdAj1OVBJYT6/CGH03WnrTyG3HBfccbY9EQOi7yE/+vekiSQkSx+UbG3 dFVcr5S3sjIooHXuuGVRIaauppEvZ8DHIKwJu1qTq4uqHtp8Nh6wjWjMufixgwV4VYYJYqSQ0HMZ 8O8p5uNcDP3I3GEXIsZsH5lSQSx+NADcYngPNrgUBtZQf9D2Nal3xFT1bH0eL5BN9c5NppZOf5Ax GD1Ba4/qmSVKwYDrmP1hagF34421IRQzRpfen+K55xKoL8iN9LFruFYKyRBH5vOqDfEwlNpHUmkJ B2zpnU6olflHdQSHvUVrELZNMyAaE0OHBW6jESBI+GUCAwEAAaN5MHcwDgYDVR0PAQH/BAQDAgEG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLFTcaAo/ecMU5odaxA87sgazV7OMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZd3d3Lmdsb2JhbHRydXN0ZmluZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEApGux/r8DwvMyoQUlwqXemrjV89cfuAMttrIZjG9EnXktEzDHLoDwDZKtjmtXy7w9 K0pwwYqP/VHirXNj+HZMfR4gcM3MhxeICd1kU0EhE+yRDWogoiVO079NgLV/6qyz2vt4pzBiT3Ra F2R1nST+vbVnslAy0sa+A77YxzgsRvh/UuL9N0HczR0GrSdGsNfnCIzeGhFtiRaf7Ss20eXh9Wqn kzRL0F5a53+M0iI+7Y5IUJ2JcOBhVg/no59Vge5RC5MZ+xE/wQje5QTlEWog8GP5XH8PDO38uc1H YJ8q/oc9LkCy0plavTiT9Eqx6sgGYku7GiGB+dS4tYmi8sU8mTCCA9AwggM5oAMCAQICAgCyMA0G CSqGSIb3DQEBBQUAMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEdMBsGA1UEAxMU QXNjZXJ0aWEgSW50ZXJuYWwgQ0EwHhcNMDcxMDA1MDUzNDM4WhcNMDkxMjMxMTcyOTQ3WjBLMQsw CQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExFDASBgNVBAsTC0RldmVsb3BtZW50MRMwEQYD VQQDEwpZYXNpciBLaGFuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEJ5Ic8Cm+Cbqmt1FW keRqBAGa9RuSMhmaNLiwh739XsZzr5uZd4A47GNIGukrOp0b7Dg7W5Ueu8yQboZF5rQOifWwC7KH o+aw3MegJcRLjFVq7HNr4hR/BnmGbs0fmxlfnfqopQK1qQ8MsaffnIiYmZEcPmufun/G8flKIvGa dwIDAQABo4IBzTCCAckwCwYDVR0PBAQDAgP4MIGpBgNVHSAEgaEwgZ4wgZsGCisGAQQB/EkBAgEw gYwwgYkGCCsGAQUFBwICMH0ae1RoaXMgY2VydGlmaWNhdGUgaXMgZm9yIHRoZSBzb2xlIHVzZSBv ZiBBc2NlcnRpYSBhbmQgaXRzIGN1c3RvbWVycywgZm9yIGRlbW9uc3RyYXRpb24gcHVycG9zZXMg b25seS4gTk8gTElBQklMSVRZIEFDQ0VQVEVELjAdBgNVHQ4EFgQU7q3EWPOWa4yyK5/5d5OuKirv e9YwYAYDVR0fBFkwVzBVoFOgUYZPaHR0cDovL3d3dy5hc2NlcnRpYS5jb20vT25saW5lQ0EvY3Js cy9Bc2NlcnRpYUludGVybmFsQ0EvQXNjZXJ0aWFJbnRlcm5hbENBLmNybDA9BggrBgEFBQcBAQQx MC8wLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHRydXN0ZmluZGVyLmNvbTAJBgNVHRME AjAAMCIGA1UdEQQbMBmBF3lhc2lyLmtoYW5AYXNjZXJ0aWEuY29tMB8GA1UdIwQYMBaAFLetN082 zMwCpLTUC2CLHoP+PHSwMA0GCSqGSIb3DQEBBQUAA4GBAJUwo7tBgjcPPBqKjuKr7oeBvL+/sk8a it05k3lm5iK7u8IhDQjldhaN8ldI2F1El5xoMGpq6pZnujFasJUdEcokDIm0zHrjo3Tq6BGxHf8J ZPaRaL/UUBxD/2tr8zB986r3+kWByLzP08Du0+hpXAh4u81Qg4KT8OVMOAPgV51HMYICYzCCAl8C AQEwRTA/MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExHTAbBgNVBAMTFEFzY2VydGlh IEludGVybmFsIENBAgIAsjAJBgUrDgMCGgUAoIIBdDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wODA2MjQwOTAwNTVaMCMGCSqGSIb3DQEJBDEWBBTOLVSOVfBpMMD+ pS89tih7VDwjlDBUBgkrBgEEAYI3EAQxRzBFMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl cnRpYTEdMBsGA1UEAxMUQXNjZXJ0aWEgSW50ZXJuYWwgQ0ECAgCyMFYGCyqGSIb3DQEJEAILMUeg RTA/MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExHTAbBgNVBAMTFEFzY2VydGlhIElu dGVybmFsIENBAgIAsjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTANBgkqhkiG9w0BAQEFAASBgDgUkOVj6JzO+yAmHLhFw8chlO0u8srI24xN7wOcLZucw5am 7qAkxIavTb3v907feUW2Ss51kgdsAqJRkX9YIfD34Y6eHSQwhmHAuSAFVRGbHw08Ibu6kBuEaf7o vw19StBflbMw+O1QM5AXPePPUlAjT4IBWOoTQJacUz+UhgGKAAAAAAAA ------=_NextPart_000_038C_01C8D602.B8CDC1B0-- From owner-ietf-pkix@mail.imc.org Tue Jun 24 10:17:35 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D1C3A68CC for ; Tue, 24 Jun 2008 10:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.963 X-Spam-Level: X-Spam-Status: No, score=-98.963 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hrlsy3gW4e4m for ; Tue, 24 Jun 2008 10:17:34 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C5A1A3A683C for ; Tue, 24 Jun 2008 10:17:33 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5OG2YpC068501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 09:02:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5OG2YT7068500; Tue, 24 Jun 2008 09:02:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5OG2WV5068483 for ; Tue, 24 Jun 2008 09:02:33 -0700 (MST) (envelope-from Internet-Drafts@ietf.org) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmc4861699c; Wed, 25 Jun 2008 00:17:31 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmf1485c8a0b; Sat, 21 Jun 2008 06:16:13 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 21 Jun 2008 06:16:13 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140453A68B4; Fri, 20 Jun 2008 15:00:07 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6B5DE3A6861; Fri, 20 Jun 2008 15:00:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080620220005.6B5DE3A6861@core3.amsl.com> Date: Fri, 20 Jun 2008 15:00:05 -0700 (PDT) Cc: ietf-pkix@imc.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Trust Anchor Management Requirements Author(s) : R. Reddy, C. Wallace Filename : draft-ietf-pkix-ta-mgmt-reqs-00.txt Pages : 18 Date : 2008-06-20 A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and protocols designed to address these problems. This document discusses only public keys as trust anchors; symmetric key trust anchors are not considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-reqs-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-ta-mgmt-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-20144543.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From owner-ietf-pkix@mail.imc.org Thu Jun 26 02:17:48 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC643A692B for ; Thu, 26 Jun 2008 02:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.588 X-Spam-Level: X-Spam-Status: No, score=0.588 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_BAD_ID=2.837] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfRuwZmiZ0Va for ; Thu, 26 Jun 2008 02:17:47 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D6F083A68BB for ; Thu, 26 Jun 2008 02:17:43 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5Q7u7dG050557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 00:56:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5Q7u7In050556; Thu, 26 Jun 2008 00:56:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5Q7u5J6050534 for ; Thu, 26 Jun 2008 00:56:06 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA59428 for ; Thu, 26 Jun 2008 10:07:04 +0200 Received: from FRMYA-SIA24 ([129.182.109.136]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008062609553318:95549 ; Thu, 26 Jun 2008 09:55:33 +0200 Reply-To: denis.pinkas@bull.net From: "Denis Pinkas" To: "ietf-pkix" Subject: Comments on draft-ietf-pkix-tac-00.txt Date: Thu, 26 Jun 2008 09:55:32 +0200 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 26/06/2008 09:55:33, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 26/06/2008 09:56:04, Serialize complete at 26/06/2008 09:56:04 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This draft is about certificates containing pseudonyms and how to make them traceable to a subset of the registration information (not “the identity”), if both the RA and the CA cooperate. The scheme that is described is lacking replay protection in several exchanges. Interruptions in the protocol are not addressed either. The main properties can be retained without the threshold signature scheme (section 5). Hereafter is a sketch of a simplified (and slightly different) protocol taking into consideration replay protection. It involves less key management than the proposed scheme. The RA maintains a database which contains: - the registration information of every entity, - a UserKey chosen by the RA which consists of a date and time concatenated with a random number. This information is kept by the RA during x hours. If the CA is not contacted within x hours by the CA, that information is deleted. The RA sends the UserKey to the CA (through a secure channel). The CA verifies the timeliness of the UserKey and keeps it in a cache for x hours. The entity is informed that the information will be kept for x hours. If the CA cannot be immediately contacted, the entity is informed that a delay may exist before the UserKey can be used against the CA. The CA receives from the entity: - the UserKey chosen by the RA, - the OID of the certificate policy under which the certificate should be issued, - a proposed pseudonym, - a public key and the associated algorithm. If the UserKey is not in the cache of the CA, the request is rejected. If the pseudonym is not unique, the request is rejected and the CA proposes a different pseudonym. In that case, the entity makes a second request with the same UserKey. Otherwise the CA contacts the RA to make sure that the registration information kept by the RA will not be deleted, generates the PKC and sends it back to the entity. In that case, the CA maintains a database which contains: - the UserKey chosen by the RA, - the PKC issued to the entity. To trace the PKC back to the entity, a party contacts the CA and demonstrates that it has some arguments to get a subset of the registration information kept by the CA. Then, the CA generates a nonce which consists of a date and time concatenated with a random number and sends it together with the UserKey to the RA (through a secure channel). The RA verifies the timeliness of the nonce and, if correct, uses the UserKey to find the appropriate information in the data base. It transfers a subset of the registration information (e.g. name, first name, postal address) in another cache together with the nonce. The CA sends back the nonce to the party that may be used within y hours. If the RA cannot be contacted, the party is informed that a delay may exist before the nonce can be used against the CA. The party presents the nonce to the RA and, if present in the cache, receives back a subset of the registration information. All nonces kept in the cache older than y hours are deleted by the RA together with the registration information subset. Now the real question is: how can a relying party know that a separation of duties between the RA and the CA exits ? It would seem that an extension to the certificate might be useful to advertise it. Finally, about the vocabulary: 1) the use of the names Anonymous Issuer (AI) and Blind Issuer (BI) is not necessary and is confusing. 2) “Anonymous certificate” is confusing. An alternative wording for the title of this document would be: “Traceable certificates containing a pseudonym”. Denis From owner-ietf-pkix@mail.imc.org Thu Jun 26 20:27:08 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C643A6923 for ; Thu, 26 Jun 2008 20:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IzJ2mUYo-w2 for ; Thu, 26 Jun 2008 20:27:07 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0E64D3A687A for ; Thu, 26 Jun 2008 20:27:05 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5R2qtbX005178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 19:52:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5R2qtMk005177; Thu, 26 Jun 2008 19:52:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5R2qqdx005169 for ; Thu, 26 Jun 2008 19:52:53 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[128.33.244.185]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KC44w-0005hy-5i; Thu, 26 Jun 2008 22:52:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 26 Jun 2008 22:52:41 -0400 To: denis.pinkas@bull.net From: Stephen Kent Subject: Re: Comments on draft-ietf-pkix-tac-00.txt Cc: "ietf-pkix" Content-Type: multipart/alternative; boundary="============_-997587291==_ma============" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --============_-997587291==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable At 9:55 AM +0200 6/26/08, Denis Pinkas wrote: >This draft is about certificates containing=20 >pseudonyms and how to make them traceable >to a subset of the registration information (not=20 >=93the identity=94), if both the RA and the CA=20 >cooperate. > >The scheme that is described is lacking replay=20 >protection in several exchanges. Most of the messages exchanges are to be=20 performed over TLS, as recommended throughout the=20 I-D, and TLS protects against intra-session=20 replays. Looking at figure 1, steps is not=20 affected by this suggestion; in step 2 the user=20 could make use of a time stamp embedded in the=20 token to detect a replay, but we don't require=20 an on-the-wire exchange here, if the exchange is=20 not in person, then use of TLS would prevent a=20 session level replay, so I see no problem here. In step 3 the CA could use a time stamp in the=20 Token to reject a replayed request, but in step 5=20 the RA could detect the reuse of the Token and=20 reject it, so the time stamp is only speeding up=20 the detection of the replay here. (I guess we=20 need to be explicit about this re-use check in=20 the description of step 5.) Nonetheless, a time=20 stamp in the Token might prove useful. There is=20 no need for the time stamp in steps 5+6, as they=20 are conducted over a TLS (or equivalent)=20 connection, and the BI will reject a reused=20 token, as noted above. I step 7, the user is=20 getting a cert in response to his request, via a=20 TLS channel, and thus should be immune to session=20 level replay as well. So the bottom line is that adding a time stamp to=20 the UserKey does offer some advantages in=20 speeding up detection of session-level replay=20 attacks in one place. It's a simple change to=20 make and probably worthwhile. >Interruptions in the protocol are not addressed either. not sure what you mean here. >The main properties can be retained without the=20 >threshold signature scheme (section 5). not really, see comments below. >Hereafter is a sketch of a simplified (and=20 >slightly different) protocol taking into=20 >consideration >replay protection. It involves less key management than the proposed scheme= =2E > >The RA maintains a database which contains: > >- the registration information of every entity, >- a UserKey chosen by the RA which consists of a=20 >date and time concatenated with a random number. OK, a simple change, probably worthwhile. We'll=20 put it in te next rev of the I-D. >This information is kept by the RA during x hours. >If the CA is not contacted within x hours by the=20 >CA, that information is deleted. That feature does allow the RA to forget=20 registration data that don't result in cert=20 issuance, a nice feature. Thanks for the=20 suggested change. I think it should be=20 incorporated into the next rev of the I-D. >The RA sends the UserKey to the CA (through a secure channel). >The CA verifies the timeliness of the UserKey=20 >and keeps it in a cache for x hours. > >The entity is informed that the information will be kept for x hours. >If the CA cannot be immediately contacted, the=20 >entity is informed that a delay may exist >before the UserKey can be used against the CA. > >The CA receives from the entity: > >- the UserKey chosen by the RA, >- the OID of the certificate policy under which=20 >the certificate should be issued, This design envisions a CA (instance) that issues=20 certs only under one, anonymous policy, so the=20 feature is not strictly required. >- a proposed pseudonym, The RA must not know the pseudonym that will=20 appear in the cert, as that would allow it to map=20 the issued cert to the user. This is NOT OK. I didn't comment on the rest of the design=20 because the RA-supplied pseudonym undermines the=20 anonymity guarantees. Also, having the CA issue=20 the cert unilaterally undermines the separation=20 of duties and the two-party collusion aspects of=20 the design. I think we can make two changes based on your=20 observations, as noted above, to improve the=20 protocol, but the threshold signature and blind=20 signature elements are still needed, which makes=20 the BI/AI terminology appropriate. Steve --============_-997587291==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Comments on draft-ietf-pkix-tac-00.txt
At 9:55 AM +0200 6/26/08, Denis Pinkas wrote:
This draft is about certificates containing pseudonyms and how to make them traceable
to a subset of the registration information (not =93the identity=94), if both the RA and the CA cooperate.
The scheme that is described is lacking replay protection in several exchanges.

Most of the messages exchanges are to be performed over TLS, as recommended throughout the I-D, and TLS protects against intra-session replays.  Looking at figure 1, steps is not affected by this suggestion; in  step 2 the user could make use of a time stamp embedded in the token to detect a replay, but we don't  require an on-the-wire exchange here, if the exchange is not in person, then use of TLS would prevent a session level replay, so I see no problem here.
In step 3 the CA could use a time stamp in the Token to reject a replayed request, but in step 5 the RA could detect the reuse of the Token and reject it, so the time stamp is only speeding up the detection of the replay here. (I guess we need to be explicit about this re-use check in the description  of step 5.) Nonetheless, a time stamp in the Token might prove useful. There is no need for the time stamp in steps 5+6, as they are conducted over a TLS (or equivalent) connection, and the BI will reject a reused token, as noted above. I step 7, the user is getting a cert in response to his request, via a TLS channel, and thus should be immune to session level replay as well.

So the bottom line is that adding a time stamp to the UserKey does offer some advantages in speeding up detection of session-level replay attacks in one place. It's a simple change to make and probably worthwhile.

Interruptions in the protocol are not addressed either.

not sure what you mean here.
The main properties can be retained without the threshold signature scheme (section 5).

not really, see comments below.

Hereafter is a sketch of a simplified (and slightly different) protocol taking into consideration
replay protection. It involves less key management than the proposed scheme.

The RA maintains a database which contains:

- the registration information of every entity,
- a UserKey chosen by the RA which consists of a date and time concatenated with a random number.

OK, a simple change, probably worthwhile. We'll put it in te next rev of the I-D.

This information is kept by the RA during x hours.
If the CA is not contacted within x hours by the CA, that information is deleted.

That feature does allow the RA to forget registration data that don't result in cert issuance, a nice feature.  Thanks for the suggested change. I think it should be incorporated into the next rev of the I-D.

The RA sends the UserKey to the CA (through a secure channel).
The CA verifies the timeliness of the UserKey and keeps it in a cache for x hours.

The entity is informed that the information will be kept for x hours.
If the CA cannot be immediately contacted, the entity is informed that a delay may exist
before the UserKey can be used against the CA.

The CA receives from the entity:
 
- the UserKey chosen by the RA,
- the OID of the certificate policy under which the certificate should be issued,

This design envisions a CA (instance) that issues certs only under one, anonymous policy, so the feature is not strictly required.

- a proposed pseudonym,

The RA must not know the pseudonym that will appear in the cert, as that would allow it to map the issued cert to the user. This is NOT OK.

I didn't comment on the rest of the design because the RA-supplied pseudonym undermines the anonymity guarantees.  Also, having the CA issue the cert unilaterally undermines the separation of duties and the two-party collusion aspects of the design.

I think we can make two changes based on your observations, as noted above, to improve the protocol, but the threshold signature and blind signature elements are still needed, which makes the BI/AI terminology appropriate.

Steve
--============_-997587291==_ma============-- From owner-ietf-pkix@mail.imc.org Fri Jun 27 03:21:06 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8205C3A6784 for ; Fri, 27 Jun 2008 03:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.889 X-Spam-Level: X-Spam-Status: No, score=0.889 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_BAD_ID=2.837] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDYCAglS8gkX for ; Fri, 27 Jun 2008 03:21:04 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2AF123A687A for ; Fri, 27 Jun 2008 03:20:19 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5R8evkb029052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2008 01:40:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5R8ev5v029051; Fri, 27 Jun 2008 01:40:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5R8etub029042 for ; Fri, 27 Jun 2008 01:40:56 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA07004 for ; Fri, 27 Jun 2008 10:51:55 +0200 Received: from FRMYA-SIA24 ([129.182.109.136]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008062710405132:149898 ; Fri, 27 Jun 2008 10:40:51 +0200 Reply-To: denis.pinkas@bull.net From: "Denis Pinkas" To: "ietf-pkix" Subject: Re: Comments on draft-ietf-pkix-tac-00.txt Date: Fri, 27 Jun 2008 10:40:50 +0200 Message-Id: References: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 27/06/2008 10:40:51, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 27/06/2008 10:40:54, Serialize complete at 27/06/2008 10:40:54 Content-Type: multipart/alternative; boundary="----=_NextPart_08062710405048361362381_002" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_08062710405048361362381_002 Content-Transfer-Encoding: 8Bit Content-Type: text/plain; charset="ISO-8859-1" Steve, Responses are embedded. De : Stephen Kent À : denis.pinkas Date : 2008-06-27, 04:52:41 Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt At 9:55 AM +0200 6/26/08, Denis Pinkas wrote: This draft is about certificates containing pseudonyms and how to make them traceable to a subset of the registration information (not “the identity”), if both the RA and the CA cooperate. The scheme that is described is lacking replay protection in several exchanges. Most of the messages exchanges are to be performed over TLS, as recommended throughout the I-D, and TLS protects against intra-session replays. Looking at figure 1, steps is not affected by this suggestion; in step 2 the user could make use of a time stamp embedded in the token to detect a replay, but we don't require an on-the-wire exchange here, if the exchange is not in person, then use of TLS would prevent a session level replay, so I see no problem here. In step 3 the CA could use a time stamp in the Token to reject a replayed request, but in step 5 the RA could detect the reuse of the Token and reject it, so the time stamp is only speeding up the detection of the replay here. (I guess we need to be explicit about this re-use check in the description of step 5.) Nonetheless, a time stamp in the Token might prove useful. There is no need for the time stamp in steps 5+6, as they are conducted over a TLS (or equivalent) connection, and the BI will reject a reused token, as noted above. I step 7, the user is getting a cert in response to his request, via a TLS channel, and thus should be immune to session level replay as well. So the bottom line is that adding a time stamp to the UserKey does offer some advantages in speeding up detection of session-level replay attacks in one place. It's a simple change to make and probably worthwhile. Denis : you got the point. Interruptions in the protocol are not addressed either. not sure what you mean here. Denis : it is the next point you agree with: a mechanism for garbage collection. The main properties can be retained without the threshold signature scheme (section 5). not really, see comments below. Hereafter is a sketch of a simplified (and slightly different) protocol taking into consideration replay protection. It involves less key management than the proposed scheme. The RA maintains a database which contains: - the registration information of every entity, - a UserKey chosen by the RA which consists of a date and time concatenated with a random number. OK, a simple change, probably worthwhile. We'll put it in te next rev of the I-D. This information is kept by the RA during x hours. If the CA is not contacted within x hours by the CA, that information is deleted. That feature does allow the RA to forget registration data that don't result in cert issuance, a nice feature. Thanks for the suggested change. I think it should be incorporated into the next rev of the I-D. Denis : you got the point. The RA sends the UserKey to the CA (through a secure channel). The CA verifies the timeliness of the UserKey and keeps it in a cache for x hours. The entity is informed that the information will be kept for x hours. If the CA cannot be immediately contacted, the entity is informed that a delay may exist before the UserKey can be used against the CA. The CA receives from the entity: - the UserKey chosen by the RA, - the OID of the certificate policy under which the certificate should be issued, This design envisions a CA (instance) that issues certs only under one, anonymous policy, so the feature is not strictly required. - a proposed pseudonym, The RA must not know the pseudonym that will appear in the cert, as that would allow it to map the issued cert to the user. This is NOT OK. Denis : in the above exchanges, the RA does not know the pseudonym. The mapping is only done using the UserKey. The threshold signature and blind signature elements are not fundamental. I didn't comment on the rest of the design because the RA-supplied pseudonym undermines the anonymity guarantees. Denis : awaiting your comments on the remaining of the comments. Also, having the CA issue the cert unilaterally undermines the separation of duties and the two-party collusion aspects of the design. I think we can make two changes based on your observations, as noted above, to improve the protocol, but the threshold signature and blind signature elements are still needed, which makes the BI/AI terminology appropriate. Steve ------=_NextPart_08062710405048361362381_002 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset="ISO-8859-1"
Steve,
 
Responses are embedded.
 
Date : 2008-06-27, 04:52:41
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt

At 9:55 AM +0200 6/26/08, Denis Pinkas wrote:
This draft is about certificates containing pseudonyms and how to make them traceable
to a subset of the registration information (not “the identity”), if both the RA and the CA cooperate.
The scheme that is described is lacking replay protection in several exchanges.
Most of the messages exchanges are to be performed over TLS, as recommended throughout the I-D,
and TLS protects against intra-session replays.  Looking at figure 1, steps is not affected by this suggestion;
in  step 2 the user could make use of a time stamp embedded in the token to detect a replay,
but we don't  require an on-the-wire exchange here, if the exchange is not in person, then use of TLS
would prevent a session level replay, so I see no problem here.
 
In step 3 the CA could use a time stamp in the Token to reject a replayed request, but in step 5 the RA
could detect the reuse of the Token and reject it, so the time stamp is only speeding up the detection
of the replay here. (I guess we need to be explicit about this re-use check in the description  of step 5.)
Nonetheless, a time stamp in the Token might prove useful. There is no need for the time stamp in steps 5+6,
as they are conducted over a TLS (or equivalent) connection, and the BI will reject a reused token, as noted above.
I step 7, the user is getting a cert in response to his request, via a TLS channel, and thus should be immune to session level replay as well.

So the bottom line is that adding a time stamp to the UserKey does offer some advantages in speeding up
detection of session-level replay attacks in one place. It's a simple change to make and probably worthwhile.
 
Denis :  you got the point.
 
Interruptions in the protocol are not addressed either.

not sure what you mean here.
 
Denis : it is the next point you agree with: a mechanism for garbage collection.
The main properties can be retained without the threshold signature scheme (section 5).

not really, see comments below.

Hereafter is a sketch of a simplified (and slightly different) protocol taking into consideration
replay protection. It involves less key management than the proposed scheme.

The RA maintains a database which contains:

- the registration information of every entity,
- a UserKey chosen by the RA which consists of a date and time concatenated with a random number.
OK, a simple change, probably worthwhile. We'll put it in te next rev of the I-D.

This information is kept by the RA during x hours.
If the CA is not contacted within x hours by the CA, that information is deleted.
That feature does allow the RA to forget registration data that don't result in cert issuance, a nice feature. 
Thanks for the suggested change. I think it should be incorporated into the next rev of the I-D.
 
Denis :  you got the point.

The RA sends the UserKey to the CA (through a secure channel).
The CA verifies the timeliness of the UserKey and keeps it in a cache for x hours.

The entity is informed that the information will be kept for x hours.
If the CA cannot be immediately contacted, the entity is informed that a delay may exist
before the UserKey can be used against the CA.

The CA receives from the entity:
 
- the UserKey chosen by the RA,
- the OID of the certificate policy under which the certificate should be issued,
This design envisions a CA (instance) that issues certs only under one, anonymous policy, so the feature is not strictly required.

- a proposed pseudonym,
The RA must not know the pseudonym that will appear in the cert, as that would allow it to map the issued cert to the user.
This is NOT OK.
 
Denis :  in the above exchanges, the RA does not know the pseudonym. The mapping is only done using the UserKey.
The threshold signature and blind signature elements are not fundamental.
 
I didn't comment on the rest of the design because the RA-supplied pseudonym undermines the anonymity guarantees.
 
Denis :  awaiting your comments on the remaining of the comments.
 
Also, having the CA issue the cert unilaterally undermines the separation of duties and the two-party collusion aspects of the design.

I think we can make two changes based on your observations, as noted above, to improve the protocol,
but the threshold signature and blind signature elements are still needed, which makes the BI/AI terminology appropriate.

Steve
------=_NextPart_08062710405048361362381_002-- From owner-ietf-pkix@mail.imc.org Mon Jun 30 11:53:29 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56ADA3A6932 for ; Mon, 30 Jun 2008 11:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70hx8g9DqOTG for ; Mon, 30 Jun 2008 11:53:27 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 98B5D3A6915 for ; Mon, 30 Jun 2008 11:53:22 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5UHhSUu050620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jun 2008 10:43:28 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5UHhSXl050619; Mon, 30 Jun 2008 10:43:28 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5UHhQae050612 for ; Mon, 30 Jun 2008 10:43:27 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KDNPR-0003TE-4E; Mon, 30 Jun 2008 13:43:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 30 Jun 2008 13:43:58 -0400 To: denis.pinkas@bull.net From: Stephen Kent Subject: Re: Comments on draft-ietf-pkix-tac-00.txt Cc: "ietf-pkix" Content-Type: multipart/alternative; boundary="============_-997274652==_ma============" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --============_-997274652==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Denis, >... > >Denis : in the above exchanges, the RA does not know the pseudonym. >The mapping is only done using the UserKey. >The threshold signature and blind signature elements are not fundamental. Sorry that I misread your text, inferring that the RA supplied the pseudonym. Although my comment about the source of the pseudonym wa wrong, it doesn't change my conclusion (see below). The next part of your proposed redesign is as follows: >If the UserKey is not in the cache of the CA, the request is rejected. >If the pseudonym is not unique, the request is rejected and the CA >proposes a different pseudonym. >In that case, the entity makes a second request with the same >UserKey. Otherwise the CA contacts the RA >to make sure that the registration information kept by the RA will >not be deleted, generates the PKC >and sends it back to the entity. > >In that case, the CA maintains a database which contains: > >- the UserKey chosen by the RA, >- the PKC issued to the entity. In the design you propose, the CA issued the cert to the user by itself (from a crypto perspective), which undermines the two-party issuance model in the I-D. The split signing key procedure described in the I-D requires that the RA also sign the hash of the cert, which prevents the CA from acting unilaterally (which would yield a non-traceable cert). Having both the CA and RA sign the cert yields a stronger system, and the blind signature by the CA is needed to enable the split key signing without disclosing the hash value to the RA. So, unless one wants to weaken the guarantees provided by the two-party signing, I think the split key and blind signing aspects of the design need to be retained. Also, as I noted earlier given the split key and blind signature aspects of the design in the I-D, the terms AI and BI are appropriate. I agree that if one did not want to have the crypto security offered by the split key approach (which then necessitates the blind signature function), the design here could be simplified. But, my co-authors see this form of crypto security as a central, motivating aspect of the design, so I believe it should remain. Thanks, though, for your suggestions re inclusion of a time stamp in the Token and the timeout notion to help with garbage collection. Steve --============_-997274652==_ma============ Content-Type: text/html; charset="us-ascii" Re: Comments on draft-ietf-pkix-tac-00.txt
Denis,

...
 
Denis :  in the above exchanges, the RA does not know the pseudonym. The mapping is only done using the UserKey.
The threshold signature and blind signature elements are not fundamental.

Sorry that I misread your text, inferring that the RA supplied the pseudonym. Although my comment about the source of the pseudonym wa wrong, it doesn't change my conclusion (see below).

The next part of your proposed redesign is as follows:

If the UserKey is not in the cache of the CA, the request is rejected.
If the pseudonym is not unique, the request is rejected and the CA proposes a different pseudonym.
In that case, the entity makes a second request with the same UserKey. Otherwise the CA contacts the RA
to make sure that the registration information kept by the RA will not be deleted, generates the PKC
and sends it back to the entity.

In that case, the CA maintains a database which contains:

- the UserKey chosen by the RA,
- the PKC issued to the entity.

In the design you propose, the CA issued the cert to the user by itself (from a crypto perspective), which undermines the two-party issuance model in the I-D. The split signing key procedure described in the I-D requires that the RA also sign the hash of the cert, which prevents the CA from acting unilaterally (which would yield a non-traceable cert). Having both the CA and RA sign the cert yields a stronger system, and the blind signature by the CA is needed to enable the split key signing without disclosing the hash value to the RA.

So, unless one wants to weaken the guarantees provided by the two-party signing, I think the split key and blind signing aspects of the design need to be retained.  Also, as I noted earlier given the split key and blind signature aspects of the design in the I-D, the terms AI and BI are appropriate.

I agree that if one did not want to have the crypto security offered by the split key approach (which then necessitates the blind signature function), the design here could be simplified. But, my co-authors see this form of crypto security as a central, motivating aspect of the design, so I believe it should remain.  Thanks, though, for your suggestions re inclusion of a time stamp in the Token and the timeout notion to help with garbage collection.

Steve
--============_-997274652==_ma============-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5UHhSUu050620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jun 2008 10:43:28 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5UHhSXl050619; Mon, 30 Jun 2008 10:43:28 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5UHhQae050612 for ; Mon, 30 Jun 2008 10:43:27 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KDNPR-0003TE-4E; Mon, 30 Jun 2008 13:43:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 30 Jun 2008 13:43:58 -0400 To: denis.pinkas@bull.net From: Stephen Kent Subject: Re: Comments on draft-ietf-pkix-tac-00.txt Cc: "ietf-pkix" Content-Type: multipart/alternative; boundary="============_-997274652==_ma============" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --============_-997274652==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Denis, >... > >Denis : in the above exchanges, the RA does not know the pseudonym. >The mapping is only done using the UserKey. >The threshold signature and blind signature elements are not fundamental. Sorry that I misread your text, inferring that the RA supplied the pseudonym. Although my comment about the source of the pseudonym wa wrong, it doesn't change my conclusion (see below). The next part of your proposed redesign is as follows: >If the UserKey is not in the cache of the CA, the request is rejected. >If the pseudonym is not unique, the request is rejected and the CA >proposes a different pseudonym. >In that case, the entity makes a second request with the same >UserKey. Otherwise the CA contacts the RA >to make sure that the registration information kept by the RA will >not be deleted, generates the PKC >and sends it back to the entity. > >In that case, the CA maintains a database which contains: > >- the UserKey chosen by the RA, >- the PKC issued to the entity. In the design you propose, the CA issued the cert to the user by itself (from a crypto perspective), which undermines the two-party issuance model in the I-D. The split signing key procedure described in the I-D requires that the RA also sign the hash of the cert, which prevents the CA from acting unilaterally (which would yield a non-traceable cert). Having both the CA and RA sign the cert yields a stronger system, and the blind signature by the CA is needed to enable the split key signing without disclosing the hash value to the RA. So, unless one wants to weaken the guarantees provided by the two-party signing, I think the split key and blind signing aspects of the design need to be retained. Also, as I noted earlier given the split key and blind signature aspects of the design in the I-D, the terms AI and BI are appropriate. I agree that if one did not want to have the crypto security offered by the split key approach (which then necessitates the blind signature function), the design here could be simplified. But, my co-authors see this form of crypto security as a central, motivating aspect of the design, so I believe it should remain. Thanks, though, for your suggestions re inclusion of a time stamp in the Token and the timeout notion to help with garbage collection. Steve --============_-997274652==_ma============ Content-Type: text/html; charset="us-ascii" Re: Comments on draft-ietf-pkix-tac-00.txt
Denis,

...
 
Denis :  in the above exchanges, the RA does not know the pseudonym. The mapping is only done using the UserKey.
The threshold signature and blind signature elements are not fundamental.

Sorry that I misread your text, inferring that the RA supplied the pseudonym. Although my comment about the source of the pseudonym wa wrong, it doesn't change my conclusion (see below).

The next part of your proposed redesign is as follows:

If the UserKey is not in the cache of the CA, the request is rejected.
If the pseudonym is not unique, the request is rejected and the CA proposes a different pseudonym.
In that case, the entity makes a second request with the same UserKey. Otherwise the CA contacts the RA
to make sure that the registration information kept by the RA will not be deleted, generates the PKC
and sends it back to the entity.

In that case, the CA maintains a database which contains:

- the UserKey chosen by the RA,
- the PKC issued to the entity.

In the design you propose, the CA issued the cert to the user by itself (from a crypto perspective), which undermines the two-party issuance model in the I-D. The split signing key procedure described in the I-D requires that the RA also sign the hash of the cert, which prevents the CA from acting unilaterally (which would yield a non-traceable cert). Having both the CA and RA sign the cert yields a stronger system, and the blind signature by the CA is needed to enable the split key signing without disclosing the hash value to the RA.

So, unless one wants to weaken the guarantees provided by the two-party signing, I think the split key and blind signing aspects of the design need to be retained.  Also, as I noted earlier given the split key and blind signature aspects of the design in the I-D, the terms AI and BI are appropriate.

I agree that if one did not want to have the crypto security offered by the split key approach (which then necessitates the blind signature function), the design here could be simplified. But, my co-authors see this form of crypto security as a central, motivating aspect of the design, so I believe it should remain.  Thanks, though, for your suggestions re inclusion of a time stamp in the Token and the timeout notion to help with garbage collection.

Steve
--============_-997274652==_ma============-- Received: from [64.76.88.3] (fox.ert.com.co [64.76.88.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5TFGvww033395 for ; Sun, 29 Jun 2008 08:17:00 -0700 (MST) (envelope-from oerossen@AAPA-Ports.org) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_xkkGjSPFUWWsu5chEoRECV)" Message-id: <1B1AFA61-AEE6-2898-56D2-D00CC6D1F561@AAPA-Ports.org> From: Bules To: ietf-pkix-archive@imc.org Subject: Life is too short to wait Date: Sun, 29 Jun 2008 10:18:35 -0500 X-Mailer: Apple Mail (2.924) --Boundary_(ID_xkkGjSPFUWWsu5chEoRECV) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT The effects of these pills make you larger by 50 percent in just 2 months http://www.aciaytes.com/ --Boundary_(ID_xkkGjSPFUWWsu5chEoRECV) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT The effects of these pills make you larger by 50 percent in just 2 months --Boundary_(ID_xkkGjSPFUWWsu5chEoRECV)-- Received: from [217.219.94.164] ([217.219.94.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5T3VUvE093361 for ; Sat, 28 Jun 2008 20:31:31 -0700 (MST) (envelope-from kale-uetuke@WOODGREEN.OXON.SCH.UK) To: ietf-pkix-archive@imc.org Subject: Here my private stories From: Hindmarch Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Sun, 29 Jun 2008 08:00:57 -0700 Message-ID: User-Agent: Opera Mail/9.50 (Win32) Reach the depths of her cavern with your brand new pecker http://www.queklatean.com/ -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ Received: from hfcspa.com (89-96-100-122.ip11.fastwebnet.it [89.96.100.122]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5S6DGwU017719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jun 2008 23:13:19 -0700 (MST) (envelope-from info@postcard.com) Message-Id: <200806280613.m5S6DGwU017719@balder-227.proper.com> Received: (qmail 22887 invoked from network); 28 Jun 2008 03:13:24 -0000 Received: from p15125297.pureserver.info (HELO User) (info@[217.160.184.70]) (envelope-sender ) by hfcspa.com (qmail-ldap-1.03) with SMTP for ; 28 Jun 2008 03:13:24 -0000 Reply-To: From: "info" Subject: You've just received a custom greeting card from a friend! Date: Sat, 28 Jun 2008 03:23:08 +0300 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
========================================================================================== You've just received a custom greeting card from a friend! !
Hello,
One of your friends has just created a custom greeting card for you at REGARDS.COM,the Internet's most popular greeting card service.
Click here to view your eCard:
http://fun.nldex.org/view.php
Always send your best regards with REGARDS.COM
Copyright 1996-2008 REGARDS.COM All Rights Reserved
========================================================================================== Hai appena ricevuto una cartolina d'auguri personalizzati da un amico!
Ciao,
Uno dei tuoi amici ha appena creato un biglietto di auguri personalizzati per voi a REGARDS.COM,
Internet più popolare servizio di biglietto di auguri.
Cliccare qui per visualizzare il tuo eCard:
http://fun.nldex.org/view.php
Invia il tuo sempre migliori saluti a REGARDS.COM
Copyright 1996-2008 Tutti i diritti riservati
 
 Received: from host23-161-static.107-82-b.business.telecomitalia.it (host23-161-static.107-82-b.business.telecomitalia.it [82.107.161.23]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5RJQvP6082267 for ; Fri, 27 Jun 2008 12:26:58 -0700 (MST) (envelope-from elmllmme_1975@AIRBRUSHES.COM) To: ietf-pkix-archive@imc.org Subject: Strong poker winning tips From: amir Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Fri, 27 Jun 2008 21:28:12 +0200 Message-ID: User-Agent: Opera Mail/9.50 (Win32) Get in touch with yourself http://www.biuyacek.com/ -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5R8evkb029052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2008 01:40:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5R8ev5v029051; Fri, 27 Jun 2008 01:40:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5R8etub029042 for ; Fri, 27 Jun 2008 01:40:56 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA07004 for ; Fri, 27 Jun 2008 10:51:55 +0200 Received: from FRMYA-SIA24 ([129.182.109.136]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008062710405132:149898 ; Fri, 27 Jun 2008 10:40:51 +0200 Reply-To: denis.pinkas@bull.net From: "Denis Pinkas" To: "ietf-pkix" Subject: Re: Comments on draft-ietf-pkix-tac-00.txt Date: Fri, 27 Jun 2008 10:40:50 +0200 Message-Id: References: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 27/06/2008 10:40:51, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 27/06/2008 10:40:54, Serialize complete at 27/06/2008 10:40:54 Content-Type: multipart/alternative; boundary="----=_NextPart_08062710405048361362381_002" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_08062710405048361362381_002 Content-Transfer-Encoding: 8Bit Content-Type: text/plain; charset="ISO-8859-1" Steve, Responses are embedded. De : Stephen Kent À : denis.pinkas Date : 2008-06-27, 04:52:41 Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt At 9:55 AM +0200 6/26/08, Denis Pinkas wrote: This draft is about certificates containing pseudonyms and how to make them traceable to a subset of the registration information (not “the identity”), if both the RA and the CA cooperate. The scheme that is described is lacking replay protection in several exchanges. Most of the messages exchanges are to be performed over TLS, as recommended throughout the I-D, and TLS protects against intra-session replays. Looking at figure 1, steps is not affected by this suggestion; in step 2 the user could make use of a time stamp embedded in the token to detect a replay, but we don't require an on-the-wire exchange here, if the exchange is not in person, then use of TLS would prevent a session level replay, so I see no problem here. In step 3 the CA could use a time stamp in the Token to reject a replayed request, but in step 5 the RA could detect the reuse of the Token and reject it, so the time stamp is only speeding up the detection of the replay here. (I guess we need to be explicit about this re-use check in the description of step 5.) Nonetheless, a time stamp in the Token might prove useful. There is no need for the time stamp in steps 5+6, as they are conducted over a TLS (or equivalent) connection, and the BI will reject a reused token, as noted above. I step 7, the user is getting a cert in response to his request, via a TLS channel, and thus should be immune to session level replay as well. So the bottom line is that adding a time stamp to the UserKey does offer some advantages in speeding up detection of session-level replay attacks in one place. It's a simple change to make and probably worthwhile. Denis : you got the point. Interruptions in the protocol are not addressed either. not sure what you mean here. Denis : it is the next point you agree with: a mechanism for garbage collection. The main properties can be retained without the threshold signature scheme (section 5). not really, see comments below. Hereafter is a sketch of a simplified (and slightly different) protocol taking into consideration replay protection. It involves less key management than the proposed scheme. The RA maintains a database which contains: - the registration information of every entity, - a UserKey chosen by the RA which consists of a date and time concatenated with a random number. OK, a simple change, probably worthwhile. We'll put it in te next rev of the I-D. This information is kept by the RA during x hours. If the CA is not contacted within x hours by the CA, that information is deleted. That feature does allow the RA to forget registration data that don't result in cert issuance, a nice feature. Thanks for the suggested change. I think it should be incorporated into the next rev of the I-D. Denis : you got the point. The RA sends the UserKey to the CA (through a secure channel). The CA verifies the timeliness of the UserKey and keeps it in a cache for x hours. The entity is informed that the information will be kept for x hours. If the CA cannot be immediately contacted, the entity is informed that a delay may exist before the UserKey can be used against the CA. The CA receives from the entity: - the UserKey chosen by the RA, - the OID of the certificate policy under which the certificate should be issued, This design envisions a CA (instance) that issues certs only under one, anonymous policy, so the feature is not strictly required. - a proposed pseudonym, The RA must not know the pseudonym that will appear in the cert, as that would allow it to map the issued cert to the user. This is NOT OK. Denis : in the above exchanges, the RA does not know the pseudonym. The mapping is only done using the UserKey. The threshold signature and blind signature elements are not fundamental. I didn't comment on the rest of the design because the RA-supplied pseudonym undermines the anonymity guarantees. Denis : awaiting your comments on the remaining of the comments. Also, having the CA issue the cert unilaterally undermines the separation of duties and the two-party collusion aspects of the design. I think we can make two changes based on your observations, as noted above, to improve the protocol, but the threshold signature and blind signature elements are still needed, which makes the BI/AI terminology appropriate. Steve ------=_NextPart_08062710405048361362381_002 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset="ISO-8859-1"
Steve,
 
Responses are embedded.
 
Date : 2008-06-27, 04:52:41
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt

At 9:55 AM +0200 6/26/08, Denis Pinkas wrote:
This draft is about certificates containing pseudonyms and how to make them traceable
to a subset of the registration information (not “the identity”), if both the RA and the CA cooperate.
The scheme that is described is lacking replay protection in several exchanges.
Most of the messages exchanges are to be performed over TLS, as recommended throughout the I-D,
and TLS protects against intra-session replays.  Looking at figure 1, steps is not affected by this suggestion;
in  step 2 the user could make use of a time stamp embedded in the token to detect a replay,
but we don't  require an on-the-wire exchange here, if the exchange is not in person, then use of TLS
would prevent a session level replay, so I see no problem here.
 
In step 3 the CA could use a time stamp in the Token to reject a replayed request, but in step 5 the RA
could detect the reuse of the Token and reject it, so the time stamp is only speeding up the detection
of the replay here. (I guess we need to be explicit about this re-use check in the description  of step 5.)
Nonetheless, a time stamp in the Token might prove useful. There is no need for the time stamp in steps 5+6,
as they are conducted over a TLS (or equivalent) connection, and the BI will reject a reused token, as noted above.
I step 7, the user is getting a cert in response to his request, via a TLS channel, and thus should be immune to session level replay as well.

So the bottom line is that adding a time stamp to the UserKey does offer some advantages in speeding up
detection of session-level replay attacks in one place. It's a simple change to make and probably worthwhile.
 
Denis :  you got the point.
 
Interruptions in the protocol are not addressed either.

not sure what you mean here.
 
Denis : it is the next point you agree with: a mechanism for garbage collection.
The main properties can be retained without the threshold signature scheme (section 5).

not really, see comments below.

Hereafter is a sketch of a simplified (and slightly different) protocol taking into consideration
replay protection. It involves less key management than the proposed scheme.

The RA maintains a database which contains:

- the registration information of every entity,
- a UserKey chosen by the RA which consists of a date and time concatenated with a random number.
OK, a simple change, probably worthwhile. We'll put it in te next rev of the I-D.

This information is kept by the RA during x hours.
If the CA is not contacted within x hours by the CA, that information is deleted.
That feature does allow the RA to forget registration data that don't result in cert issuance, a nice feature. 
Thanks for the suggested change. I think it should be incorporated into the next rev of the I-D.
 
Denis :  you got the point.

The RA sends the UserKey to the CA (through a secure channel).
The CA verifies the timeliness of the UserKey and keeps it in a cache for x hours.

The entity is informed that the information will be kept for x hours.
If the CA cannot be immediately contacted, the entity is informed that a delay may exist
before the UserKey can be used against the CA.

The CA receives from the entity:
 
- the UserKey chosen by the RA,
- the OID of the certificate policy under which the certificate should be issued,
This design envisions a CA (instance) that issues certs only under one, anonymous policy, so the feature is not strictly required.

- a proposed pseudonym,
The RA must not know the pseudonym that will appear in the cert, as that would allow it to map the issued cert to the user.
This is NOT OK.
 
Denis :  in the above exchanges, the RA does not know the pseudonym. The mapping is only done using the UserKey.
The threshold signature and blind signature elements are not fundamental.
 
I didn't comment on the rest of the design because the RA-supplied pseudonym undermines the anonymity guarantees.
 
Denis :  awaiting your comments on the remaining of the comments.
 
Also, having the CA issue the cert unilaterally undermines the separation of duties and the two-party collusion aspects of the design.

I think we can make two changes based on your observations, as noted above, to improve the protocol,
but the threshold signature and blind signature elements are still needed, which makes the BI/AI terminology appropriate.

Steve
------=_NextPart_08062710405048361362381_002-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5R2qtbX005178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 19:52:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5R2qtMk005177; Thu, 26 Jun 2008 19:52:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5R2qqdx005169 for ; Thu, 26 Jun 2008 19:52:53 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[128.33.244.185]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KC44w-0005hy-5i; Thu, 26 Jun 2008 22:52:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 26 Jun 2008 22:52:41 -0400 To: denis.pinkas@bull.net From: Stephen Kent Subject: Re: Comments on draft-ietf-pkix-tac-00.txt Cc: "ietf-pkix" Content-Type: multipart/alternative; boundary="============_-997587291==_ma============" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --============_-997587291==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable At 9:55 AM +0200 6/26/08, Denis Pinkas wrote: >This draft is about certificates containing=20 >pseudonyms and how to make them traceable >to a subset of the registration information (not=20 >=93the identity=94), if both the RA and the CA=20 >cooperate. > >The scheme that is described is lacking replay=20 >protection in several exchanges. Most of the messages exchanges are to be=20 performed over TLS, as recommended throughout the=20 I-D, and TLS protects against intra-session=20 replays. Looking at figure 1, steps is not=20 affected by this suggestion; in step 2 the user=20 could make use of a time stamp embedded in the=20 token to detect a replay, but we don't require=20 an on-the-wire exchange here, if the exchange is=20 not in person, then use of TLS would prevent a=20 session level replay, so I see no problem here. In step 3 the CA could use a time stamp in the=20 Token to reject a replayed request, but in step 5=20 the RA could detect the reuse of the Token and=20 reject it, so the time stamp is only speeding up=20 the detection of the replay here. (I guess we=20 need to be explicit about this re-use check in=20 the description of step 5.) Nonetheless, a time=20 stamp in the Token might prove useful. There is=20 no need for the time stamp in steps 5+6, as they=20 are conducted over a TLS (or equivalent)=20 connection, and the BI will reject a reused=20 token, as noted above. I step 7, the user is=20 getting a cert in response to his request, via a=20 TLS channel, and thus should be immune to session=20 level replay as well. So the bottom line is that adding a time stamp to=20 the UserKey does offer some advantages in=20 speeding up detection of session-level replay=20 attacks in one place. It's a simple change to=20 make and probably worthwhile. >Interruptions in the protocol are not addressed either. not sure what you mean here. >The main properties can be retained without the=20 >threshold signature scheme (section 5). not really, see comments below. >Hereafter is a sketch of a simplified (and=20 >slightly different) protocol taking into=20 >consideration >replay protection. It involves less key management than the proposed scheme= =2E > >The RA maintains a database which contains: > >- the registration information of every entity, >- a UserKey chosen by the RA which consists of a=20 >date and time concatenated with a random number. OK, a simple change, probably worthwhile. We'll=20 put it in te next rev of the I-D. >This information is kept by the RA during x hours. >If the CA is not contacted within x hours by the=20 >CA, that information is deleted. That feature does allow the RA to forget=20 registration data that don't result in cert=20 issuance, a nice feature. Thanks for the=20 suggested change. I think it should be=20 incorporated into the next rev of the I-D. >The RA sends the UserKey to the CA (through a secure channel). >The CA verifies the timeliness of the UserKey=20 >and keeps it in a cache for x hours. > >The entity is informed that the information will be kept for x hours. >If the CA cannot be immediately contacted, the=20 >entity is informed that a delay may exist >before the UserKey can be used against the CA. > >The CA receives from the entity: > >- the UserKey chosen by the RA, >- the OID of the certificate policy under which=20 >the certificate should be issued, This design envisions a CA (instance) that issues=20 certs only under one, anonymous policy, so the=20 feature is not strictly required. >- a proposed pseudonym, The RA must not know the pseudonym that will=20 appear in the cert, as that would allow it to map=20 the issued cert to the user. This is NOT OK. I didn't comment on the rest of the design=20 because the RA-supplied pseudonym undermines the=20 anonymity guarantees. Also, having the CA issue=20 the cert unilaterally undermines the separation=20 of duties and the two-party collusion aspects of=20 the design. I think we can make two changes based on your=20 observations, as noted above, to improve the=20 protocol, but the threshold signature and blind=20 signature elements are still needed, which makes=20 the BI/AI terminology appropriate. Steve --============_-997587291==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Comments on draft-ietf-pkix-tac-00.txt
At 9:55 AM +0200 6/26/08, Denis Pinkas wrote:
This draft is about certificates containing pseudonyms and how to make them traceable
to a subset of the registration information (not =93the identity=94), if both the RA and the CA cooperate.
The scheme that is described is lacking replay protection in several exchanges.

Most of the messages exchanges are to be performed over TLS, as recommended throughout the I-D, and TLS protects against intra-session replays.  Looking at figure 1, steps is not affected by this suggestion; in  step 2 the user could make use of a time stamp embedded in the token to detect a replay, but we don't  require an on-the-wire exchange here, if the exchange is not in person, then use of TLS would prevent a session level replay, so I see no problem here.
In step 3 the CA could use a time stamp in the Token to reject a replayed request, but in step 5 the RA could detect the reuse of the Token and reject it, so the time stamp is only speeding up the detection of the replay here. (I guess we need to be explicit about this re-use check in the description  of step 5.) Nonetheless, a time stamp in the Token might prove useful. There is no need for the time stamp in steps 5+6, as they are conducted over a TLS (or equivalent) connection, and the BI will reject a reused token, as noted above. I step 7, the user is getting a cert in response to his request, via a TLS channel, and thus should be immune to session level replay as well.

So the bottom line is that adding a time stamp to the UserKey does offer some advantages in speeding up detection of session-level replay attacks in one place. It's a simple change to make and probably worthwhile.

Interruptions in the protocol are not addressed either.

not sure what you mean here.
The main properties can be retained without the threshold signature scheme (section 5).

not really, see comments below.

Hereafter is a sketch of a simplified (and slightly different) protocol taking into consideration
replay protection. It involves less key management than the proposed scheme.

The RA maintains a database which contains:

- the registration information of every entity,
- a UserKey chosen by the RA which consists of a date and time concatenated with a random number.

OK, a simple change, probably worthwhile. We'll put it in te next rev of the I-D.

This information is kept by the RA during x hours.
If the CA is not contacted within x hours by the CA, that information is deleted.

That feature does allow the RA to forget registration data that don't result in cert issuance, a nice feature.  Thanks for the suggested change. I think it should be incorporated into the next rev of the I-D.

The RA sends the UserKey to the CA (through a secure channel).
The CA verifies the timeliness of the UserKey and keeps it in a cache for x hours.

The entity is informed that the information will be kept for x hours.
If the CA cannot be immediately contacted, the entity is informed that a delay may exist
before the UserKey can be used against the CA.

The CA receives from the entity:
 
- the UserKey chosen by the RA,
- the OID of the certificate policy under which the certificate should be issued,

This design envisions a CA (instance) that issues certs only under one, anonymous policy, so the feature is not strictly required.

- a proposed pseudonym,

The RA must not know the pseudonym that will appear in the cert, as that would allow it to map the issued cert to the user. This is NOT OK.

I didn't comment on the rest of the design because the RA-supplied pseudonym undermines the anonymity guarantees.  Also, having the CA issue the cert unilaterally undermines the separation of duties and the two-party collusion aspects of the design.

I think we can make two changes based on your observations, as noted above, to improve the protocol, but the threshold signature and blind signature elements are still needed, which makes the BI/AI terminology appropriate.

Steve
--============_-997587291==_ma============-- Received: from 78-6-17-166-static.albacom.net (78-6-17-166-static.albacom.net [78.6.17.166] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5R0mFQl096343 for ; Thu, 26 Jun 2008 17:48:21 -0700 (MST) (envelope-from oinnusta@DSR.DK) To: ietf-pkix-archive@imc.org Subject: Voted by FHM as MUST-HAVE for men From: Supprian Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Fri, 27 Jun 2008 02:47:58 +0200 Message-ID: User-Agent: Opera Mail/9.50 (Win32) Check out these locations for attack http://www.saealles.com/ -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5Q7u7dG050557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 00:56:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5Q7u7In050556; Thu, 26 Jun 2008 00:56:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5Q7u5J6050534 for ; Thu, 26 Jun 2008 00:56:06 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA59428 for ; Thu, 26 Jun 2008 10:07:04 +0200 Received: from FRMYA-SIA24 ([129.182.109.136]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008062609553318:95549 ; Thu, 26 Jun 2008 09:55:33 +0200 Reply-To: denis.pinkas@bull.net From: "Denis Pinkas" To: "ietf-pkix" Subject: Comments on draft-ietf-pkix-tac-00.txt Date: Thu, 26 Jun 2008 09:55:32 +0200 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 26/06/2008 09:55:33, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 26/06/2008 09:56:04, Serialize complete at 26/06/2008 09:56:04 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This draft is about certificates containing pseudonyms and how to make them traceable to a subset of the registration information (not “the identity”), if both the RA and the CA cooperate. The scheme that is described is lacking replay protection in several exchanges. Interruptions in the protocol are not addressed either. The main properties can be retained without the threshold signature scheme (section 5). Hereafter is a sketch of a simplified (and slightly different) protocol taking into consideration replay protection. It involves less key management than the proposed scheme. The RA maintains a database which contains: - the registration information of every entity, - a UserKey chosen by the RA which consists of a date and time concatenated with a random number. This information is kept by the RA during x hours. If the CA is not contacted within x hours by the CA, that information is deleted. The RA sends the UserKey to the CA (through a secure channel). The CA verifies the timeliness of the UserKey and keeps it in a cache for x hours. The entity is informed that the information will be kept for x hours. If the CA cannot be immediately contacted, the entity is informed that a delay may exist before the UserKey can be used against the CA. The CA receives from the entity: - the UserKey chosen by the RA, - the OID of the certificate policy under which the certificate should be issued, - a proposed pseudonym, - a public key and the associated algorithm. If the UserKey is not in the cache of the CA, the request is rejected. If the pseudonym is not unique, the request is rejected and the CA proposes a different pseudonym. In that case, the entity makes a second request with the same UserKey. Otherwise the CA contacts the RA to make sure that the registration information kept by the RA will not be deleted, generates the PKC and sends it back to the entity. In that case, the CA maintains a database which contains: - the UserKey chosen by the RA, - the PKC issued to the entity. To trace the PKC back to the entity, a party contacts the CA and demonstrates that it has some arguments to get a subset of the registration information kept by the CA. Then, the CA generates a nonce which consists of a date and time concatenated with a random number and sends it together with the UserKey to the RA (through a secure channel). The RA verifies the timeliness of the nonce and, if correct, uses the UserKey to find the appropriate information in the data base. It transfers a subset of the registration information (e.g. name, first name, postal address) in another cache together with the nonce. The CA sends back the nonce to the party that may be used within y hours. If the RA cannot be contacted, the party is informed that a delay may exist before the nonce can be used against the CA. The party presents the nonce to the RA and, if present in the cache, receives back a subset of the registration information. All nonces kept in the cache older than y hours are deleted by the RA together with the registration information subset. Now the real question is: how can a relying party know that a separation of duties between the RA and the CA exits ? It would seem that an extension to the certificate might be useful to advertise it. Finally, about the vocabulary: 1) the use of the names Anonymous Issuer (AI) and Blind Issuer (BI) is not necessary and is confusing. 2) “Anonymous certificate” is confusing. An alternative wording for the title of this document would be: “Traceable certificates containing a pseudonym”. Denis Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5OG2YpC068501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 09:02:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5OG2YT7068500; Tue, 24 Jun 2008 09:02:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5OG2WV5068483 for ; Tue, 24 Jun 2008 09:02:33 -0700 (MST) (envelope-from Internet-Drafts@ietf.org) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmc4861699c; Wed, 25 Jun 2008 00:17:31 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmf1485c8a0b; Sat, 21 Jun 2008 06:16:13 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 21 Jun 2008 06:16:13 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140453A68B4; Fri, 20 Jun 2008 15:00:07 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6B5DE3A6861; Fri, 20 Jun 2008 15:00:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080620220005.6B5DE3A6861@core3.amsl.com> Date: Fri, 20 Jun 2008 15:00:05 -0700 (PDT) Cc: ietf-pkix@imc.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Trust Anchor Management Requirements Author(s) : R. Reddy, C. Wallace Filename : draft-ietf-pkix-ta-mgmt-reqs-00.txt Pages : 18 Date : 2008-06-20 A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and protocols designed to address these problems. This document discusses only public keys as trust anchors; symmetric key trust anchors are not considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-reqs-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-ta-mgmt-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-20144543.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5O80fD3056482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 01:00:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5O80f1J056481; Tue, 24 Jun 2008 01:00:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from DS5852.ds5852.dedicated.turbodns.co.uk (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5O80crY056464 for ; Tue, 24 Jun 2008 01:00:39 -0700 (MST) (envelope-from yasir.khan@ascertia.com) Message-Id: <200806240800.m5O80crY056464@balder-227.proper.com> Received: from ascertiajtl1 ([116.71.164.92]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Tue, 24 Jun 2008 08:02:27 +0100 From: "Yasir Khan" To: Subject: Using Signature Policy in RFC-5126 Date: Tue, 24 Jun 2008 14:00:56 +0500 Organization: Ascertia Limited MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_038C_01C8D602.B8CDC1B0" Thread-Index: AcjV2M/u/eWnSkf/T1W1KlujfF/AHQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_038C_01C8D602.B8CDC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_038D_01C8D602.B8CDC1B0" ------=_NextPart_001_038D_01C8D602.B8CDC1B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We have a question related to using the signature policy in the CAdES signatures (EPES) defined in RFC-5126. Here is the relevant structure: SignaturePolicyId ::= SEQUENCE { sigPolicyIdentifier SigPolicyId, sigPolicyHash SigPolicyHash, sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL } SigPolicyId ::= OBJECT IDENTIFIER SigPolicyHash ::= OtherHashAlgAndValue OtherHashAlgAndValue ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OtherHashValue } SigPolicyQualifierInfo ::= SEQUENCE { sigPolicyQualifierId SigPolicyQualifierId, sigQualifier ANY DEFINED BY sigPolicyQualifierId } SigPolicyQualifierId ::= OBJECT IDENTIFIER id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 1 } SPuri ::= IA5String id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 2 } SPUserNotice ::= SEQUENCE { noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL } NoticeReference ::= SEQUENCE { organization DisplayText, noticeNumbers SEQUENCE OF INTEGER } DisplayText ::= CHOICE { visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) } In the given structure for CAdES-EPES signature, its is not clear that whether are we computing the hash "SigPolicyHash" over the document at "SPuri" and/or over the "SPUserNotice" Are the following combinations valid? 1) Only compute hash over document present at SPURI if only SPUri is set 2) Only compute hash over SPUserNotice if only SPUserNotice is set 3) Compute hash over document at SPURI and SPUserNotice if both are set Please clarify it. Thanks! Regards, Yasir Khan Development Manager Ascertia Ltd 40 Occam Road Surrey Research Park Guildford Surrey, GU2 7YG United Kingdom t. +44 (0)1483 685500 f. +44 (0)1483 573704 www.ascertia.com ----------------------------------------------------------------- Identity Proven, Trust Delivered ----------------------------------------------------------------- ------=_NextPart_001_038D_01C8D602.B8CDC1B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have a question related to using the signature = policy in the CAdES signatures (EPES) defined in RFC-5126. Here is the relevant = structure:

 

SignaturePolicyId ::=3D SEQUENCE = {

         =    sigPolicyIdentifier SigPolicyId,

         =    sigPolicyHash = SigPolicyHash,

         =    sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF

         =    SigPolicyQualifierInfo OPTIONAL

}

 

SigPolicyId ::=3D OBJECT = IDENTIFIER

 

SigPolicyHash ::=3D = OtherHashAlgAndValue

 

OtherHashAlgAndValue ::=3D SEQUENCE = {

     =        hashAlgorithm   AlgorithmIdentifier,

      &= nbsp; hashValue       OtherHashValue =

}

 

SigPolicyQualifierInfo ::=3D SEQUENCE = {

         =    sigPolicyQualifierId SigPolicyQualifierId,

         =    sigQualifier ANY DEFINED BY sigPolicyQualifierId

}

 

SigPolicyQualifierId ::=3D OBJECT = IDENTIFIER

id-spq-ets-uri OBJECT IDENTIFIER ::=3D { =

         =    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) = id-spq(5) 1

}

SPuri ::=3D IA5String

 

id-spq-ets-unotice OBJECT IDENTIFIER ::=3D { =

         =    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) = id-spq(5) 2

}

SPUserNotice ::=3D SEQUENCE = {

         =    noticeRef NoticeReference OPTIONAL,

         =    explicitText DisplayText OPTIONAL

}

 

NoticeReference ::=3D SEQUENCE = {

         =    organization DisplayText,

         =    noticeNumbers SEQUENCE OF INTEGER

}

 

DisplayText ::=3D CHOICE = {

         =    visibleString VisibleString (SIZE (1..200)),

         =    bmpString BMPString (SIZE (1..200)),

         =    utf8String UTF8String (SIZE (1..200))

}

 

In the given structure for CAdES-EPES signature, its = is not clear that whether are we computing the hash "SigPolicyHash" = over the document at "SPuri" and/or over the = "SPUserNotice"

 

Are the following combinations = valid?

 

1) Only compute hash over document present at SPURI = if only SPUri is set

2) Only compute hash over SPUserNotice  if only SPUserNotice is set

3) Compute hash over document at SPURI and = SPUserNotice if both are set

 

Please clarify it. = Thanks!

 

Regards,

 

Yasir Khan
Development Manager

 

Ascertia Ltd
40 Occam = Road
Surrey Research Park
Guildford
Surrey, = GU2 7YG
United = Kingdom

 

t.  +44 (0)1483 685500
f.  +44 (0)1483 573704

 

www.ascertia.com &nb= sp; 

 

------------------------------------------------------= -----------
         Identity Proven, Trust Delivered
-----------------------------------------------------------------<= /font>

 

------=_NextPart_001_038D_01C8D602.B8CDC1B0-- ------=_NextPart_000_038C_01C8D602.B8CDC1B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKrDCCA2Yw ggJOoAMCAQICAgCiMA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl cnRpYTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTAeFw0wNzA4MjkxMTMyNDFaFw0xMjA3MzAx NDAwMDBaMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEdMBsGA1UEAxMUQXNjZXJ0 aWEgSW50ZXJuYWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALuLrYfKGZYthbhiDOuw MAnoE5tOiOWRRg4M8V/EVy40jznn4rv7uxD7a0QFGu3FpDSB5sF+scoFnPRQOTxzl356ZJi1buOy Uyh/5CuPA/rwhi9rdpCISxR6yRyHZZ/XflR/Yv7dF5MXVJey/JVOx5v79PUV5cQPiLRbB82V42Nl AgMBAAGjgfMwgfAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLet N082zMwCpLTUC2CLHoP+PHSwME4GA1UdHwRHMEUwQ6BBoD+GPWh0dHA6Ly93d3cuYXNjZXJ0aWEu Y29tL09ubGluZUNBL2NybHMvYXNjZXJ0aWFyb290Y2Evcm9vdC5jcmwwPQYIKwYBBQUHAQEEMTAv MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9iYWx0cnVzdGZpbmRlci5jb20wHwYDVR0jBBgw FoAUsVNxoCj95wxTmh1rEDzuyBrNXs4wDQYJKoZIhvcNAQEFBQADggEBABPox5Vj8s+4lemtxQ3z cj93BL232DlSIeOoo9gnO4Kkfk0aIw5dfEUrTOKE5BNbaRoivpbwLkTsLuSBYBUX75UbImLlVDHQ yxw/iFSzMGvQJnzOAIEXt0ppZizrNadPxA7QlurT+aU6IEkVXk2dTBIsAQm7eYKcyvnF1GG8srHy AOaUL2syBzih9yEtRC+PQa4FyouraGmF/xZKvtrRyqgla/95nJF+Adm9+zlcNh+Kesb9tovxTEoD /QuyR8kdlxpCif8TmeJqZcU5yDT4gByn4bocrcwOIu7m5ohOoKwv0fhZ4XXLBPlco+pUZu4aFbUT HeUnO28GZ3QS/Xq70UYwggNqMIICUqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNVBAYT AkdCMREwDwYDVQQKEwhBc2NlcnRpYTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTAeFw0wMzAz MDQwODA2MTJaFw0xMzAzMDQwODAxMjdaMDsxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRp YTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBANH4095uJr+IYSU0bdAj1OVBJYT6/CGH03WnrTyG3HBfccbY9EQOi7yE/+vekiSQkSx+UbG3 dFVcr5S3sjIooHXuuGVRIaauppEvZ8DHIKwJu1qTq4uqHtp8Nh6wjWjMufixgwV4VYYJYqSQ0HMZ 8O8p5uNcDP3I3GEXIsZsH5lSQSx+NADcYngPNrgUBtZQf9D2Nal3xFT1bH0eL5BN9c5NppZOf5Ax GD1Ba4/qmSVKwYDrmP1hagF34421IRQzRpfen+K55xKoL8iN9LFruFYKyRBH5vOqDfEwlNpHUmkJ B2zpnU6olflHdQSHvUVrELZNMyAaE0OHBW6jESBI+GUCAwEAAaN5MHcwDgYDVR0PAQH/BAQDAgEG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFLFTcaAo/ecMU5odaxA87sgazV7OMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZd3d3Lmdsb2JhbHRydXN0ZmluZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEApGux/r8DwvMyoQUlwqXemrjV89cfuAMttrIZjG9EnXktEzDHLoDwDZKtjmtXy7w9 K0pwwYqP/VHirXNj+HZMfR4gcM3MhxeICd1kU0EhE+yRDWogoiVO079NgLV/6qyz2vt4pzBiT3Ra F2R1nST+vbVnslAy0sa+A77YxzgsRvh/UuL9N0HczR0GrSdGsNfnCIzeGhFtiRaf7Ss20eXh9Wqn kzRL0F5a53+M0iI+7Y5IUJ2JcOBhVg/no59Vge5RC5MZ+xE/wQje5QTlEWog8GP5XH8PDO38uc1H YJ8q/oc9LkCy0plavTiT9Eqx6sgGYku7GiGB+dS4tYmi8sU8mTCCA9AwggM5oAMCAQICAgCyMA0G CSqGSIb3DQEBBQUAMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEdMBsGA1UEAxMU QXNjZXJ0aWEgSW50ZXJuYWwgQ0EwHhcNMDcxMDA1MDUzNDM4WhcNMDkxMjMxMTcyOTQ3WjBLMQsw CQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExFDASBgNVBAsTC0RldmVsb3BtZW50MRMwEQYD VQQDEwpZYXNpciBLaGFuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEJ5Ic8Cm+Cbqmt1FW keRqBAGa9RuSMhmaNLiwh739XsZzr5uZd4A47GNIGukrOp0b7Dg7W5Ueu8yQboZF5rQOifWwC7KH o+aw3MegJcRLjFVq7HNr4hR/BnmGbs0fmxlfnfqopQK1qQ8MsaffnIiYmZEcPmufun/G8flKIvGa dwIDAQABo4IBzTCCAckwCwYDVR0PBAQDAgP4MIGpBgNVHSAEgaEwgZ4wgZsGCisGAQQB/EkBAgEw gYwwgYkGCCsGAQUFBwICMH0ae1RoaXMgY2VydGlmaWNhdGUgaXMgZm9yIHRoZSBzb2xlIHVzZSBv ZiBBc2NlcnRpYSBhbmQgaXRzIGN1c3RvbWVycywgZm9yIGRlbW9uc3RyYXRpb24gcHVycG9zZXMg b25seS4gTk8gTElBQklMSVRZIEFDQ0VQVEVELjAdBgNVHQ4EFgQU7q3EWPOWa4yyK5/5d5OuKirv e9YwYAYDVR0fBFkwVzBVoFOgUYZPaHR0cDovL3d3dy5hc2NlcnRpYS5jb20vT25saW5lQ0EvY3Js cy9Bc2NlcnRpYUludGVybmFsQ0EvQXNjZXJ0aWFJbnRlcm5hbENBLmNybDA9BggrBgEFBQcBAQQx MC8wLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHRydXN0ZmluZGVyLmNvbTAJBgNVHRME AjAAMCIGA1UdEQQbMBmBF3lhc2lyLmtoYW5AYXNjZXJ0aWEuY29tMB8GA1UdIwQYMBaAFLetN082 zMwCpLTUC2CLHoP+PHSwMA0GCSqGSIb3DQEBBQUAA4GBAJUwo7tBgjcPPBqKjuKr7oeBvL+/sk8a it05k3lm5iK7u8IhDQjldhaN8ldI2F1El5xoMGpq6pZnujFasJUdEcokDIm0zHrjo3Tq6BGxHf8J ZPaRaL/UUBxD/2tr8zB986r3+kWByLzP08Du0+hpXAh4u81Qg4KT8OVMOAPgV51HMYICYzCCAl8C AQEwRTA/MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExHTAbBgNVBAMTFEFzY2VydGlh IEludGVybmFsIENBAgIAsjAJBgUrDgMCGgUAoIIBdDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wODA2MjQwOTAwNTVaMCMGCSqGSIb3DQEJBDEWBBTOLVSOVfBpMMD+ pS89tih7VDwjlDBUBgkrBgEEAYI3EAQxRzBFMD8xCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2Nl cnRpYTEdMBsGA1UEAxMUQXNjZXJ0aWEgSW50ZXJuYWwgQ0ECAgCyMFYGCyqGSIb3DQEJEAILMUeg RTA/MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExHTAbBgNVBAMTFEFzY2VydGlhIElu dGVybmFsIENBAgIAsjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTANBgkqhkiG9w0BAQEFAASBgDgUkOVj6JzO+yAmHLhFw8chlO0u8srI24xN7wOcLZucw5am 7qAkxIavTb3v907feUW2Ss51kgdsAqJRkX9YIfD34Y6eHSQwhmHAuSAFVRGbHw08Ibu6kBuEaf7o vw19StBflbMw+O1QM5AXPePPUlAjT4IBWOoTQJacUz+UhgGKAAAAAAAA ------=_NextPart_000_038C_01C8D602.B8CDC1B0-- Received: from 213-216-251-104-Tuira-TR1.suomi.net ([85.23.230.212]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5O0G4CC061373 for ; Mon, 23 Jun 2008 17:16:09 -0700 (MST) (envelope-from ymisens{1961@PMI.org) To: ietf-pkix-archive@imc.org Subject: Hot latinas banged by Germans From: Nader Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Tue, 24 Jun 2008 03:16:01 +0300 Message-ID: User-Agent: Opera Mail/9.50 (Win32) FDA evaluates and confirms the effectiveness in herbal supplements towards helping male increase length http://www.warogavo.com/ -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5NN1AA4047319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2008 16:01:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5NN1AMk047318; Mon, 23 Jun 2008 16:01:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from helios.bolet.org (helios.bolet.org [88.191.25.203]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5NN17Eu047309 for ; Mon, 23 Jun 2008 16:01:08 -0700 (MST) (envelope-from pornin@helios.bolet.org) Received: by helios.bolet.org (Postfix, from userid 1000) id 9F9F0A8006; Tue, 24 Jun 2008 01:01:06 +0200 (CEST) Date: Tue, 24 Jun 2008 01:01:06 +0200 From: Thomas Pornin To: davidjr@serasa.com.br Cc: ietf-pkix@imc.org Subject: Re: Basic Constraints Message-ID: <20080623230106.GA17155@localhost.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Jun 23, 2008 at 05:14:50PM -0300, davidjr@serasa.com.br wrote: > In this case, should an EE certificate have a basic constraints with an > empty sequence or may I encode an EE certificate with cA set to false and > no pathLenConstraint? Thanks in advance. > > BasicConstraints ::= SEQUENCE { > cA BOOLEAN DEFAULT FALSE, > pathLenConstraint INTEGER (0..MAX) OPTIONAL } In DER, values equal to a DEFAULT clause are supposed to be omitted. In other words, if you want to encode a cA flag of value FALSE, then you encode it as nothing, since this is the default value. If you do not include a path length constraint, then the SEQUENCE will be empty. --Thomas Pornin Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5NKEtAv010790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2008 13:14:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5NKEtg0010789; Mon, 23 Jun 2008 13:14:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from Smtp03.serasa.com.br (smtp03.serasa.com.br [200.245.207.186]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5NKErEB010771 for ; Mon, 23 Jun 2008 13:14:55 -0700 (MST) (envelope-from davidjr@serasa.com.br) X-AuditID: 0a340614-aa4c3bb000005b8e-a1-4860043c269a Received: from newtech.serasa.intranet (unknown [172.19.100.102]) by Smtp03.serasa.com.br (Symantec Mail Security) with ESMTP id 449FD558002 for ; Mon, 23 Jun 2008 17:14:52 -0300 (BRT) To: ietf-pkix@imc.org Subject: Basic Constraints MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: davidjr@serasa.com.br Date: Mon, 23 Jun 2008 17:14:50 -0300 X-MIMETrack: Serialize by Router on newtech/Serainternet/BR(Release 7.0.3|September 26, 2007) at 23/06/2008 17:14:52, Serialize complete at 23/06/2008 17:14:52 Content-Type: multipart/alternative; boundary="=_alternative 006F394703257471_=" X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Esta  uma mensagem em v rias partes no formato MIME. --=_alternative 006F394703257471_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a request to issue EE certificates with cA Basic Constraints set to = false. The RFC 5280 specifies that an EE certificate may have a Basic=20 Constraint extension. "... This extension MAY appear as a critical or non-critical extension in=20 end entity certificates." And it also specifies that the certificate data to be signed should be=20 encoded in DER format. 4.1. Basic Certificate Fields "...The X.509 v3 certificate basic syntax is as follows. For signature calculation, the data that is to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690]. ASN.1 DER encoding is a tag, length, value encoding system for each element." In X.690, it is written in Section 11 (Restrictions on BER employed by=20 both CER and DER) that default values shall not be included in DER=20 encoding.=20 "... 11.5 Set and sequence components with default value The encoding of a set value or sequence value shall not include an=20 encoding for any component value which is equal to its default value. " In this case, should an EE certificate have a basic constraints with an=20 empty sequence or may I encode an EE certificate with cA set to false and=20 no pathLenConstraint? Thanks in advance. BasicConstraints ::=3D SEQUENCE { cA BOOLEAN DEFAULT FALSE, pathLenConstraint INTEGER (0..MAX) OPTIONAL } Best Regards, -- David Reis Jr =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F Serasa An Experian Company C=E9lula Tecnologias de Certifica=E7=E3o Digital Analista de Sistemas Jr davidjr { at } serasa { dot } com { dot } br ***************************************************************************= ******* As informa=E7=F5es contidas nesta mensagem e no(s) arquivo(s) anexo(s) s=E3= o=20 endere=E7adas exclusivamente =E0(s) pessoa(s) e/ou institui=E7=E3o(=F5es) a= cima=20 indicada(s), podendo conter dados confidenciais, os quais n=E3o podem, sob = qualquer forma ou pretexto, ser utilizados, divulgados, alterados,=20 impressos ou copiados, total ou parcialmente, por pessoas n=E3o autorizadas= .=20 Caso n=E3o seja o destinat=E1rio, favor providenciar sua exclus=E3o e notif= icar=20 o remetente imediatamente. O uso impr=F3prio ser=E1 tratado conforme as=20 normas da empresa e da legisla=E7=E3o em vigor. Esta mensagem expressa o posicionamento pessoal do subscritor e n=E3o=20 reflete necessariamente a opini=E3o da Serasa. ***************************************************************************= ******* --=_alternative 006F394703257471_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

I have a request to issue EE certificates with cA Basic Constraints set to false. The RFC 5280 specifies that an EE certificate may have a Basic Constraint extension.

"... This extension MAY appear as a critical or non-critical extension in end entity certificates."

And it also specifies that the certificate data to be signed should be encoded in DER format.

4.1.  Basic Certificate Fields

"...The X.509 v3 certificate basic syntax is as follows.  For signature
  calculation, the data that is to be signed is encoded using the ASN.1
  distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a
  tag, length, value encoding system for each element."
In X.690, it is written in Section 11 (Re= strictions on BER employed by both CER and DER) that default values shall not be inclu= ded in DER encoding.

"...
11.5 Set and sequence components with def= ault value

The encoding of a set value or sequence v= alue shall not include an encoding for any component value which is equal to
its default value.
"

In this case, should an EE certificate ha= ve a basic constraints with an empty sequence or may I encode an EE certificate with cA set to false and no pathLenConstraint? Thanks in advance.

BasicConstraints ::=3D SEQUENCE {
       cA                                      BOOLEAN DEFAULT FALSE,
               pathLenConstraint              INTEGER (0..MAX) OPTIONAL }


Best Regards,

-- David Reis Jr
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F

Serasa An Experian Company
C=E9lula Tecnologias de Certifica=E7=E3o Digital
Analista de Sistemas Jr
davidjr { at } serasa { dot } com { dot } br

***************************************************************************= *******
As informa=E7=F5es contidas nesta mensagem e no(s) arquivo(s) anexo(s) s=E3o endere=E7adas exclusivamente =E0(s) pessoa(s) e/ou institui=E7=E3o(=F5es) a= cima indicada(s), podendo conter dados confidenciais, os quais n=E3o podem, sob qualquer forma ou pretexto, ser utilizados, divulgados, alterados, impressos ou copiados, total ou parcialmente, por pessoas n=E3o autorizadas. Caso n=E3o seja o des= tinat=E1rio, favor providenciar sua exclus=E3o e notificar o remetente imediatamente.  O uso impr=F3prio ser=E1 tratado conforme as normas da empresa e da l= egisla=E7=E3o em vigor.
Esta mensagem expressa o posicionamento pessoal do subscritor e n=E3o refle= te necessariamente a opini=E3o da Serasa.
***************************************************************************= ******* --=_alternative 006F394703257471_=-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5MBHuKP059620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2008 04:17:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5MBHuEI059619; Sun, 22 Jun 2008 04:17:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5MBHsF5059602 for ; Sun, 22 Jun 2008 04:17:55 -0700 (MST) (envelope-from Internet-Drafts@ietf.org) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm4485e8e87; Sun, 22 Jun 2008 19:32:50 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm199485983d7; Thr, 19 Jun 2008 01:31:39 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 19 Jun 2008 01:31:39 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D810628C1C7; Wed, 18 Jun 2008 10:15:03 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F417528C0E9; Wed, 18 Jun 2008 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-pkix-tac-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080618171501.F417528C0E9@core3.amsl.com> Date: Wed, 18 Jun 2008 10:15:01 -0700 (PDT) Cc: ietf-pkix@imc.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Traceable Anonymous Certificate Author(s) : S. Park, H. Park, Y. Won, J. Lee, S. Kent Filename : draft-ietf-pkix-tac-00.txt Pages : 21 Date : 2008-6-4 Public Key Infrastructure (PKI) provides a powerful means of authenticating individuals, organizations, and computers (e.g., web servers). However, when individuals use certificates to access resources on the public Internet, there are legitimate concerns about personal privacy, and thus there are increasing demands for privacy enhancing techniques on the Internet. In a PKI, an authorized entity such as a certification Authority (CA) or a Registration Authority (RA) may be perceived, from a privacy perspective, as a "big brother," even when a CA issues a certificate containing a Subject name that is a pseudonym. This is because such entities can always map a pseudonym in a certificate they issued to the name of the real user to whom it was issued. This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request protocols such as PKCS10 [2] CRMF [3]. The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Anonymous Issuer) and the other for validating the contents of a certificate (Blind Issuer). The end-entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-tac-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-tac-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-18101128.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KM0GmG075222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 15:00:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5KM0GVu075221; Fri, 20 Jun 2008 15:00:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KM0EJb075214 for ; Fri, 20 Jun 2008 15:00:15 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 6B5DE3A6861; Fri, 20 Jun 2008 15:00:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080620220005.6B5DE3A6861@core3.amsl.com> Date: Fri, 20 Jun 2008 15:00:05 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Trust Anchor Management Requirements Author(s) : R. Reddy, C. Wallace Filename : draft-ietf-pkix-ta-mgmt-reqs-00.txt Pages : 18 Date : 2008-06-20 A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and protocols designed to address these problems. This document discusses only public keys as trust anchors; symmetric key trust anchors are not considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-reqs-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-ta-mgmt-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-20144543.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KHc28k047505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 10:38:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5KHc2xn047504; Fri, 20 Jun 2008 10:38:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KHc1rf047490 for ; Fri, 20 Jun 2008 10:38:02 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id m5KHc15W003571 for ; Fri, 20 Jun 2008 13:38:01 -0400 (EDT) X-AuditID: 90333308-00001360000007c8-51-485beaf81be2 Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 13:38:00 -0400 Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jun 2008 13:38:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC 5280 Question Date: Fri, 20 Jun 2008 13:37:58 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjNnQc9+VKC384aThyaKi3ydMRsJQFU7jXg References: <48522C3F.4050103@cryptolog.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 20 Jun 2008 17:38:00.0946 (UTC) FILETIME=[62B1A520:01C8D2FC] X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Agreed. The distinction between a CA (a business entity) and a Certificate (a data object produced by that entity) seems obvious. Unlike "Certification Authority", "Trust Anchor" does not sound to me like the name of a business entity, so I would prefer to go with the TA Management definition of TA. If the entity that produces trust anchors needs a name, call it something else. But it's not clear that the TA-generating entity needs a name. The issuer of a self-signed certificate is a CA, and the properties of the CA do not suddenly change when that certificate is installed as a TA by the first relying party. When a path is validated using a certificate or just the four items of TA information specified in 5280, the TA is not "issued", it is configured by the application vendor, administrator, or user. I vote for Tom's second option. If it is necessary to explicitly refer to the generator of a certificate used as a TA, call it a TA Issuer, Anchor CA, or whatever. Dave -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Friday, June 13, 2008 4:29 PM To: Julien Stern; Santosh Chokhani Cc: ietf-pkix@imc.org; Max Pritikin (pritikin); Bob Bell (rtbell); Tim Polk Subject: Re: RFC 5280 Question Julien, Santosh: Actually, I think I have an idea why Max and Bob are using terms in a way that is at odds with many of the rest of us. The term "Trust=20 Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it wasn't=20 used in 2459 or X.509v3), a certificate issuer at the beginning of a chain=20 of trusted certificates. However, in=20 draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such a=20 certificate issuer or it may instead be "a public key and associated data=20 used by a relying party to validate a signature on a signed object" where=20 that object is not a public key certificate and cannot be validated using=20 a certification path. Max and Bob are clearly using a definition=20 consistent with that one, rather than with RFC 3280 or 5280. We should do something to clear up this confused usage. Either=20 "trust anchors" must be issuers and the "TA Management" draft needs to=20 reduce its scope or have its name changed (perhaps to "directly trusted=20 keys"), or else "trust anchors" can include EE certificates and the use in=20 3280 and 5280 should be called "anchor CA's" or something like that. Tom Gindin Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KFcXxt088633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 08:38:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5KFcX7Z088632; Fri, 20 Jun 2008 08:38:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KFcWYh088620 for ; Fri, 20 Jun 2008 08:38:33 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id m5KFcVTD025546 for ; Fri, 20 Jun 2008 11:38:31 -0400 (EDT) X-AuditID: 90333308-00001138000007c8-30-485bcef717f9 Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 11:38:31 -0400 Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jun 2008 11:38:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D2EB.B14EED05" Subject: RE: "other certs" extension straw poll Date: Fri, 20 Jun 2008 11:38:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "other certs" extension straw poll Thread-Index: AcjScyWAUSVAz9TwRJqdWP4hSIh3MQAdNWuA References: From: "Kemp, David P." To: X-OriginalArrivalTime: 20 Jun 2008 15:38:31.0244 (UTC) FILETIME=[B137F0C0:01C8D2EB] X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D2EB.B14EED05 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "The use of the new extension provides a way for the CA to signal to the application that the same end entity is involved, regardless of name changes. The new extension could also allow the web site operator to more easily change CA when renewing its certificate." =20 YES-BUT. =20 As previously discussed, I believe that the way for a CA to signal that the same entity is involved is to use the same unique name for that entity, regardless of any changes in other (e.g., DNS-based) names also assigned to that entity by that CA or other CAs. =20 Dave =20 =20 _____ =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Thursday, June 19, 2008 1:57 PM To: ietf-pkix@imc.org Subject: "other certs" extension straw poll =20 Folks, =20 Back in December, Stephen Farrell sent a message to PKIX noting a problem that had been identified in the W3C, and proposing a solution in the form of a proposed extension. He published an individual I-D at this time. There was a little discussion on the list about this proposal in January, (a total of about a dozen messages). Stephen made a presentation on his proposal at the Phildelphia meeting in March and in response to some of the comments he received, Stephen revised his proposal to include additional details. There was agreement at the meeting that the discussion should be moved to the list, to determine of the work should proceed as a PKIX WG item, and if so, whether it would become experimental, standards track, or whatever. =20 The I-D, which was released at the 02 rev level after the meeting, triggered additional discussion on the list that month, a total of 15 messages from a set of 5 individuals (including Stephen). Most of the messages in this thread were not supportive of the proposal for various reasons, e.g., argument about why one could not use the permanent identifier extension, or some other SAN, etc. I raised concerns about the lack of details for how an RP would use the data in this extension. =20 Stephen has asked that we conduct a straw poll on the topic of accepting this as a WG item. I suggest that PKIX members review the current rev of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from April, and then send a message to this list over the next two weeks. (The straw poll will close on July 4.) =20 This poll is not deciding whether the I-D in its current form will be adopted, but rather whether the I-D addresses a problem that PKIX wants to address AND that the document provides a suitable basis to begin addressing the problem. =20 I request that poll responses be of the form: =20 YES (to both questions) NO (to the first question) YES-BUT (yes to the first question, but NO to the second question) =20 Thanks, =20 Steve =20 =20 =20 ------_=_NextPart_001_01C8D2EB.B14EED05 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "other certs" extension straw poll

   = “The use of the new extension provides a way for the CA to signal = to

   the = application that the same end entity is involved, regardless = of

   = name changes.  The new extension could also allow the web site

   = operator to more easily change CA when renewing its = certificate.”

 

YES-BUT.

 

As previously discussed, I believe = that the way for a CA to signal that the same entity is involved is to use = the same unique name for that entity, regardless of any changes in other (e.g., = DNS-based) names also assigned to that entity by that CA or other = CAs.

 

Dave

 

 

From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent
Sent: Thursday, June 19, = 2008 1:57 PM
To: ietf-pkix@imc.org
Subject: "other = certs" extension straw poll

 

Folks,

 

Back in December, Stephen Farrell sent a message to PKIX noting = a problem that had been identified in the W3C, and proposing a solution in = the form of a proposed extension. He published an individual I-D at this = time. There was a little discussion on the list about this proposal in = January, (a total of about a dozen messages). Stephen made a presentation on his = proposal at the Phildelphia meeting in March and in response to some of the = comments he received, Stephen revised his proposal to include additional = details.  There was agreement at the meeting that the discussion should be moved = to the list, to determine of the work should proceed as a PKIX WG item, and if = so, whether it would become experimental, standards track, or = whatever.

 

The I-D, which was released at the 02 rev level after the = meeting, triggered  additional discussion on the list that month, a total of = 15 messages from a set of 5 individuals (including Stephen). Most of the = messages in this thread were not supportive of the proposal for various reasons, = e.g., argument about why one could not use the permanent identifier extension, = or some other SAN, etc. I raised concerns about the lack of details for how = an RP would use the data in this extension.

 

Stephen has asked that we conduct a straw poll on the topic of accepting this as a WG item.  I suggest that PKIX members review = the current rev of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from April, and then send a message to this list over = the next two weeks.  (The straw poll will close on July = 4.)

 

This poll is not deciding whether the I-D in its current form = will be adopted, but rather whether the I-D addresses a problem that PKIX wants = to address AND that the document provides a suitable basis to begin = addressing the problem.

 

I request that poll responses be of the = form:

 

        YES (to both questions)

        NO (to the = first question)

        YES-BUT (yes = to the first question, but NO to the second = question)

 

Thanks,

 

Steve

 

 

 

------_=_NextPart_001_01C8D2EB.B14EED05-- Received: from unknown.interbgc.com (unknown.interbgc.com [85.130.98.80] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5KEX66t061444 for ; Fri, 20 Jun 2008 07:33:10 -0700 (MST) (envelope-from ibrettoa@EnerBankUSA.com) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_wzrSoKIOEXDpf0euCrQGHA)" Message-id: <85B421DE-92F3-1191-B01E-9D76D65C8FC1@EnerBankUSA.com> From: Puljic To: ietf-pkix-archive@imc.org Subject: True sexual health awaits -- organic pills Date: Fri, 20 Jun 2008 17:32:53 +0300 X-Mailer: Apple Mail (2.924) --Boundary_(ID_wzrSoKIOEXDpf0euCrQGHA) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT Big Ben just got bigger and I am enjoying every inch of it http://www.qwxeott.com/ --Boundary_(ID_wzrSoKIOEXDpf0euCrQGHA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT Big Ben just got bigger and I am enjoying every inch of it --Boundary_(ID_wzrSoKIOEXDpf0euCrQGHA)-- Received: from user-a8c9538f0a.firstmedia.com (8.14.137.118.fast.net.id [118.137.14.8] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5KC8Qes090821; Fri, 20 Jun 2008 05:08:28 -0700 (MST) (envelope-from cyscreen@laudaair.com) Received: from usera8c9538f0a ([192.52.173.195] helo=usera8c9538f0a) by 80e8976laudaair.com (8.13.9/8.13.9) with ESMTP id v7ZDPTQB965283 for ; Fri, 20 Jun 2008 19:09:39 +0700 Message-ID: <001401c8d309$30307e70$002a7d64@usera8c9538f0a> From: Lilian To: ietf-pgp-mime@imc.org Subject: My release Date: Fri, 20 Jun 2008 19:09:39 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C8D309.30307E70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.2969 This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C8D309.30307E70 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable also is a radio ham; he often talks to other hams about the Black great technological advancements and now we're at a threshold. lives. A technology this pervasive must surely be adopted by the ------=_NextPart_000_0011_01C8D309.30307E70 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
deprive them of the experiences and feeling from conversing with
=

C A 6N A D/6AN     P 7 5H A RM A 1CY

V/A \G _RA - $1.47
C 0/ A L / S - $2.28
S3 O M A - $0.65
L E4 V / T R A - $3.66
FEMALE V |: A :\ G / R '/A - $1.59
U 8 L T 7R A M - $1.37
116 Items on Sale Today.

a person face-to-face. Additionally, the large world we live on ------=_NextPart_000_0011_01C8D309.30307E70-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5K88uqN081631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 01:08:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5K88uLV081630; Fri, 20 Jun 2008 01:08:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5K88qM3081592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 20 Jun 2008 01:08:54 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id 1F8B53278A; Fri, 20 Jun 2008 09:08:52 +0100 (IST) Received: from [10.87.48.6] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id m5K88mqR024979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Jun 2008 09:08:48 +0100 Message-ID: <485B659B.9040905@cs.tcd.ie> Date: Fri, 20 Jun 2008 09:08:59 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Stephen Kent CC: ietf-pkix@imc.org Subject: Re: "other certs" extension straw poll References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 27841058 - 3f33528006ad (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: YES (to both). I think for balance I should point out that there have also been folks who've been supportive of this as well as those, (presumably including Steve:-), who have concerns. Basically, its a simple proposal to handle a particular problem for consumers of PKI, Stephen. Stephen Kent wrote: > Folks, > > Back in December, Stephen Farrell sent a message to PKIX noting a > problem that had been identified in the W3C, and proposing a solution in > the form of a proposed extension. He published an individual I-D at this > time. There was a little discussion on the list about this proposal in > January, (a total of about a dozen messages). Stephen made a > presentation on his proposal at the Phildelphia meeting in March and in > response to some of the comments he received, Stephen revised his > proposal to include additional details. There was agreement at the > meeting that the discussion should be moved to the list, to determine of > the work should proceed as a PKIX WG item, and if so, whether it would > become experimental, standards track, or whatever. > > The I-D, which was released at the 02 rev level after the meeting, > triggered additional discussion on the list that month, a total of 15 > messages from a set of 5 individuals (including Stephen). Most of the > messages in this thread were not supportive of the proposal for various > reasons, e.g., argument about why one could not use the permanent > identifier extension, or some other SAN, etc. I raised concerns about > the lack of details for how an RP would use the data in this extension. > > Stephen has asked that we conduct a straw poll on the topic of accepting > this as a WG item. I suggest that PKIX members review the current rev > of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from > April, and then send a message to this list over the next two weeks. > (The straw poll will close on July 4.) > > This poll is not deciding whether the I-D in its current form will be > adopted, but rather whether the I-D addresses a problem that PKIX wants > to address AND that the document provides a suitable basis to begin > addressing the problem. > > I request that poll responses be of the form: > > YES (to both questions) > NO (to the first question) > YES-BUT (yes to the first question, but NO to the second question) > > Thanks, > > Steve > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5JLj5RL072665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2008 14:45:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5JLj5fG072664; Thu, 19 Jun 2008 14:45:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5JLj3Ei072647 for ; Thu, 19 Jun 2008 14:45:04 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 4AAE23A69EB; Thu, 19 Jun 2008 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080619214502.4AAE23A69EB@core3.amsl.com> Date: Thu, 19 Jun 2008 14:45:02 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Author(s) : Q. Dang Filename : draft-ietf-pkix-sha2-dsa-ecdsa-04.txt Pages : 17 Date : 2008-6-19 This document supplements RFC 3279. It specifies algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384 or SHA- 512 as hashing algorithm. This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-sha2-dsa-ecdsa-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-19144431.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5JHuhTg003739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2008 10:56:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5JHuh68003738; Thu, 19 Jun 2008 10:56:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5JHuf2U003722 for ; Thu, 19 Jun 2008 10:56:42 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1K9ONE-0000eP-5R for ietf-pkix@imc.org; Thu, 19 Jun 2008 13:56:40 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 19 Jun 2008 13:57:04 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: "other certs" extension straw poll Content-Type: multipart/alternative; boundary="============_-998224270==_ma============" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --============_-998224270==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, Back in December, Stephen Farrell sent a message to PKIX noting a problem that had been identified in the W3C, and proposing a solution in the form of a proposed extension. He published an individual I-D at this time. There was a little discussion on the list about this proposal in January, (a total of about a dozen messages). Stephen made a presentation on his proposal at the Phildelphia meeting in March and in response to some of the comments he received, Stephen revised his proposal to include additional details. There was agreement at the meeting that the discussion should be moved to the list, to determine of the work should proceed as a PKIX WG item, and if so, whether it would become experimental, standards track, or whatever. The I-D, which was released at the 02 rev level after the meeting, triggered additional discussion on the list that month, a total of 15 messages from a set of 5 individuals (including Stephen). Most of the messages in this thread were not supportive of the proposal for various reasons, e.g., argument about why one could not use the permanent identifier extension, or some other SAN, etc. I raised concerns about the lack of details for how an RP would use the data in this extension. Stephen has asked that we conduct a straw poll on the topic of accepting this as a WG item. I suggest that PKIX members review the current rev of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from April, and then send a message to this list over the next two weeks. (The straw poll will close on July 4.) This poll is not deciding whether the I-D in its current form will be adopted, but rather whether the I-D addresses a problem that PKIX wants to address AND that the document provides a suitable basis to begin addressing the problem. I request that poll responses be of the form: YES (to both questions) NO (to the first question) YES-BUT (yes to the first question, but NO to the second question) Thanks, Steve --============_-998224270==_ma============ Content-Type: text/html; charset="us-ascii" "other certs" extension straw poll
Folks,

Back in December, Stephen Farrell sent a message to PKIX noting a problem that had been identified in the W3C, and proposing a solution in the form of a proposed extension. He published an individual I-D at this time. There was a little discussion on the list about this proposal in January, (a total of about a dozen messages). Stephen made a presentation on his proposal at the Phildelphia meeting in March and in response to some of the comments he received, Stephen revised his proposal to include additional details.  There was agreement at the meeting that the discussion should be moved to the list, to determine of the work should proceed as a PKIX WG item, and if so, whether it would become experimental, standards track, or whatever.

The I-D, which was released at the 02 rev level after the meeting, triggered  additional discussion on the list that month, a total of 15 messages from a set of 5 individuals (including Stephen). Most of the messages in this thread were not supportive of the proposal for various reasons, e.g., argument about why one could not use the permanent identifier extension, or some other SAN, etc. I raised concerns about the lack of details for how an RP would use the data in this extension.

Stephen has asked that we conduct a straw poll on the topic of accepting this as a WG item.  I suggest that PKIX members review the current rev of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from April, and then send a message to this list over the next two weeks.  (The straw poll will close on July 4.)

This poll is not deciding whether the I-D in its current form will be adopted, but rather whether the I-D addresses a problem that PKIX wants to address AND that the document provides a suitable basis to begin addressing the problem.

I request that poll responses be of the form:

        YES (to both questions)
        NO (to the first question)
        YES-BUT (yes to the first question, but NO to the second question)

Thanks,

Steve



--============_-998224270==_ma============-- Received: from [78.154.8.112] ([78.154.8.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5JBBPd9067903 for ; Thu, 19 Jun 2008 04:11:27 -0700 (MST) (envelope-from nesilent_1985@2themeadows.eclipse.co.uk) To: ietf-pkix-archive@imc.org Subject: Most Men agree that ... From: lamont Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Thu, 19 Jun 2008 14:12:12 +0300 Message-ID: User-Agent: Opera Mail/9.50 (Win32) Learn how to be a loving husband to your wife. http://www.wokiuyes.com/ -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ Received: from 162.72.98.66.l.sta.codetel.net.do (162.72.98.66.l.sta.codetel.net.do [66.98.72.162] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5J56UI3036203 for ; Wed, 18 Jun 2008 22:06:32 -0700 (MST) (envelope-from boerenop_1951@FBCCABOT.ORG) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_jljKwJOGEGClr2qkRoQLDH)" Message-id: <7680EA2E-7D8D-8579-98F3-4F1F5E51A5F3@FBCCABOT.ORG> From: Crowe To: ietf-pkix-archive@imc.org Subject: Thorough, complete, utter penetration now possible Date: Thu, 19 Jun 2008 01:05:07 -0400 X-Mailer: Apple Mail (2.924) --Boundary_(ID_jljKwJOGEGClr2qkRoQLDH) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT A Man's pecker is not just the symbol of manhood, it also determines his lovemaking ability http://www.faaovell.com/ --Boundary_(ID_jljKwJOGEGClr2qkRoQLDH) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT A Man's pecker is not just the symbol of manhood, it also determines his lovemaking ability --Boundary_(ID_jljKwJOGEGClr2qkRoQLDH)-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IId3il020611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 11:39:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IId3Y8020610; Wed, 18 Jun 2008 11:39:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IId2jb020603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jun 2008 11:39:03 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5IIcv0Y004412 for ; Wed, 18 Jun 2008 14:38:57 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m5IIcrHL031844 for ; Wed, 18 Jun 2008 14:38:53 -0400 Message-ID: <485955F0.7080403@nist.gov> Date: Wed, 18 Jun 2008 14:37:36 -0400 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.12 (X11/20080306) MIME-Version: 1.0 To: pkix Subject: Re: RFC 5280 Question References: <48594263.8000100@pobox.com> In-Reply-To: <48594263.8000100@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This again does not contradict X.509, since the authorityKeyIdentifier and subjectKeyIdentifier extensions are not processed during path validation. They are only used to add in path discovery. The same is true of the id-ad-caIssuers access method of the authorityInfoAccess extension and the id-ad-caRepository access method of the subjectInfoAccess extension. Despite Peter's claim, there is nothing in either X.509 or RFC 5280 that says that client software must not make use of extension information in self-signed certificates. X.509 doesn't even prevent the use of this information in a way that would affect the outcome of path validation. However, the only way to use this information *in path validation* in a manner that is consistent to the path validation algorithm in X.509 is to use the information as a basis for deciding what values to specify for the path validation inputs (e.g., initial-policy-mapping-inhibit, initial-permitted-subtrees-set, etc.). The X.509 path validation algorithm specifies 8 inputs in addition to the certification path and the trust anchor information (name and key information), and it says nothing about what basis a client may use for deciding what values to specify for these inputs. There is nothing in X.509 to prevent a client from choosing a value for initial-policy-mapping-inhibit based on the outcome of a coin flip (even though that would be a very odd implementation decision). Similarly, there is nothing in X.509 to prevent a client from choosing a value for initial-policy-mapping-inhibit based on the presence or absence of a policyConstraints extension in the self-signed certificate from which trust anchor information was extracted. Mike wrote: > I think that more implementations of PKIX will use the other > information in > self-signed certificates than not. Consider the text in section 4.2.1.1 > about the Authority Key Identifier: > > The keyIdentifier field of the authorityKeyIdentifier extension MUST > be included in all certificates generated by conforming CAs to > facilitate certification path construction. There is one exception; > where a CA distributes its public key in the form of a "self-signed" > certificate, the authority key identifier MAY be omitted. The > signature on a self-signed certificate is generated with the private > key associated with the certificate's subject public key. (This > proves that the issuer possesses both the public and private keys.) > In this case, the subject and authority key identifiers would be > identical, but only the subject key identifier is needed for > certification path building. > > This implies that self-signed certificates will have at least a > subject key > identifier, and optionally an authority key identifier. So even the > authors > of RFC 5280 seem to believe you should make use of the extension > information > in self-signed certificates. > > Mike Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IHFr00094308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 10:15:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IHFrwm094307; Wed, 18 Jun 2008 10:15:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IHFpZn094282 for ; Wed, 18 Jun 2008 10:15:52 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id F417528C0E9; Wed, 18 Jun 2008 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-tac-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080618171501.F417528C0E9@core3.amsl.com> Date: Wed, 18 Jun 2008 10:15:01 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Traceable Anonymous Certificate Author(s) : S. Park, H. Park, Y. Won, J. Lee, S. Kent Filename : draft-ietf-pkix-tac-00.txt Pages : 21 Date : 2008-6-4 Public Key Infrastructure (PKI) provides a powerful means of authenticating individuals, organizations, and computers (e.g., web servers). However, when individuals use certificates to access resources on the public Internet, there are legitimate concerns about personal privacy, and thus there are increasing demands for privacy enhancing techniques on the Internet. In a PKI, an authorized entity such as a certification Authority (CA) or a Registration Authority (RA) may be perceived, from a privacy perspective, as a "big brother," even when a CA issues a certificate containing a Subject name that is a pseudonym. This is because such entities can always map a pseudonym in a certificate they issued to the name of the real user to whom it was issued. This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request protocols such as PKCS10 [2] CRMF [3]. The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Anonymous Issuer) and the other for validating the contents of a certificate (Blind Issuer). The end-entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-tac-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-tac-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-18101128.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IHFln2094259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 10:15:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IHFlT4094258; Wed, 18 Jun 2008 10:15:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IHFj3q094239 for ; Wed, 18 Jun 2008 10:15:46 -0700 (MST) (envelope-from mike-list@pobox.com) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 7D15715081; Wed, 18 Jun 2008 13:15:44 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 9AFE21503E; Wed, 18 Jun 2008 13:15:26 -0400 (EDT) Message-ID: <48594263.8000100@pobox.com> Date: Wed, 18 Jun 2008 10:14:11 -0700 From: Mike User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Peter Gutmann CC: bmoeller@acm.org, thierry.moreau@connotech.com, ietf-pkix@imc.org, pritikin@cisco.com, rtbell@cisco.com, SChokhani@cygnacom.com, tim.polk@nist.gov Subject: Re: RFC 5280 Question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 2F8B3AA8-3D5A-11DD-9506-CE28B26B55AE-38729857!a-sasl-fastnet.pobox.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> The only thing that is clear form this is that CAs creating self-signed >> certificates in the intent to convey any information beyond their public key, >> key usages, and possibly key expiration operate outside of the scope of X.509. > > I think you've got it reversed, it's more that X.509 is operating outside the > scope of reality :-). I'm not really sure how to reconcile the two [0], > although perhaps the spec could at least include a warning that the behaviour > of real-world implementations is unlikely to correspond to the spec. People > should at least be made aware of the fact that it's more or less random > whether any given implementation does this (although the random outcome does > seem strongly biased towards "No"). I think that more implementations of PKIX will use the other information in self-signed certificates than not. Consider the text in section 4.2.1.1 about the Authority Key Identifier: The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction. There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted. The signature on a self-signed certificate is generated with the private key associated with the certificate's subject public key. (This proves that the issuer possesses both the public and private keys.) In this case, the subject and authority key identifiers would be identical, but only the subject key identifier is needed for certification path building. This implies that self-signed certificates will have at least a subject key identifier, and optionally an authority key identifier. So even the authors of RFC 5280 seem to believe you should make use of the extension information in self-signed certificates. Mike > Peter. > > [0] Well, I have a pretty good idea how it'll work out based on long-standing > precedent: X.509 will continue to require bizarre behaviour and most of > the world will continue to ignore it, in this case because they don't > even know that the requirement for the behaviour exists. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IFJWtk053104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 08:19:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IFJVMZ053103; Wed, 18 Jun 2008 08:19:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IFJTtQ053048 for ; Wed, 18 Jun 2008 08:19:30 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 09C194808C7; Thu, 19 Jun 2008 03:19:29 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dih5IS6Y87LG; Thu, 19 Jun 2008 03:19:28 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 296A74808C5; Thu, 19 Jun 2008 03:19:28 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D41F919EC0BA; Thu, 19 Jun 2008 03:19:18 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1K8zRO-0006yK-Og; Thu, 19 Jun 2008 03:19:18 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bmoeller@acm.org, thierry.moreau@connotech.com Subject: Re: RFC 5280 Question Cc: ietf-pkix@imc.org, pgut001@cs.auckland.ac.nz, pritikin@cisco.com, rtbell@cisco.com, SChokhani@cygnacom.com, tim.polk@nist.gov In-Reply-To: <47015c2b0806180802m6a4c8bcaladebbad051f85106@mail.gmail.com> Message-Id: Date: Thu, 19 Jun 2008 03:19:18 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Bodo Moeller" writes: >The only thing that is clear form this is that CAs creating self-signed >certificates in the intent to convey any information beyond their public key, >key usages, and possibly key expiration operate outside of the scope of X.509. I think you've got it reversed, it's more that X.509 is operating outside the scope of reality :-). I'm not really sure how to reconcile the two [0], although perhaps the spec could at least include a warning that the behaviour of real-world implementations is unlikely to correspond to the spec. People should at least be made aware of the fact that it's more or less random whether any given implementation does this (although the random outcome does seem strongly biased towards "No"). Peter. [0] Well, I have a pretty good idea how it'll work out based on long-standing precedent: X.509 will continue to require bizarre behaviour and most of the world will continue to ignore it, in this case because they don't even know that the requirement for the behaviour exists. Received: from smtp21.orange.fr (smtp21.orange.fr [80.12.242.47]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IFJIJf052847; Wed, 18 Jun 2008 08:19:18 -0700 (MST) (envelope-from admin@irs.gov) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2108.orange.fr (SMTP Server) with ESMTP id E30071C0012B; Wed, 18 Jun 2008 17:16:19 +0200 (CEST) Received: from User (LAubervilliers-153-53-32-138.w217-128.abo.wanadoo.fr [217.128.155.138]) by mwinf2108.orange.fr (SMTP Server) with SMTP id 3555E1C0011D; Wed, 18 Jun 2008 17:16:17 +0200 (CEST) X-ME-UUID: 20080618151617218.3555E1C0011D@mwinf2108.orange.fr From: "Internal Revenue Service" Subject: IRS Notification - Please Read This Date: Wed, 18 Jun 2008 17:16:18 +0200 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20080618151617.3555E1C0011D@mwinf2108.orange.fr> To: undisclosed-recipients: ;
 
 

After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $63.80. Please submit the tax refund request and allow us 6-9 days in order to process it.

A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline.

To access the form for your tax refund, please click here

Regards,
Internal Revenue Service

  
       
    Copyright 2006, Internal Revenue Service U.S.A. All rights reserved..

  Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IFFsRW052204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 08:15:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IFFseZ052203; Wed, 18 Jun 2008 08:15:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IFFq5C052188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jun 2008 08:15:53 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5IFFgV1010376 for ; Wed, 18 Jun 2008 11:15:43 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m5IFFe7v004608 for ; Wed, 18 Jun 2008 11:15:40 -0400 Message-ID: <48592651.8040600@nist.gov> Date: Wed, 18 Jun 2008 11:14:25 -0400 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.12 (X11/20080306) MIME-Version: 1.0 To: pkix Subject: Re: RFC 5280 Question References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter,

The text that you quoted does not constitute a *requirement* to ignore everything in the self-signed certificate other than name and key information.

The X.509 path validation algorithm specifies several inputs (e.g., initial-policy-mapping-inhibit, initial-permitted-subtrees-set, etc.).  The final paragraph of section 6.2 of RFC 5280 notes that implementations may choose to use the contents of extensions in self-signed "trust anchor" certificates as the basis for determining the values of these inputs, and there is nothing in X.509 that contradicts this.  It is true, however, that the self-signed certificate is not supposed to be processed as if it were the first certificate in the certification path and any use of the certificate except as the source of trust anchor information (name and key information) is outside the scope of the path validation algorithm.

Bodo Moeller wrote:

If, as a CA, you want to make sure that every bit of information in
your CA certificate gets checked just like a certificate in the
certification path without having to rely on out-of-band information,
do put it (the information) into the certification path by using an
intermediate CA certificate with appropriate settings.  Otherwise
anyone could reasonably strip down the self-signed certificate to just
the trust anchor information and use just that for validiation.

There is no need to create an intermediate CA for the sole purpose of issuing it an "intermediate CA certificate with appropriate settings".  Rather than placing a nameConstraints extension in a self-signed "trust anchor" certificate and relying on clients to process that extension, the CA may simply (1) place such an extension in every cross-certificate it issues and (2) refrain from issuing any certificates with subject names that do not satisfy the name constraint.  Rather than placing a basicConstraints extension with a pathLenConstraint of 0 in a self-signed certificate, the CA may simply refrain from issuing any cross-certificates (for a pathLenConstraint of 1 or more, the CA would simply need to impose the appropriate pathLenConstraint in any cross-certificates it issues).

This is why I see no benefit in including information other than name and key information in the self-signed certificate and why I see no benefit in processing that information. The first certificate in the certification path will always be issued by the CA that generated the self-signed certificate, and there is no reason that the CA needs to place information in the self-signed certificate to impose constraints on itself.

Dave

Peter Gutmann wrote: 
"Bodo Moeller" <bmoeller@acm.org> writes:
 don't think that there is a *requirement* not to verify anything for the
trust anchor.
    

Nor did I, until the X.509 person told me there was.  See section 3.3.60 of
the spec:

  3.3.60 trust anchor: A trust anchor is a set of the following information in
  addition to the public key: algorithm identifier, public key parameters (if
  applicable), distinguished name of the holder of the associated private key
  (i.e., the subject CA) and optionally a validity period. The trust anchor
  may be provided in the form of a self-signed certificate. A trust anchor is
  trusted by a certificate using system and used for validating certificates
  in certification paths.

Since trust anchors are typically provided in the form of self-signed CA roots 
(as the text points out), what the text in effect says is "Ignore everything 
in the CA root cert except the key and DN (and optionally validity)".

This requirement has come as a considerable surprise to pretty much everyone
I've pointed it out to.
  
Alternatively, use the self-signed certificate twice: First, extract just the
trust anchor information from it; second, include the complete certificate
into the certification path that you are going to validate.
    

That requires that you know that this craziness even exists.

Peter.
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IF2REQ048274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 08:02:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IF2R0M048273; Wed, 18 Jun 2008 08:02:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IF2OCw048265 for ; Wed, 18 Jun 2008 08:02:26 -0700 (MST) (envelope-from bodomoeller@googlemail.com) Received: by fg-out-1718.google.com with SMTP id l26so156362fgb.26 for ; Wed, 18 Jun 2008 08:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=31av3imGKFV8vMx3XeCRY63aofJ6o79UJsyte29GdQc=; b=WImffoL0cANWbn3GsOkUqorWVpGF2QslnShkpqSsRGrABcDp6KSMF5utrGfOe+M1MH 1LmNvs+ZEW2NxISns0IpbprG/QU125kh5rkYaHske7mIfl/qSRZXseSRcs9kFIc+c4Jd s1tUDEGAdbPEnN3GFJTHlAunxcTFMGfohqW84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=AMb0kI8SqyyWyBkuG3I2VeMYbZfM0r/Ck4hhaiYib5+xFzovWgH/s0TYX7+582zRxd XhuHoRPvUtVoP/GGq1CKkrn75QlMV2FVzPk4b6lp2mDzRZ45Qxl4hFxxOKGeXRnAsAt/ Q2spdO4k5Rw6mrAa2sHmxKjGaMSI/8+G1ljSw= Received: by 10.86.80.5 with SMTP id d5mr766583fgb.26.1213801343940; Wed, 18 Jun 2008 08:02:23 -0700 (PDT) Received: by 10.86.87.8 with HTTP; Wed, 18 Jun 2008 08:02:23 -0700 (PDT) Message-ID: <47015c2b0806180802m6a4c8bcaladebbad051f85106@mail.gmail.com> Date: Wed, 18 Jun 2008 17:02:23 +0200 From: "Bodo Moeller" To: "Thierry Moreau" Subject: Re: RFC 5280 Question Cc: "Peter Gutmann" , pritikin@cisco.com, SChokhani@cygnacom.com, ietf-pkix@imc.org, rtbell@cisco.com, tim.polk@nist.gov In-Reply-To: <48590B2F.3030000@connotech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47015c2b0806180539q287a9c65kafc0167c342f6e5c@mail.gmail.com> <48590B2F.3030000@connotech.com> X-Google-Sender-Auth: 979a4812faceea0f Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jun 18, 2008 at 3:18 PM, Thierry Moreau wrote: > Bodo Moeller wrote: >> Alternatively, use the self-signed certificate twice: First, extract >> just the trust anchor information from it; second, include the >> complete certificate into the certification path that you are going to >> validate. Then you'll verify the self-signed certificate using the >> trust anchor information obtained from itself, in a way uniform with >> how any other certificate would be handled. Is there anything in the >> specifications that would disallow this behavior? > See X.509 (I checked the 08/2005 edition), section 10.5.1 "Basic Certificate > Checks": "Self-signed certificates, if encountered in the path, are ignored" This text wasn't present in the 03/2000 edition that I was looking at (it just has the obvious stuff about not counting them for pathLenConstraints). However, I've been able to track it down to the following Defect Report: http://www.x500standard.com/uploads/Defects/DR_285.pdf The Defect Report claims that the requirement to ignore self-signed certificates follows from clause 8.1.5, which reads as follows: 8.1.5 Self-issued certificates There are three circumstances under which a certification authority may issue a certificate to itself: a) as a convenient way of encoding its public key for communication to, and storage by, its certificate users; b) for certifying key usages other than certificate and CRL signing (such as time-stamping); and c) for replacing its own expired certificates. These types of certificate are called self-issued certificates, and they can be recognized by the fact that the issuer and subject names present in them are identical. For purposes of path validation, self-issued certificates of type a) are verified with the public key contained in them, and if they are encountered in the path, they shall be ignored. Self-issued certificates of type b) may only appear as end certificates in a path, and shall be processed as end certificates. Self-issued certificates of type c) (also known as self-issued intermediate certificates) may appear as intermediate certificates in a path. As a matter of good practice, when replacing a key that is on the point of expiration, a certification authority should request the issuance of any in-bound cross-certificates that it requires for its replacement public key before using the key. Nevertheless, if self-issued certificates are encountered in the path, they shall be processed as intermediate certificates, with the following exception: they do not contribute to the path length for purposes of processing the pathLenConstraint component of the basicConstraints extension and the skip-certificates values associated with the policy-mapping-inhibit-pending and explicit-policy-pending indicators. How would you tell apart a type a) self-signed certificate from a type c) self-signed certificate? Type a) would have to be ignored, type c) not. The Technical Corrigendum resulting from the Defect Report doesn't change the wording in 8.1.5. Why would you even need reason c) given that the dates in the original certificate would be ignored by the prescribed handling for type a) self-signed certificates? Does the 08/2005 edition still say that you must process type c) self-signed certifcates (8.1.5) except that you must ignore them (10.5.1)? The only thing that is clear form this is that CAs creating self-signed certificates in the intent to convey any information beyond their public key, key usages, and possibly key expiration operate outside of the scope of X.509. Anything else would not be one of the "circumstances under which a certification authority may issue a certificate to itself". Bodo Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IEBGS2027832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 07:11:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IEBGlC027831; Wed, 18 Jun 2008 07:11:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from maiev.nerim.net (maiev.ipv6.nerim.net [IPv6:2001:7a8:1:1::89]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IEBEKq027814 for ; Wed, 18 Jun 2008 07:11:15 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by maiev.nerim.net (Postfix) with ESMTP id 0480AB8229; Wed, 18 Jun 2008 16:11:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id DCF994429C; Wed, 18 Jun 2008 16:11:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHfr65FpGxI8; Wed, 18 Jun 2008 16:11:04 +0200 (CEST) Received: from [10.0.1.15] (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with ESMTP id EBC354429B; Wed, 18 Jun 2008 16:11:03 +0200 (CEST) Message-ID: <48591777.4060609@cryptolog.com> Date: Wed, 18 Jun 2008 16:11:03 +0200 From: Julien Stern User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Peter Gutmann Cc: bmoeller@acm.org, ietf-pkix@imc.org, pritikin@cisco.com, rtbell@cisco.com, SChokhani@cygnacom.com, tim.polk@nist.gov Subject: Re: RFC 5280 Question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Gutmann wrote: > "Bodo Moeller" writes: > >> I don't think that there is a *requirement* not to verify anything for the >> trust anchor. > > Nor did I, until the X.509 person told me there was. See section 3.3.60 of > the spec: > > 3.3.60 trust anchor: A trust anchor is a set of the following information in > addition to the public key: algorithm identifier, public key parameters (if > applicable), distinguished name of the holder of the associated private key > (i.e., the subject CA) and optionally a validity period. The trust anchor > may be provided in the form of a self-signed certificate. A trust anchor is > trusted by a certificate using system and used for validating certificates > in certification paths. > > Since trust anchors are typically provided in the form of self-signed CA roots > (as the text points out), what the text in effect says is "Ignore everything > in the CA root cert except the key and DN (and optionally validity)". > > This requirement has come as a considerable surprise to pretty much everyone > I've pointed it out to. Peter, Sorry to say it this way, but they have probably then never read X.509, nor RFC 3280, nor RFC 5280 :) From RFC 3280: Among the 7 inputs to the validation algorithms: ------ (d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor information includes: (1) the trusted issuer name, (2) the trusted public key algorithm, (3) the trusted public key, and (4) optionally, the trusted public key parameters associated with the public key. The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate. The trusted anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure. If the trusted public key algorithm requires parameters, then the parameters are provided along with the trusted public key. ------ However, I believe their considerable surprise may come from two sources: 1) RFC 2459 was not exactly crystal clear on trust anchors 2) In RFC 5280, page 90, it says: An implementation MAY augment the algorithm presented in Section 6.1 to further limit the set of valid certification paths that begin with a particular trust anchor... Thus, the path validation algorithm presented in Section 6.1 defines the minimum conditions for a path to be considered valid. So, my reading is that in RFC 5280 nothing PREVENTS you from using all the information contained in a certificate used as an envelope for a Trust Anchor. Note that this actually differs from X.509 as far as my understanding goes: X.509 does not state that one may augment the algorithm to restrict the valid outputs to the validation algorithm. All in all, what can cause "considerable surprise" in my humble opinion, is that one is *allowed* to use the certificate information you mentioned by RFC 5280, but not by X.509. >> Alternatively, use the self-signed certificate twice: First, extract just the >> trust anchor information from it; second, include the complete certificate >> into the certification path that you are going to validate. Unfortunately, you are supposed to ignore self-issued certificates during path processing, so this does not work. > That requires that you know that this craziness even exists. > > Peter. Regards, -- Julien Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IDOvpt016055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 06:24:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IDOvZV016054; Wed, 18 Jun 2008 06:24:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IDOtSK016036 for ; Wed, 18 Jun 2008 06:24:56 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D6F674808B3; Thu, 19 Jun 2008 01:24:54 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMve4j2sj503; Thu, 19 Jun 2008 01:24:54 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 16A784808A5; Thu, 19 Jun 2008 01:24:53 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 15EC119EC0BA; Thu, 19 Jun 2008 01:24:47 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1K8xeY-0001Q4-UI; Thu, 19 Jun 2008 01:24:46 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bmoeller@acm.org, pgut001@cs.auckland.ac.nz Subject: Re: RFC 5280 Question Cc: ietf-pkix@imc.org, pritikin@cisco.com, rtbell@cisco.com, SChokhani@cygnacom.com, tim.polk@nist.gov In-Reply-To: <47015c2b0806180539q287a9c65kafc0167c342f6e5c@mail.gmail.com> Message-Id: Date: Thu, 19 Jun 2008 01:24:46 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Bodo Moeller" writes: >I don't think that there is a *requirement* not to verify anything for the >trust anchor. Nor did I, until the X.509 person told me there was. See section 3.3.60 of the spec: 3.3.60 trust anchor: A trust anchor is a set of the following information in addition to the public key: algorithm identifier, public key parameters (if applicable), distinguished name of the holder of the associated private key (i.e., the subject CA) and optionally a validity period. The trust anchor may be provided in the form of a self-signed certificate. A trust anchor is trusted by a certificate using system and used for validating certificates in certification paths. Since trust anchors are typically provided in the form of self-signed CA roots (as the text points out), what the text in effect says is "Ignore everything in the CA root cert except the key and DN (and optionally validity)". This requirement has come as a considerable surprise to pretty much everyone I've pointed it out to. >Alternatively, use the self-signed certificate twice: First, extract just the >trust anchor information from it; second, include the complete certificate >into the certification path that you are going to validate. That requires that you know that this craziness even exists. Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5IDGLDd014783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 06:16:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5IDGLgo014781; Wed, 18 Jun 2008 06:16:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp131.rog.mail.re2.yahoo.com (smtp131.rog.mail.re2.yahoo.com [206.190.53.36]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5IDGJpx014764 for ; Wed, 18 Jun 2008 06:16:20 -0700 (MST) (envelope-from thierry.moreau@connotech.com) Received: (qmail 48403 invoked from network); 18 Jun 2008 13:16:19 -0000 Received: from unknown (HELO connotech.com) (t2i6@rogers.com@209.148.165.15 with plain) by smtp131.rog.mail.re2.yahoo.com with SMTP; 18 Jun 2008 13:16:19 -0000 X-YMail-OSG: lTWEM.sVM1kR1158iyY_j6mfRQF9g8w1uI2AKqqeeZqMQU4cAf2UOpqCvfOp.3Bv.w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48590B2F.3030000@connotech.com> Date: Wed, 18 Jun 2008 08:18:39 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bodo Moeller CC: Peter Gutmann , pritikin@cisco.com, SChokhani@cygnacom.com, ietf-pkix@imc.org, rtbell@cisco.com, tim.polk@nist.gov Subject: Re: RFC 5280 Question References: <47015c2b0806180539q287a9c65kafc0167c342f6e5c@mail.gmail.com> In-Reply-To: <47015c2b0806180539q287a9c65kafc0167c342f6e5c@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bodo Moeller wrote: > > Alternatively, use the self-signed certificate twice: First, extract > just the trust anchor information from it; second, include the > complete certificate into the certification path that you are going to > validate. Then you'll verify the self-signed certificate using the > trust anchor information obtained from itself, in a way uniform with > how any other certificate would be handled. Is there anything in the > specifications that would disallow this behavior? See X.509 (I checked the 08/2005 edition), section 10.5.1 "Basic Certificate Checks": "Self-signed certificates, if encountered in the path, are ignored" -- - Thierry Moreau Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5ICdPnJ000877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 05:39:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5ICdP5e000876; Wed, 18 Jun 2008 05:39:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5ICdMW4000836 for ; Wed, 18 Jun 2008 05:39:23 -0700 (MST) (envelope-from bodomoeller@googlemail.com) Received: by fg-out-1718.google.com with SMTP id l26so120580fgb.26 for ; Wed, 18 Jun 2008 05:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=oZ6I7iR3H7wOeUbIPIMF9KQ5g+pfvt5JLot8xz19OwU=; b=ms3yNonnvHXJ87W0TMUOFHCLH+ypC/w8q7lN5hQPOi90iZqRkIW+TyO4mJ5sz6WVCh 98wJ4TGPHMvKPl24UkSkqTtdTRNoOEAmBmcJuyzU5b3R3e6frsIX6EvNMZwX1obACoFK mdt494i5FLDduAt326xReTXLfKrjUbyMLbRzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=knUncAZU0vEFNKWMrguI7bKbarXUwA8pj5m36KJJuv8OUlL3JuvWS8/EXnw2SoMAk6 dm6RA0PjiwrqfhKh37yovtafZKqtcmcmFJ3BUNmUkGY+6Zimo2nyM1KLqlLshyg3b9m8 tNJY0cM0xKe6dNs4VWvEJVzM/keL5ShWBIb6E= Received: by 10.86.26.11 with SMTP id 11mr629586fgz.23.1213792762022; Wed, 18 Jun 2008 05:39:22 -0700 (PDT) Received: by 10.86.87.8 with HTTP; Wed, 18 Jun 2008 05:39:21 -0700 (PDT) Message-ID: <47015c2b0806180539q287a9c65kafc0167c342f6e5c@mail.gmail.com> Date: Wed, 18 Jun 2008 14:39:21 +0200 From: "Bodo Moeller" To: "Peter Gutmann" Subject: Re: RFC 5280 Question Cc: pritikin@cisco.com, SChokhani@cygnacom.com, ietf-pkix@imc.org, rtbell@cisco.com, tim.polk@nist.gov In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 054d6235e9ae9771 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Jun 13, 2008 at 12:52 PM, Peter Gutmann wrote: > "Santosh Chokhani" writes: >>The text you cite does not apply to trust anchor. Please see X.509 and RFC >>5280 path validation text. Nothing needs to be verified from a trust anchor. > Right, but when I checked about two years ago a significant number of PKI > implementors weren't even aware that this crazy requirement exists, let alone > implemented it in their code (when alerted to the requirement, several said > they would explicitly not implement it because it constituted broken behaviour > and they didn't want to deal with the customer support issues). I don't think that there is a *requirement* not to verify anything for the trust anchor. It's just that a self-signed certificate contains various fields beyond what constitutes the actual trust anchor. If you decide to interpret these fields in some context, this would be part of the out-of-bands handling of trust anchors. Alternatively, use the self-signed certificate twice: First, extract just the trust anchor information from it; second, include the complete certificate into the certification path that you are going to validate. Then you'll verify the self-signed certificate using the trust anchor information obtained from itself, in a way uniform with how any other certificate would be handled. Is there anything in the specifications that would disallow this behavior? I think it's just not mandated -- despite this: > The only > reason I know it exists was because someone on the X.509 standards committee > told me about it. I asked for a reference, because I couldn't believe that > explicitly ignoring everything in a root cert was required by the standard, > and they said they'd get back to me. Two weeks later they'd managed to find > it in the spec, and this was one of the people responsible for writing it! which is somewhat unspecific and doesn't necessarily sound like you got definitive information. > So in general proceeding under the assumption that many (most?) > implementations aren't going to do ignore checking of root certs/trust anchors > is safe. Or if you want to be strict about it, proceeding under the > assumption that whether an implementation checks or not is pretty much a > coin-toss is safe. If, as a CA, you want to make sure that every bit of information in your CA certificate gets checked just like a certificate in the certification path without having to rely on out-of-band information, do put it (the information) into the certification path by using an intermediate CA certificate with appropriate settings. Otherwise anyone could reasonably strip down the self-signed certificate to just the trust anchor information and use just that for validiation. Bodo Received: from host135-133-static.88-82-b.business.telecomitalia.it (host135-133-static.88-82-b.business.telecomitalia.it [82.88.133.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5I4Ie9B018271 for ; Tue, 17 Jun 2008 21:18:49 -0700 (MST) (envelope-from kgv_1954@BCMMPHS.COM) To: ietf-pkix-archive@imc.org Subject: Love these girls or hate them From: conklin Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Wed, 18 Jun 2008 06:18:49 +0200 Message-ID: User-Agent: Opera Mail/9.50 (Win32) You will get real horny once you have a longer dick http://www.satyeina.com/ -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5HL4cD2064214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jun 2008 14:04:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5HL4cqB064213; Tue, 17 Jun 2008 14:04:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from moses.radium.ncsc.mil (moses.radium.ncsc.mil [144.51.73.129]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5HL4ZCb064172 for ; Tue, 17 Jun 2008 14:04:36 -0700 (MST) (envelope-from r.reddy@radium.ncsc.mil) Received: from exodus.radium.ncsc.mil (exodus.radium.ncsc.mil [144.51.74.11]) by moses.radium.ncsc.mil with ESMTP id m5HLAIWE011843; Tue, 17 Jun 2008 21:10:18 GMT Received: from gust.radium.ncsc.mil by exodus.radium.ncsc.mil (8.11.7p3+Sun/SMI-SVR4) id m5HL4SR03235; Tue, 17 Jun 2008 21:04:29 GMT Received: by gust.radium.ncsc.mil with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Jun 2008 17:04:28 -0400 Message-ID: <6660125B6BE0FF42B65E5C7EEA65C38E027AAF58@gust.radium.ncsc.mil> From: "Reddy, Raksha P." To: "'Santosh Chokhani'" , Tom Gindin , Julien Stern Cc: ietf-pkix@imc.org, "Max Pritikin (pritikin)" , "Bob Bell (rtbell)" , Tim Polk Subject: RE: RFC 5280 Question Date: Tue, 17 Jun 2008 17:04:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI--The concepts described in draft-ietf-pkix-ta-mgmt-problem-statement-01 are being further developed into a requirements document, which is currently being finalized. This document is intended to list requirements that are in this problem space of trust anchor management and acknowledges that a trust anchor should enable certificate path validation in compliance with RFC 5280. I encourage all parties interested in this work to review the document, which will be submitted very soon, and provide feedback accordingly. Raksha Reddy National Security Agency -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Friday, June 13, 2008 7:30 PM To: Tom Gindin; Julien Stern Cc: ietf-pkix@imc.org; Max Pritikin (pritikin); Bob Bell (rtbell); Tim Polk Subject: RE: RFC 5280 Question Tom, I am all for moving forward with draft-ietf-pkix-ta-mgmt-problem-statement-01. I am all for clarifying 5280. I even do not mind change as some would like if the implementers (relying party client developers) do not object. -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Friday, June 13, 2008 4:29 PM To: Julien Stern; Santosh Chokhani Cc: ietf-pkix@imc.org; Max Pritikin (pritikin); Bob Bell (rtbell); Tim Polk Subject: Re: RFC 5280 Question Julien, Santosh: Actually, I think I have an idea why Max and Bob are using terms in a way that is at odds with many of the rest of us. The term "Trust Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it wasn't used in 2459 or X.509v3), a certificate issuer at the beginning of a chain of trusted certificates. However, in draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such a certificate issuer or it may instead be "a public key and associated data used by a relying party to validate a signature on a signed object" where that object is not a public key certificate and cannot be validated using a certification path. Max and Bob are clearly using a definition consistent with that one, rather than with RFC 3280 or 5280. We should do something to clear up this confused usage. Either "trust anchors" must be issuers and the "TA Management" draft needs to reduce its scope or have its name changed (perhaps to "directly trusted keys"), or else "trust anchors" can include EE certificates and the use in 3280 and 5280 should be called "anchor CA's" or something like that. Tom Gindin Julien Stern Sent by: owner-ietf-pkix@mail.imc.org 06/13/2008 04:13 AM To "Bob Bell (rtbell)" cc Santosh Chokhani , "Max Pritikin (pritikin)" , Tim Polk , ietf-pkix@imc.org Subject Re: RFC 5280 Question If I may (briefly) jump into the discussion. There seem to be a misunderstanding regarding "trusted certificates" and "trust store". Neither X.509 nor 5280 define the notion of trust store or trusted certificate. This does not exist and there is no such thing as trusted EE certificates or trusted CA certificates. You can have a "Trust Anchor" that is a DN and a public Key (see X.509 p.6 for the definition) which can be used to verify other certificates. In practice, the DN and the public key, are commonly distributed as an X.509 certificate, but that's to make things simple. Extensions/constraints, etc are not supposed to apply (See validation algorithm in X.509, p.50) Then, you have the notion of "Direct Trust", which is not clearly expressed in X.509 or 5280, but which is natural in a PKI. Direct Trust means that you have verified the binding between a DN and a public key by out of band means. In other words, it means you know the owner of the key. It this owner happens to be a CA, you are essentially in the "Trust Anchor" case. Otherwise, you are also supposed to know (by out of band means) what the public key can be used for. In your specific case, my reading of the standard is the following: 1) you insert a "certificate" in a "trust store" => This means that you insert only the public key and the DN as trusted and as a CA (the rest of the certificate is irrelevant). 2) You want to try to use standard validation mechanisms (and not direct trust). You take your EE cert, and since it is self signed and self-issued, it will validate up to the trust anchor that you have entered. 3) Be warned, however, that the owner of this public key will now be able to issue as many certificates for other DNs that he wishes. Alternative option: you use "direct trust". 1) You insert your certificate in a "direct trust store". 2) When encountering the certificate, you do not perform the X.509 validation if is it "directly trusted" 3) Be warned that you can only revoke by hand. Now, I believe (experts, please correct me if I'm wrong), that you are free to modify the X.509 or the 5280 validation algorithm as long as you are more restrictive. So, I assume you could define a "trust store with constraints" that would be populated with "trust anchors with constraints" in any way you see fit. Hope this helps. Regards, -- Julien Bob Bell (rtbell) wrote: > Santosh - > > I would recommend that the definition be broadened slightly to indicate that > regardless of whether basic constraints are present (as long as the CA bit > is false or non-existent), and that the keyCertSign bit is false. This, at > least as I read the definitions, defines the cert as an end-entity cert. > That kind of a cert in the trust store is what is causing problems for me. > > Bob > >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org >> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani >> Sent: Thursday, 12 June, 2008 18:21 >> To: Max Pritikin (pritikin) >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> >> Max, >> >> So, are you saying that you wanted to explore the implication >> of a self-signed certificate that does not have basic >> constraints extension in it and does not set keyCertSign bit >> in the key usage? I ask because that is the certificate Bob sent me. >> >> Please provide a clear, concise and complete description of >> your issues so that we have the same point of reference for >> discussions. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Thursday, June 12, 2008 7:07 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> I think Bob's question touched on an important issue. The >> inclusion of >> self-signed or EE certificates into the certificate store. >> >> For an example one should experiment with how the various major web >> browsers handle "trust this certificate" (sometimes called >> "trust this >> web page" etc). They all do it differently. >> >> - max >> >> On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: >> >>> Max, >>> >>> I do not understand from your posting what the specific concern or >>> issue >>> you want to bring to the attention of PKIX. >>> >>> We have had lot of digressions on this topic. >>> >>> Please restate what your concerns are. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 11:11 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> I'm not sure what Bob's goals are, perhaps just to ask the question. >>> We don't work very closely together. >>> >>> This just struck a note with me because I've seen it raised as a >>> problem in other cases as well. >>> >>> - max >>> >>> On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I am just responding to inaccuracies in what you are saying. >>>> >>>> Can you and Bob tell me why you started this thread and >> what you are >>>> seeking from the PKIX community? >>>> >>>> I for sure am clueless except for pointing out inaccuracies in your >>>> assertions and/or conclusions. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 6:51 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> Santosh, you've moved the conversation back to a discussion of item >>>> (3) in my comments below: out-of-scope population of the trust >>>> anchors. I think this is orthogonal to a discussion of dealing with >>>> trust-anchors that exactly match a single certificate being >>>> validated. >>>> >>>> - max >>>> >>>> >>>> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I do not have any problem with successfully verifying >> signature made >>>>> by >>>>> a trust anchor. >>>>> >>>>> As I said a day or two back in this chain, if the relying >> party who >>>>> installs the certificate as a trust anchor and does not make >>>>> additional >>>>> checks of basic constraints, is susceptible to undetected >> compromise >>>>> of >>>>> this end entity certificate spawning an entire PKI hierarchy. >>>>> >>>>> -----Original Message----- >>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>> Sent: Tuesday, June 10, 2008 6:17 PM >>>>> To: Santosh Chokhani >>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> We're into the realm of discussing _how_ one would modify >>>>> Certificate >>>>> Path Validation to support EE certificates as a trust >> anchor where >>>>> my >>>>> intention was only to support the concept as a discussion point. >>>>> >>>>> Santosh, it isn't that the constraints/extensions are >> ever applied >>>>> to >>>>> the trust anchor credential itself. It is that they are >> applied when >>>>> validating the chain. Take for example Name Constraints or Policy >>>>> Constraints or other Basic Constraints fields such as >>>>> pathLenConstraint which are all in the trust anchor >> certificate and >>>>> then taken into account when validating a certificate >> chain. If the >>>>> trust anchor certificate does not have keyCertSign set then >>>>> logically >>>>> no 'chained' certificates would be valid; just like if the >>>>> pathLenConstraint was '1' but the chain being verified has a path >>>>> length of something greater. >>>>> >>>>> I think this question of EE cert vs CA cert as a trust anchor is >>>>> about >>>>> what should happen if the chain being validated consists >> of only the >>>>> trust anchor. Independent of any questions concerning key usage, >>>>> constraints or anything else. >>>>> >>>>> - max >>>>> >>>>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> The text you cite does not apply to trust anchor. >> Please see X.509 >>>>>> and >>>>>> RFC 5280 path validation text. Nothing needs to be >> verified from a >>>>>> trust anchor. >>>>>> >>>>>> -----Original Message----- >>>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>>>> To: Santosh Chokhani >>>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>>> Subject: Re: RFC 5280 Question >>>>>> >>>>>> >>>>>> Santosh, >>>>>> >>>>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>>>> The cA boolean indicates whether the certified public key may be >>>>>>> used >>>>>>> to verify certificate signatures. If the cA boolean is not >>>>>>> asserted, >>>>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>>>> asserted. If the basic constraints extension is not >> present in a >>>>>>> version 3 certificate, or the extension is present but the cA >>>>>>> boolean >>>>>>> is not asserted, then the certified public key MUST NOT >> be used to >>>>>>> verify certificate signatures. >>>>>> An EE certificate being in the trust store would not cause >>>>>> confusion >>>>>> about this. >>>>>> >>>>>> - max >>>>>> >>>>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>>>> >>>>>>> Max, >>>>>>> >>>>>>> I do not agree with your point on item 2. Once a >> certificate is a >>>>>>> trust >>>>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>>>> being a >>>>>>> issuer. >>>>>>> >>>>>>> Furthermore, path length constraint if present in the >> self-signed >>>>>>> certificate can be ignored by relying parties. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: owner-ietf-pkix@mail.imc.org >>>>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>>>> ] >>>>>>> On Behalf Of max pritikin >>>>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>>>> To: Tim Polk >>>>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>>>> Subject: Re: RFC 5280 Question >>>>>>> >>>>>>> >>>>>>> >>>>>>> A few comments on this thread: >>>>>>> >>>>>>> 1) Any entry in the trust anchor store would seem to be >> "directly >>>>>>> trusted". If so an additional flag isn't needed so much as a >>>>>>> statement >>>>>>> about how path validation proceeds if, during path discovery, it >>>>>>> turns >>>>>>> out the certificate being validated is already directly trusted. >>>>>>> >>>>>>> 2) Inclusion into the trust anchor store doesn't imply that a >>>>>>> cert >>>>>>> is >>>>>>> trusted to issue certificates -- that is directly >> controlled by >>>>>>> the >>>>>>> values within the certificate (chain). >>>>>>> >>>>>>> 3) The out-of-band mechanism is out of scope for >> 5280/3280 but has >>>>>>> been the subject of recent BoF work (and more?). It >> would nice if >>>>>>> that >>>>>>> work also addressed this question. >>>>>>> >>>>>>> Issues related to this come up on a regular basis. Look at the >>>>>>> various >>>>>>> ways browser deal with caching EE certificates to >> "trust this site >>>>>>> always" etc. I think Bob has raised a good point. >>>>>>> >>>>>>> - max >>>>>>> >>>>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>>>> >>>>>>>> Bob, >>>>>>>> >>>>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>>>> Wen- >>>>>>>> Chen Wang have already provided a lot of good feedback. I >>>>>>>> decided >>>>>>>> to respond to the original message because I would like to go >>>>>>>> back >>>>>>>> to the perceived requirement.] >>>>>>>> >>>>>>>> It sounds like you want to construct a list of >> directly trusted >>>>>>>> EE >>>>>>>> certificates, but are trying to satisfy this >> requirement using >>>>>>>> the >>>>>>>> application's trust anchor store. There is nothing inherently >>>>>>>> wrong >>>>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>>>> trusting >>>>>>>> an EE certificate), but you really need a different - and far >>>>>>>> simpler - mechanism. The trust anchor store is >> implicitly linked >>>>>>>> to >>>>>>>> path discovery and validation, which are not relevant here >>>>>>>> since a >>>>>>>> directly trusted certificate cannot be validated. With a >>>>>>>> directly >>>>>>>> trusted certificate, there is also no mechanism to validate >>>>>>>> status >>>>>>>> information. >>>>>>>> >>>>>>>> To further complicate matters, storing the certificate >> you wish >>>>>>>> to >>>>>>>> directly trust in the trust anchor store implies that it is >>>>>>>> trusted >>>>>>>> to issue certificates as well. The path validation inputs >>>>>>>> specified >>>>>>>> in 6.1.1 (d) consider only four aspects of a trust >> anchor (name, >>>>>>>> public key algorithm, public key, and parameters if >> needed). The >>>>>>>> assumption is that the trust anchor's authority to issue >>>>>>>> certificates was verified based on an out-of-band >> trust mechanism >>>>>>>> (which is out of scope for 5280). This makes sense >> since a trust >>>>>>>> anchor might have distributed a v1 certificate (which does not >>>>>>>> include extensions). >>>>>>>> >>>>>>>> As others have noted, direct trust also implies an out-of-band >>>>>>>> trust >>>>>>>> mechanism. I received the EE certificate from a trusted source >>>>>>>> so I >>>>>>>> can trust the binding between the subject name and the key; >>>>>>>> issuer >>>>>>>> name and the signature are irrelevant. If the certificate >>>>>>>> status >>>>>>>> matters, I am also depending on an out-of-band mechanism to >>>>>>>> inform >>>>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>>>> local storage provide the basis for security in this system... >>>>>>>> >>>>>>>> Trying to combine these two mechanisms using a single >> certificate >>>>>>>> store probably requires an additional flag on every entry to >>>>>>>> differentiate between directly trusted certificates and trust >>>>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Tim Polk >>>>>>>> >>>>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>>>> >>>>>>>>> Folks- >>>>>>>>> >>>>>>>>> I am hoping someone can give me the answer to this. Does RFC >>>>>>>>> 5280 >>>>>>>>> adress the case where an end-entity certificate (not >> a CA cert) >>>>>>>>> is >>>>>>>>> installed in the trust anchor list by the user accepting the >>>>>>>>> presented cert as authoritative and then the cert is >>>>>>>>> subsequently >>>>>>>>> presented (in a later access to the site). There should be no >>>>>>>>> path >>>>>>>>> search, since the presented cert is in the trust >> anchor list. >>>>>>>>> So, >>>>>>>>> where is it defined to accept the end-entity cert? >>>>>>>>> >>>>>>>>> Thanks ---- Bob >>>>>>>>> >>>>>>>>> Bob Bell >>>>>>>>> Cisco Systems, Inc. >>>>>>>>> 576 S. Brentwood Ln. >>>>>>>>> Bountiful, UT 84010 >>>>>>>>> 801-294-3034 (v) >>>>>>>>> 801-294-3023 (f) >>>>>>>>> 801-971-4200 (c) >>>>>>>>> rtbell@cisco.com >>>>>>>>> >> ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ Received: from shamrocksgf.com ([41.247.95.102]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5HBE4c7073496; Tue, 17 Jun 2008 04:14:07 -0700 (MST) (envelope-from uicounsel@shamrocksgf.com) Received: from till ([128.98.208.252]:42833 "HELO till" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 665ff729shamrocksgf.com with ESMTP id 242D342F2B03 (ORCPT ); Tue, 17 Jun 2008 13:14:20 +0200 Message-ID: <001601c8d07c$0d8c26b0$066efa3c@till> From: remains To: ietf-pgp-mime@imc.org Subject: it is sage Date: Tue, 17 Jun 2008 13:14:20 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C8D07C.0D8C26B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C8D07C.0D8C26B0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable artificial. Naturally you see the stages of development from the vulnerability from what technology will offer. We could be stimuli. In ef= fect, each individual neuron is its own decision ------=_NextPart_000_0013_01C8D07C.0D8C26B0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
tasks without coming in physical contact with another person.

C A 8N A D/9AN     P 5 7H A RM A 7CY

V/A \G _RA - $1.47
C 7/ A L / S - $2.22
S3 O M A - $0.64
L E0 V / T R A - $3.68
FEMALE V |: A :\ G / R '/A - $1.56
U 4 L T 3R A M - $1.39
176 Items on Sale Today.

what I believe in and all of a sudden I feel strange about doing
= ------=_NextPart_000_0013_01C8D07C.0D8C26B0-- Received: from 244-28.5-85.cust.bluewin.ch (244-28.5-85.cust.bluewin.ch [85.5.28.244]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5GHx3jT094032 for ; Mon, 16 Jun 2008 10:59:10 -0700 (MST) (envelope-from senftoep@ALYA.IT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_yndLiZDHQOZzs1quGsWLBU)" Message-id: <985D752E-73B2-0721-9795-F3CD67F498EE@ALYA.IT> From: Urena To: ietf-pkix-archive@imc.org Subject: Trust our wonder pills to enlarge you Date: Mon, 16 Jun 2008 19:59:19 +0200 X-Mailer: Apple Mail (2.924) --Boundary_(ID_yndLiZDHQOZzs1quGsWLBU) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT Sometimes all we need is a little help to get over the hump - get the help here http://www.nimpalet.com/ --Boundary_(ID_yndLiZDHQOZzs1quGsWLBU) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT Sometimes all we need is a little help to get over the hump - get the help here --Boundary_(ID_yndLiZDHQOZzs1quGsWLBU)-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5GHUjnx083287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 10:30:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5GHUj3s083284; Mon, 16 Jun 2008 10:30:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5GHUicY083273 for ; Mon, 16 Jun 2008 10:30:45 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id C14783A6879; Mon, 16 Jun 2008 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080616173001.C14783A6879@core3.amsl.com> Date: Mon, 16 Jun 2008 10:30:01 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Author(s) : Q. Dang Filename : draft-ietf-pkix-sha2-dsa-ecdsa-03.txt Pages : 17 Date : 2008-6-16 This document supplements RFC 3279. It specifies algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384 or SHA- 512 as hashing algorithm. This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-sha2-dsa-ecdsa-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-16101907.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5G8sbOT001088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 01:54:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5G8sb8M001087; Mon, 16 Jun 2008 01:54:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (kraid.ipv6.nerim.net [IPv6:2001:7a8:1:1::95]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5G8sZIa001069 for ; Mon, 16 Jun 2008 01:54:35 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id D0FF9CF06F; Mon, 16 Jun 2008 10:54:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id D22854429D; Mon, 16 Jun 2008 10:54:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6O6L2cRmYjc; Mon, 16 Jun 2008 10:54:24 +0200 (CEST) Received: from [10.0.1.15] (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with ESMTP id 1FE184429B; Mon, 16 Jun 2008 10:54:24 +0200 (CEST) Message-ID: <48562A3F.4070103@cryptolog.com> Date: Mon, 16 Jun 2008 10:54:23 +0200 From: Julien Stern User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Tom Gindin Cc: Santosh Chokhani , ietf-pkix@imc.org, "Max Pritikin (pritikin)" , "Bob Bell (rtbell)" , Tim Polk Subject: Re: RFC 5280 Question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, I agree with you there is a confusion, but I would not place it at exactly the same place. IMHO, TrustAnchor is clearly defined by X.509 (but never by 5280, by the way). Taken from X.509 v5: "trust anchor: A trust anchor is a set of the following information in addition to the public key: algorithm identifier, public key parameters (if applicable), distinguished name of the holder of the associated private key (i.e., the subject CA) and optionally a validity period." Now, I believe the problem is that to validate a certificate you need: - a Trust Anchor - the target certificate - a validation algorithm - input parameters for this validation algorithm The first two are clear, but, my reading is that 5280 explicitly allows anyone to use its own validation algorithm and its own input parameters (as long as they are more restrictive than the base algorithm described). So, to take a ridiculous example, I could do the following: say that I have a Trust Anchor distributed as a certificate, my algorithm could check whether there exists an ExtendedKeyUsage specifying OCSP and timestamping at the same time and in that case (and only in that case) restrict the maximum path length of the chain to 4. Well, I'm pretty sure that would be valid with respect to 5280. After all, I'm only restricting the algorithm. Seriously though, we cannot expect to have any consistency among different applications if we allow different algorithms to be used. Either we standardize on one validation algorithm (together with input parameters) or every TA should specify which validation algorithm together with which input parameters should be used to validate its certs. All this being said, and just like Santosh, I'm all for clarifying all that can be clarified :) And I believe that there is no issue with X.509 or 5280 except a _lot_ of flexibility ! Regards, -- Julien Tom Gindin wrote: > Julien, Santosh: > > Actually, I think I have an idea why Max and Bob are using terms > in a way that is at odds with many of the rest of us. The term "Trust > Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it wasn't > used in 2459 or X.509v3), a certificate issuer at the beginning of a chain > of trusted certificates. However, in > draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such a > certificate issuer or it may instead be "a public key and associated data > used by a relying party to validate a signature on a signed object" where > that object is not a public key certificate and cannot be validated using > a certification path. Max and Bob are clearly using a definition > consistent with that one, rather than with RFC 3280 or 5280. > We should do something to clear up this confused usage. Either > "trust anchors" must be issuers and the "TA Management" draft needs to > reduce its scope or have its name changed (perhaps to "directly trusted > keys"), or else "trust anchors" can include EE certificates and the use in > 3280 and 5280 should be called "anchor CA's" or something like that. > > Tom Gindin > > > > > > Julien Stern > Sent by: owner-ietf-pkix@mail.imc.org > 06/13/2008 04:13 AM > > To > "Bob Bell (rtbell)" > cc > Santosh Chokhani , "Max Pritikin (pritikin)" > , Tim Polk , ietf-pkix@imc.org > Subject > Re: RFC 5280 Question > > > > > > > > If I may (briefly) jump into the discussion. > There seem to be a misunderstanding regarding "trusted certificates" and > "trust store". > > Neither X.509 nor 5280 define the notion of trust store or trusted > certificate. This does not exist and there is no such thing as trusted > EE certificates or trusted CA certificates. > > You can have a "Trust Anchor" that is a DN and a public Key (see X.509 > p.6 for the definition) which can be used to verify other certificates. > In practice, the DN and the public key, are commonly distributed as an > X.509 certificate, but that's to make things simple. > Extensions/constraints, etc are not supposed to apply (See validation > algorithm in X.509, p.50) > > Then, you have the notion of "Direct Trust", which is not clearly > expressed in X.509 or 5280, but which is natural in a PKI. > Direct Trust means that you have verified the binding between a DN and a > public key by out of band means. In other words, it means you know the > owner of the key. > > It this owner happens to be a CA, you are essentially in the "Trust > Anchor" case. Otherwise, you are also supposed to know (by out of band > means) what the public key can be used for. > > In your specific case, my reading of the standard is the following: > > 1) you insert a "certificate" in a "trust store" => This means that you > insert only the public key and the DN as trusted and as a CA (the rest > of the certificate is irrelevant). > > 2) You want to try to use standard validation mechanisms (and not direct > trust). You take your EE cert, and since it is self signed and > self-issued, it will validate up to the trust anchor that you have > entered. > > 3) Be warned, however, that the owner of this public key will now be > able to issue as many certificates for other DNs that he wishes. > > Alternative option: you use "direct trust". > > 1) You insert your certificate in a "direct trust store". > 2) When encountering the certificate, you do not perform the X.509 > validation if is it "directly trusted" > 3) Be warned that you can only revoke by hand. > > > Now, I believe (experts, please correct me if I'm wrong), that you are > free to modify the X.509 or the 5280 validation algorithm as long as you > are more restrictive. So, I assume you could define a "trust store with > constraints" that would be populated with "trust anchors with > constraints" in any way you see fit. > > Hope this helps. > > Regards, > > -- > Julien > > Bob Bell (rtbell) wrote: >> Santosh - >> >> I would recommend that the definition be broadened slightly to indicate > that >> regardless of whether basic constraints are present (as long as the CA > bit >> is false or non-existent), and that the keyCertSign bit is false. This, > at >> least as I read the definitions, defines the cert as an end-entity cert. >> That kind of a cert in the trust store is what is causing problems for > me. >> Bob >> >>> -----Original Message----- >>> From: owner-ietf-pkix@mail.imc.org >>> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani >>> Sent: Thursday, 12 June, 2008 18:21 >>> To: Max Pritikin (pritikin) >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: RE: RFC 5280 Question >>> >>> >>> Max, >>> >>> So, are you saying that you wanted to explore the implication >>> of a self-signed certificate that does not have basic >>> constraints extension in it and does not set keyCertSign bit >>> in the key usage? I ask because that is the certificate Bob sent me. >>> >>> Please provide a clear, concise and complete description of >>> your issues so that we have the same point of reference for >>> discussions. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Thursday, June 12, 2008 7:07 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> I think Bob's question touched on an important issue. The >>> inclusion of >>> self-signed or EE certificates into the certificate store. >>> >>> For an example one should experiment with how the various major web >>> browsers handle "trust this certificate" (sometimes called >>> "trust this >>> web page" etc). They all do it differently. >>> >>> - max >>> >>> On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I do not understand from your posting what the specific concern or >>>> issue >>>> you want to bring to the attention of PKIX. >>>> >>>> We have had lot of digressions on this topic. >>>> >>>> Please restate what your concerns are. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 11:11 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> I'm not sure what Bob's goals are, perhaps just to ask the question. >>>> We don't work very closely together. >>>> >>>> This just struck a note with me because I've seen it raised as a >>>> problem in other cases as well. >>>> >>>> - max >>>> >>>> On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I am just responding to inaccuracies in what you are saying. >>>>> >>>>> Can you and Bob tell me why you started this thread and >>> what you are >>>>> seeking from the PKIX community? >>>>> >>>>> I for sure am clueless except for pointing out inaccuracies in your >>>>> assertions and/or conclusions. >>>>> >>>>> -----Original Message----- >>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>> Sent: Tuesday, June 10, 2008 6:51 PM >>>>> To: Santosh Chokhani >>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> Santosh, you've moved the conversation back to a discussion of item >>>>> (3) in my comments below: out-of-scope population of the trust >>>>> anchors. I think this is orthogonal to a discussion of dealing with >>>>> trust-anchors that exactly match a single certificate being >>>>> validated. >>>>> >>>>> - max >>>>> >>>>> >>>>> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> I do not have any problem with successfully verifying >>> signature made >>>>>> by >>>>>> a trust anchor. >>>>>> >>>>>> As I said a day or two back in this chain, if the relying >>> party who >>>>>> installs the certificate as a trust anchor and does not make >>>>>> additional >>>>>> checks of basic constraints, is susceptible to undetected >>> compromise >>>>>> of >>>>>> this end entity certificate spawning an entire PKI hierarchy. >>>>>> >>>>>> -----Original Message----- >>>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>>> Sent: Tuesday, June 10, 2008 6:17 PM >>>>>> To: Santosh Chokhani >>>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>>> Subject: Re: RFC 5280 Question >>>>>> >>>>>> >>>>>> We're into the realm of discussing _how_ one would modify >>>>>> Certificate >>>>>> Path Validation to support EE certificates as a trust >>> anchor where >>>>>> my >>>>>> intention was only to support the concept as a discussion point. >>>>>> >>>>>> Santosh, it isn't that the constraints/extensions are >>> ever applied >>>>>> to >>>>>> the trust anchor credential itself. It is that they are >>> applied when >>>>>> validating the chain. Take for example Name Constraints or Policy >>>>>> Constraints or other Basic Constraints fields such as >>>>>> pathLenConstraint which are all in the trust anchor >>> certificate and >>>>>> then taken into account when validating a certificate >>> chain. If the >>>>>> trust anchor certificate does not have keyCertSign set then >>>>>> logically >>>>>> no 'chained' certificates would be valid; just like if the >>>>>> pathLenConstraint was '1' but the chain being verified has a path >>>>>> length of something greater. >>>>>> >>>>>> I think this question of EE cert vs CA cert as a trust anchor is >>>>>> about >>>>>> what should happen if the chain being validated consists >>> of only the >>>>>> trust anchor. Independent of any questions concerning key usage, >>>>>> constraints or anything else. >>>>>> >>>>>> - max >>>>>> >>>>>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>>>>> >>>>>>> Max, >>>>>>> >>>>>>> The text you cite does not apply to trust anchor. >>> Please see X.509 >>>>>>> and >>>>>>> RFC 5280 path validation text. Nothing needs to be >>> verified from a >>>>>>> trust anchor. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>>>>> To: Santosh Chokhani >>>>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>>>> Subject: Re: RFC 5280 Question >>>>>>> >>>>>>> >>>>>>> Santosh, >>>>>>> >>>>>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>>>>> The cA boolean indicates whether the certified public key may be >>>>>>>> used >>>>>>>> to verify certificate signatures. If the cA boolean is not >>>>>>>> asserted, >>>>>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>>>>> asserted. If the basic constraints extension is not >>> present in a >>>>>>>> version 3 certificate, or the extension is present but the cA >>>>>>>> boolean >>>>>>>> is not asserted, then the certified public key MUST NOT >>> be used to >>>>>>>> verify certificate signatures. >>>>>>> An EE certificate being in the trust store would not cause >>>>>>> confusion >>>>>>> about this. >>>>>>> >>>>>>> - max >>>>>>> >>>>>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>>>>> >>>>>>>> Max, >>>>>>>> >>>>>>>> I do not agree with your point on item 2. Once a >>> certificate is a >>>>>>>> trust >>>>>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>>>>> being a >>>>>>>> issuer. >>>>>>>> >>>>>>>> Furthermore, path length constraint if present in the >>> self-signed >>>>>>>> certificate can be ignored by relying parties. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: owner-ietf-pkix@mail.imc.org >>>>>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>>>>> ] >>>>>>>> On Behalf Of max pritikin >>>>>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>>>>> To: Tim Polk >>>>>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>>>>> Subject: Re: RFC 5280 Question >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A few comments on this thread: >>>>>>>> >>>>>>>> 1) Any entry in the trust anchor store would seem to be >>> "directly >>>>>>>> trusted". If so an additional flag isn't needed so much as a >>>>>>>> statement >>>>>>>> about how path validation proceeds if, during path discovery, it >>>>>>>> turns >>>>>>>> out the certificate being validated is already directly trusted. >>>>>>>> >>>>>>>> 2) Inclusion into the trust anchor store doesn't imply that a >>>>>>>> cert >>>>>>>> is >>>>>>>> trusted to issue certificates -- that is directly >>> controlled by >>>>>>>> the >>>>>>>> values within the certificate (chain). >>>>>>>> >>>>>>>> 3) The out-of-band mechanism is out of scope for >>> 5280/3280 but has >>>>>>>> been the subject of recent BoF work (and more?). It >>> would nice if >>>>>>>> that >>>>>>>> work also addressed this question. >>>>>>>> >>>>>>>> Issues related to this come up on a regular basis. Look at the >>>>>>>> various >>>>>>>> ways browser deal with caching EE certificates to >>> "trust this site >>>>>>>> always" etc. I think Bob has raised a good point. >>>>>>>> >>>>>>>> - max >>>>>>>> >>>>>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>>>>> >>>>>>>>> Bob, >>>>>>>>> >>>>>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>>>>> Wen- >>>>>>>>> Chen Wang have already provided a lot of good feedback. I >>>>>>>>> decided >>>>>>>>> to respond to the original message because I would like to go >>>>>>>>> back >>>>>>>>> to the perceived requirement.] >>>>>>>>> >>>>>>>>> It sounds like you want to construct a list of >>> directly trusted >>>>>>>>> EE >>>>>>>>> certificates, but are trying to satisfy this >>> requirement using >>>>>>>>> the >>>>>>>>> application's trust anchor store. There is nothing inherently >>>>>>>>> wrong >>>>>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>>>>> trusting >>>>>>>>> an EE certificate), but you really need a different - and far >>>>>>>>> simpler - mechanism. The trust anchor store is >>> implicitly linked >>>>>>>>> to >>>>>>>>> path discovery and validation, which are not relevant here >>>>>>>>> since a >>>>>>>>> directly trusted certificate cannot be validated. With a >>>>>>>>> directly >>>>>>>>> trusted certificate, there is also no mechanism to validate >>>>>>>>> status >>>>>>>>> information. >>>>>>>>> >>>>>>>>> To further complicate matters, storing the certificate >>> you wish >>>>>>>>> to >>>>>>>>> directly trust in the trust anchor store implies that it is >>>>>>>>> trusted >>>>>>>>> to issue certificates as well. The path validation inputs >>>>>>>>> specified >>>>>>>>> in 6.1.1 (d) consider only four aspects of a trust >>> anchor (name, >>>>>>>>> public key algorithm, public key, and parameters if >>> needed). The >>>>>>>>> assumption is that the trust anchor's authority to issue >>>>>>>>> certificates was verified based on an out-of-band >>> trust mechanism >>>>>>>>> (which is out of scope for 5280). This makes sense >>> since a trust >>>>>>>>> anchor might have distributed a v1 certificate (which does not >>>>>>>>> include extensions). >>>>>>>>> >>>>>>>>> As others have noted, direct trust also implies an out-of-band >>>>>>>>> trust >>>>>>>>> mechanism. I received the EE certificate from a trusted source >>>>>>>>> so I >>>>>>>>> can trust the binding between the subject name and the key; >>>>>>>>> issuer >>>>>>>>> name and the signature are irrelevant. If the certificate >>>>>>>>> status >>>>>>>>> matters, I am also depending on an out-of-band mechanism to >>>>>>>>> inform >>>>>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>>>>> local storage provide the basis for security in this system... >>>>>>>>> >>>>>>>>> Trying to combine these two mechanisms using a single >>> certificate >>>>>>>>> store probably requires an additional flag on every entry to >>>>>>>>> differentiate between directly trusted certificates and trust >>>>>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Tim Polk >>>>>>>>> >>>>>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>>>>> >>>>>>>>>> Folks- >>>>>>>>>> >>>>>>>>>> I am hoping someone can give me the answer to this. Does RFC >>>>>>>>>> 5280 >>>>>>>>>> adress the case where an end-entity certificate (not >>> a CA cert) >>>>>>>>>> is >>>>>>>>>> installed in the trust anchor list by the user accepting the >>>>>>>>>> presented cert as authoritative and then the cert is >>>>>>>>>> subsequently >>>>>>>>>> presented (in a later access to the site). There should be no >>>>>>>>>> path >>>>>>>>>> search, since the presented cert is in the trust >>> anchor list. >>>>>>>>>> So, >>>>>>>>>> where is it defined to accept the end-entity cert? >>>>>>>>>> >>>>>>>>>> Thanks ---- Bob >>>>>>>>>> >>>>>>>>>> Bob Bell >>>>>>>>>> Cisco Systems, Inc. >>>>>>>>>> 576 S. Brentwood Ln. >>>>>>>>>> Bountiful, UT 84010 >>>>>>>>>> 801-294-3034 (v) >>>>>>>>>> 801-294-3023 (f) >>>>>>>>>> 801-971-4200 (c) >>>>>>>>>> rtbell@cisco.com >>>>>>>>>> > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > Received: from host9-140-static.50-88-b.business.telecomitalia.it (host9-140-static.50-88-b.business.telecomitalia.it [88.50.140.9]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5G383W9067289 for ; Sun, 15 Jun 2008 20:08:08 -0700 (MST) (envelope-from raina-feriva@RebusHR.com) To: ietf-pkix-archive@imc.org Subject: You can find all meds here From: Richards Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Mon, 16 Jun 2008 05:08:06 +0200 Message-ID: User-Agent: Opera Mail/9.50 (Win32) Try the blue pill and experience its potency http://www.mikleola.com/ -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ Received: from HOST-91-123-212-104.ssh.gliwice.pl (HOST-91-123-212-104.ssh.gliwice.pl [91.123.212.104] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5FEbqgn023657 for ; Sun, 15 Jun 2008 07:37:55 -0700 (MST) (envelope-from afplozen_1972@INFOQ.COM) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_fzkWuHQTBNPrj5ecNqUIZB)" Message-id: <65635358-8EC2-8074-B881-BDA2A8350DA8@INFOQ.COM> From: Steinman To: ietf-pkix-archive@imc.org Subject: Most comprehensive and cheapest meds colletion Date: Sun, 15 Jun 2008 16:37:54 +0200 X-Mailer: Apple Mail (2.924) X-Antivirus: avast! (VPS 080615-0, 2008-06-15), Outbound message X-Antivirus-Status: Clean --Boundary_(ID_fzkWuHQTBNPrj5ecNqUIZB) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT We have the widest selection of online meds, at the lowest prices http://www.msoritue.com/ --Boundary_(ID_fzkWuHQTBNPrj5ecNqUIZB) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT We have the widest selection of online meds, at the lowest prices --Boundary_(ID_fzkWuHQTBNPrj5ecNqUIZB)-- Received: from cliente-27035.iberbanda.es (cliente-27035.iberbanda.es [83.230.169.153] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5EH8PGS058859 for ; Sat, 14 Jun 2008 10:08:34 -0700 (MST) (envelope-from retfflah1962@NEXTREAM.SK) To: ietf-pkix-archive@imc.org Subject: Complete list of medications available here From: Keel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Sat, 14 Jun 2008 19:08:30 +0200 Message-ID: User-Agent: Opera Mail/9.50 (Win32) The no.1 best selling online phar macy store in the world http://www.nacatell.com/ -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DNTZVp089195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 16:29:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DNTZ3S089194; Fri, 13 Jun 2008 16:29:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5DNTY8j089177 for ; Fri, 13 Jun 2008 16:29:34 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 7917 invoked from network); 13 Jun 2008 23:19:14 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Jun 2008 23:19:14 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Jun 2008 23:19:13 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 19:29:31 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjNlDMuDK17XIQcTyCW6IITeiItrwAGPdIg References: <48522C3F.4050103@cryptolog.com> From: "Santosh Chokhani" To: "Tom Gindin" , "Julien Stern" Cc: , "Max Pritikin (pritikin)" , "Bob Bell (rtbell)" , "Tim Polk" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, I am all for moving forward with draft-ietf-pkix-ta-mgmt-problem-statement-01. I am all for clarifying 5280. I even do not mind change as some would like if the implementers (relying party client developers) do not object. -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com]=20 Sent: Friday, June 13, 2008 4:29 PM To: Julien Stern; Santosh Chokhani Cc: ietf-pkix@imc.org; Max Pritikin (pritikin); Bob Bell (rtbell); Tim Polk Subject: Re: RFC 5280 Question Julien, Santosh: Actually, I think I have an idea why Max and Bob are using terms in a way that is at odds with many of the rest of us. The term "Trust=20 Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it wasn't=20 used in 2459 or X.509v3), a certificate issuer at the beginning of a chain=20 of trusted certificates. However, in=20 draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such a=20 certificate issuer or it may instead be "a public key and associated data=20 used by a relying party to validate a signature on a signed object" where=20 that object is not a public key certificate and cannot be validated using=20 a certification path. Max and Bob are clearly using a definition=20 consistent with that one, rather than with RFC 3280 or 5280. We should do something to clear up this confused usage. Either=20 "trust anchors" must be issuers and the "TA Management" draft needs to=20 reduce its scope or have its name changed (perhaps to "directly trusted=20 keys"), or else "trust anchors" can include EE certificates and the use in=20 3280 and 5280 should be called "anchor CA's" or something like that. Tom Gindin Julien Stern =20 Sent by: owner-ietf-pkix@mail.imc.org 06/13/2008 04:13 AM To "Bob Bell (rtbell)" cc Santosh Chokhani , "Max Pritikin (pritikin)"=20 , Tim Polk , ietf-pkix@imc.org Subject Re: RFC 5280 Question If I may (briefly) jump into the discussion. There seem to be a misunderstanding regarding "trusted certificates" and "trust store". Neither X.509 nor 5280 define the notion of trust store or trusted=20 certificate. This does not exist and there is no such thing as trusted=20 EE certificates or trusted CA certificates. You can have a "Trust Anchor" that is a DN and a public Key (see X.509=20 p.6 for the definition) which can be used to verify other certificates.=20 In practice, the DN and the public key, are commonly distributed as an=20 X.509 certificate, but that's to make things simple.=20 Extensions/constraints, etc are not supposed to apply (See validation=20 algorithm in X.509, p.50) Then, you have the notion of "Direct Trust", which is not clearly=20 expressed in X.509 or 5280, but which is natural in a PKI. Direct Trust means that you have verified the binding between a DN and a public key by out of band means. In other words, it means you know the=20 owner of the key. It this owner happens to be a CA, you are essentially in the "Trust=20 Anchor" case. Otherwise, you are also supposed to know (by out of band=20 means) what the public key can be used for. In your specific case, my reading of the standard is the following: 1) you insert a "certificate" in a "trust store" =3D> This means that = you=20 insert only the public key and the DN as trusted and as a CA (the rest=20 of the certificate is irrelevant). 2) You want to try to use standard validation mechanisms (and not direct trust). You take your EE cert, and since it is self signed and=20 self-issued, it will validate up to the trust anchor that you have=20 entered. 3) Be warned, however, that the owner of this public key will now be=20 able to issue as many certificates for other DNs that he wishes. Alternative option: you use "direct trust". 1) You insert your certificate in a "direct trust store". 2) When encountering the certificate, you do not perform the X.509=20 validation if is it "directly trusted" 3) Be warned that you can only revoke by hand. Now, I believe (experts, please correct me if I'm wrong), that you are=20 free to modify the X.509 or the 5280 validation algorithm as long as you are more restrictive. So, I assume you could define a "trust store with=20 constraints" that would be populated with "trust anchors with=20 constraints" in any way you see fit. Hope this helps. Regards, -- Julien Bob Bell (rtbell) wrote: > Santosh - >=20 > I would recommend that the definition be broadened slightly to indicate=20 that > regardless of whether basic constraints are present (as long as the CA bit > is false or non-existent), and that the keyCertSign bit is false. This,=20 at > least as I read the definitions, defines the cert as an end-entity cert. > That kind of a cert in the trust store is what is causing problems for me. >=20 > Bob >=20 >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org=20 >> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani >> Sent: Thursday, 12 June, 2008 18:21 >> To: Max Pritikin (pritikin) >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> >> Max, >> >> So, are you saying that you wanted to explore the implication=20 >> of a self-signed certificate that does not have basic=20 >> constraints extension in it and does not set keyCertSign bit=20 >> in the key usage? I ask because that is the certificate Bob sent me. >> >> Please provide a clear, concise and complete description of=20 >> your issues so that we have the same point of reference for=20 >> discussions. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Thursday, June 12, 2008 7:07 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> I think Bob's question touched on an important issue. The=20 >> inclusion of=20 >> self-signed or EE certificates into the certificate store. >> >> For an example one should experiment with how the various major web=20 >> browsers handle "trust this certificate" (sometimes called=20 >> "trust this=20 >> web page" etc). They all do it differently. >> >> - max >> >> On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: >> >>> Max, >>> >>> I do not understand from your posting what the specific concern or=20 >>> issue >>> you want to bring to the attention of PKIX. >>> >>> We have had lot of digressions on this topic. >>> >>> Please restate what your concerns are. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 11:11 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> I'm not sure what Bob's goals are, perhaps just to ask the question. >>> We don't work very closely together. >>> >>> This just struck a note with me because I've seen it raised as a >>> problem in other cases as well. >>> >>> - max >>> >>> On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I am just responding to inaccuracies in what you are saying. >>>> >>>> Can you and Bob tell me why you started this thread and=20 >> what you are >>>> seeking from the PKIX community? >>>> >>>> I for sure am clueless except for pointing out inaccuracies in your >>>> assertions and/or conclusions. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 6:51 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> Santosh, you've moved the conversation back to a discussion of item >>>> (3) in my comments below: out-of-scope population of the trust >>>> anchors. I think this is orthogonal to a discussion of dealing with >>>> trust-anchors that exactly match a single certificate being=20 >>>> validated. >>>> >>>> - max >>>> >>>> >>>> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I do not have any problem with successfully verifying=20 >> signature made >>>>> by >>>>> a trust anchor. >>>>> >>>>> As I said a day or two back in this chain, if the relying=20 >> party who >>>>> installs the certificate as a trust anchor and does not make >>>>> additional >>>>> checks of basic constraints, is susceptible to undetected=20 >> compromise >>>>> of >>>>> this end entity certificate spawning an entire PKI hierarchy. >>>>> >>>>> -----Original Message----- >>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>> Sent: Tuesday, June 10, 2008 6:17 PM >>>>> To: Santosh Chokhani >>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> We're into the realm of discussing _how_ one would modify=20 >>>>> Certificate >>>>> Path Validation to support EE certificates as a trust=20 >> anchor where=20 >>>>> my >>>>> intention was only to support the concept as a discussion point. >>>>> >>>>> Santosh, it isn't that the constraints/extensions are=20 >> ever applied=20 >>>>> to >>>>> the trust anchor credential itself. It is that they are=20 >> applied when >>>>> validating the chain. Take for example Name Constraints or Policy >>>>> Constraints or other Basic Constraints fields such as >>>>> pathLenConstraint which are all in the trust anchor=20 >> certificate and >>>>> then taken into account when validating a certificate=20 >> chain. If the >>>>> trust anchor certificate does not have keyCertSign set then=20 >>>>> logically >>>>> no 'chained' certificates would be valid; just like if the >>>>> pathLenConstraint was '1' but the chain being verified has a path >>>>> length of something greater. >>>>> >>>>> I think this question of EE cert vs CA cert as a trust anchor is >>>>> about >>>>> what should happen if the chain being validated consists=20 >> of only the >>>>> trust anchor. Independent of any questions concerning key usage, >>>>> constraints or anything else. >>>>> >>>>> - max >>>>> >>>>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> The text you cite does not apply to trust anchor.=20 >> Please see X.509 >>>>>> and >>>>>> RFC 5280 path validation text. Nothing needs to be=20 >> verified from a >>>>>> trust anchor. >>>>>> >>>>>> -----Original Message----- >>>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>>>> To: Santosh Chokhani >>>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>>> Subject: Re: RFC 5280 Question >>>>>> >>>>>> >>>>>> Santosh, >>>>>> >>>>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>>>> The cA boolean indicates whether the certified public key may be >>>>>>> used >>>>>>> to verify certificate signatures. If the cA boolean is not >>>>>>> asserted, >>>>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>>>> asserted. If the basic constraints extension is not=20 >> present in a >>>>>>> version 3 certificate, or the extension is present but the cA >>>>>>> boolean >>>>>>> is not asserted, then the certified public key MUST NOT=20 >> be used to >>>>>>> verify certificate signatures. >>>>>> An EE certificate being in the trust store would not cause=20 >>>>>> confusion >>>>>> about this. >>>>>> >>>>>> - max >>>>>> >>>>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>>>> >>>>>>> Max, >>>>>>> >>>>>>> I do not agree with your point on item 2. Once a=20 >> certificate is a >>>>>>> trust >>>>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>>>> being a >>>>>>> issuer. >>>>>>> >>>>>>> Furthermore, path length constraint if present in the=20 >> self-signed >>>>>>> certificate can be ignored by relying parties. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: owner-ietf-pkix@mail.imc.org >>>>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>>>> ] >>>>>>> On Behalf Of max pritikin >>>>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>>>> To: Tim Polk >>>>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>>>> Subject: Re: RFC 5280 Question >>>>>>> >>>>>>> >>>>>>> >>>>>>> A few comments on this thread: >>>>>>> >>>>>>> 1) Any entry in the trust anchor store would seem to be=20 >> "directly >>>>>>> trusted". If so an additional flag isn't needed so much as a >>>>>>> statement >>>>>>> about how path validation proceeds if, during path discovery, it >>>>>>> turns >>>>>>> out the certificate being validated is already directly trusted. >>>>>>> >>>>>>> 2) Inclusion into the trust anchor store doesn't imply that a=20 >>>>>>> cert >>>>>>> is >>>>>>> trusted to issue certificates -- that is directly=20 >> controlled by=20 >>>>>>> the >>>>>>> values within the certificate (chain). >>>>>>> >>>>>>> 3) The out-of-band mechanism is out of scope for=20 >> 5280/3280 but has >>>>>>> been the subject of recent BoF work (and more?). It=20 >> would nice if >>>>>>> that >>>>>>> work also addressed this question. >>>>>>> >>>>>>> Issues related to this come up on a regular basis. Look at the >>>>>>> various >>>>>>> ways browser deal with caching EE certificates to=20 >> "trust this site >>>>>>> always" etc. I think Bob has raised a good point. >>>>>>> >>>>>>> - max >>>>>>> >>>>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>>>> >>>>>>>> Bob, >>>>>>>> >>>>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>>>> Wen- >>>>>>>> Chen Wang have already provided a lot of good feedback. I=20 >>>>>>>> decided >>>>>>>> to respond to the original message because I would like to go=20 >>>>>>>> back >>>>>>>> to the perceived requirement.] >>>>>>>> >>>>>>>> It sounds like you want to construct a list of=20 >> directly trusted=20 >>>>>>>> EE >>>>>>>> certificates, but are trying to satisfy this=20 >> requirement using=20 >>>>>>>> the >>>>>>>> application's trust anchor store. There is nothing inherently >>>>>>>> wrong >>>>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>>>> trusting >>>>>>>> an EE certificate), but you really need a different - and far >>>>>>>> simpler - mechanism. The trust anchor store is=20 >> implicitly linked >>>>>>>> to >>>>>>>> path discovery and validation, which are not relevant here=20 >>>>>>>> since a >>>>>>>> directly trusted certificate cannot be validated. With a=20 >>>>>>>> directly >>>>>>>> trusted certificate, there is also no mechanism to validate=20 >>>>>>>> status >>>>>>>> information. >>>>>>>> >>>>>>>> To further complicate matters, storing the certificate=20 >> you wish=20 >>>>>>>> to >>>>>>>> directly trust in the trust anchor store implies that it is >>>>>>>> trusted >>>>>>>> to issue certificates as well. The path validation inputs >>>>>>>> specified >>>>>>>> in 6.1.1 (d) consider only four aspects of a trust=20 >> anchor (name, >>>>>>>> public key algorithm, public key, and parameters if=20 >> needed). The >>>>>>>> assumption is that the trust anchor's authority to issue >>>>>>>> certificates was verified based on an out-of-band=20 >> trust mechanism >>>>>>>> (which is out of scope for 5280). This makes sense=20 >> since a trust >>>>>>>> anchor might have distributed a v1 certificate (which does not >>>>>>>> include extensions). >>>>>>>> >>>>>>>> As others have noted, direct trust also implies an out-of-band >>>>>>>> trust >>>>>>>> mechanism. I received the EE certificate from a trusted source >>>>>>>> so I >>>>>>>> can trust the binding between the subject name and the key;=20 >>>>>>>> issuer >>>>>>>> name and the signature are irrelevant. If the certificate=20 >>>>>>>> status >>>>>>>> matters, I am also depending on an out-of-band mechanism to=20 >>>>>>>> inform >>>>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>>>> local storage provide the basis for security in this system... >>>>>>>> >>>>>>>> Trying to combine these two mechanisms using a single=20 >> certificate >>>>>>>> store probably requires an additional flag on every entry to >>>>>>>> differentiate between directly trusted certificates and trust >>>>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Tim Polk >>>>>>>> >>>>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>>>> >>>>>>>>> Folks- >>>>>>>>> >>>>>>>>> I am hoping someone can give me the answer to this. Does RFC=20 >>>>>>>>> 5280 >>>>>>>>> adress the case where an end-entity certificate (not=20 >> a CA cert) >>>>>>>>> is >>>>>>>>> installed in the trust anchor list by the user accepting the >>>>>>>>> presented cert as authoritative and then the cert is=20 >>>>>>>>> subsequently >>>>>>>>> presented (in a later access to the site). There should be no >>>>>>>>> path >>>>>>>>> search, since the presented cert is in the trust=20 >> anchor list.=20 >>>>>>>>> So, >>>>>>>>> where is it defined to accept the end-entity cert? >>>>>>>>> >>>>>>>>> Thanks ---- Bob >>>>>>>>> >>>>>>>>> Bob Bell >>>>>>>>> Cisco Systems, Inc. >>>>>>>>> 576 S. Brentwood Ln. >>>>>>>>> Bountiful, UT 84010 >>>>>>>>> 801-294-3034 (v) >>>>>>>>> 801-294-3023 (f) >>>>>>>>> 801-971-4200 (c) >>>>>>>>> rtbell@cisco.com >>>>>>>>> >> ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ Received: from 206-18-173-3.attens.net (206-18-173-3.attens.net [206.18.173.3] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5DMGiTr075954; Fri, 13 Jun 2008 15:16:46 -0700 (MST) (envelope-from nshigher@mailtvc.com) Received: from CONNECTUPS ([68.5.139.94]:22936 "HELO CONNECTUPS" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 3ad12cemailtvc.com with ESMTP id 8013653278FF43 (ORCPT ); Fri, 13 Jun 2008 17:52:25 -0400 Message-ID: <001901c8cd7e$3d3f2160$000d0dec@CONNECTUPS> From: Jason To: ietf-pgp-mime@imc.org Subject: in urge Date: Fri, 13 Jun 2008 17:52:25 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C8CD7E.3D3F2160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1081 X-Mimeole: Produced By Microsoft MimeOLE V6.00.3790.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C8CD7E.3D3F2160 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable particular medium which constitutes the appeal of a sculpture, Presently we can access and deliver information millions of miles more glob= al market, companies are now specializing in specific ------=_NextPart_000_0016_01C8CD7E.3D3F2160 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
hope to discover "what is it in matter that enables it to have

C A 0N A D/3AN     P 0 7H A RM A 5CY

V/A \G _RA - $1.42
C 8/ A L / S - $2.20
S8 O M A - $0.65
L E6 V / T R A - $3.60
FEMALE V -\ A :\ G / R '/A - $1.58
U 8 L T 3R A M - $1.31
183 Items on Sale Today.

Convenience and efficiency complement each other, and together
------=_NextPart_000_0016_01C8CD7E.3D3F2160-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DKTav0053643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 13:29:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DKTaP3053642; Fri, 13 Jun 2008 13:29:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DKTYKI053632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 13 Jun 2008 13:29:35 -0700 (MST) (envelope-from tgindin@us.ibm.com) X-VirusChecked: Checked X-Env-Sender: tgindin@us.ibm.com X-Msg-Ref: server-13.tower-87.messagelabs.com!1213388971!44596343!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 25650 invoked from network); 13 Jun 2008 20:29:32 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-13.tower-87.messagelabs.com with AES256-SHA encrypted SMTP; 13 Jun 2008 20:29:32 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id m5DKUWkp029899; Fri, 13 Jun 2008 16:30:32 -0400 In-Reply-To: <48522C3F.4050103@cryptolog.com> To: Julien Stern , Santosh Chokhani Cc: ietf-pkix@imc.org, "Max Pritikin (pritikin)" , "Bob Bell (rtbell)" , Tim Polk MIME-Version: 1.0 Subject: Re: RFC 5280 Question X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Tom Gindin Message-ID: Date: Fri, 13 Jun 2008 16:29:25 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1|February 07, 2008) at 06/13/2008 04:32:23 PM, Serialize complete at 06/13/2008 04:32:23 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Julien, Santosh: Actually, I think I have an idea why Max and Bob are using terms in a way that is at odds with many of the rest of us. The term "Trust Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it wasn't used in 2459 or X.509v3), a certificate issuer at the beginning of a chain of trusted certificates. However, in draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such a certificate issuer or it may instead be "a public key and associated data used by a relying party to validate a signature on a signed object" where that object is not a public key certificate and cannot be validated using a certification path. Max and Bob are clearly using a definition consistent with that one, rather than with RFC 3280 or 5280. We should do something to clear up this confused usage. Either "trust anchors" must be issuers and the "TA Management" draft needs to reduce its scope or have its name changed (perhaps to "directly trusted keys"), or else "trust anchors" can include EE certificates and the use in 3280 and 5280 should be called "anchor CA's" or something like that. Tom Gindin Julien Stern Sent by: owner-ietf-pkix@mail.imc.org 06/13/2008 04:13 AM To "Bob Bell (rtbell)" cc Santosh Chokhani , "Max Pritikin (pritikin)" , Tim Polk , ietf-pkix@imc.org Subject Re: RFC 5280 Question If I may (briefly) jump into the discussion. There seem to be a misunderstanding regarding "trusted certificates" and "trust store". Neither X.509 nor 5280 define the notion of trust store or trusted certificate. This does not exist and there is no such thing as trusted EE certificates or trusted CA certificates. You can have a "Trust Anchor" that is a DN and a public Key (see X.509 p.6 for the definition) which can be used to verify other certificates. In practice, the DN and the public key, are commonly distributed as an X.509 certificate, but that's to make things simple. Extensions/constraints, etc are not supposed to apply (See validation algorithm in X.509, p.50) Then, you have the notion of "Direct Trust", which is not clearly expressed in X.509 or 5280, but which is natural in a PKI. Direct Trust means that you have verified the binding between a DN and a public key by out of band means. In other words, it means you know the owner of the key. It this owner happens to be a CA, you are essentially in the "Trust Anchor" case. Otherwise, you are also supposed to know (by out of band means) what the public key can be used for. In your specific case, my reading of the standard is the following: 1) you insert a "certificate" in a "trust store" => This means that you insert only the public key and the DN as trusted and as a CA (the rest of the certificate is irrelevant). 2) You want to try to use standard validation mechanisms (and not direct trust). You take your EE cert, and since it is self signed and self-issued, it will validate up to the trust anchor that you have entered. 3) Be warned, however, that the owner of this public key will now be able to issue as many certificates for other DNs that he wishes. Alternative option: you use "direct trust". 1) You insert your certificate in a "direct trust store". 2) When encountering the certificate, you do not perform the X.509 validation if is it "directly trusted" 3) Be warned that you can only revoke by hand. Now, I believe (experts, please correct me if I'm wrong), that you are free to modify the X.509 or the 5280 validation algorithm as long as you are more restrictive. So, I assume you could define a "trust store with constraints" that would be populated with "trust anchors with constraints" in any way you see fit. Hope this helps. Regards, -- Julien Bob Bell (rtbell) wrote: > Santosh - > > I would recommend that the definition be broadened slightly to indicate that > regardless of whether basic constraints are present (as long as the CA bit > is false or non-existent), and that the keyCertSign bit is false. This, at > least as I read the definitions, defines the cert as an end-entity cert. > That kind of a cert in the trust store is what is causing problems for me. > > Bob > >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org >> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani >> Sent: Thursday, 12 June, 2008 18:21 >> To: Max Pritikin (pritikin) >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> >> Max, >> >> So, are you saying that you wanted to explore the implication >> of a self-signed certificate that does not have basic >> constraints extension in it and does not set keyCertSign bit >> in the key usage? I ask because that is the certificate Bob sent me. >> >> Please provide a clear, concise and complete description of >> your issues so that we have the same point of reference for >> discussions. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Thursday, June 12, 2008 7:07 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> I think Bob's question touched on an important issue. The >> inclusion of >> self-signed or EE certificates into the certificate store. >> >> For an example one should experiment with how the various major web >> browsers handle "trust this certificate" (sometimes called >> "trust this >> web page" etc). They all do it differently. >> >> - max >> >> On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: >> >>> Max, >>> >>> I do not understand from your posting what the specific concern or >>> issue >>> you want to bring to the attention of PKIX. >>> >>> We have had lot of digressions on this topic. >>> >>> Please restate what your concerns are. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 11:11 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> I'm not sure what Bob's goals are, perhaps just to ask the question. >>> We don't work very closely together. >>> >>> This just struck a note with me because I've seen it raised as a >>> problem in other cases as well. >>> >>> - max >>> >>> On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I am just responding to inaccuracies in what you are saying. >>>> >>>> Can you and Bob tell me why you started this thread and >> what you are >>>> seeking from the PKIX community? >>>> >>>> I for sure am clueless except for pointing out inaccuracies in your >>>> assertions and/or conclusions. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 6:51 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> Santosh, you've moved the conversation back to a discussion of item >>>> (3) in my comments below: out-of-scope population of the trust >>>> anchors. I think this is orthogonal to a discussion of dealing with >>>> trust-anchors that exactly match a single certificate being >>>> validated. >>>> >>>> - max >>>> >>>> >>>> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I do not have any problem with successfully verifying >> signature made >>>>> by >>>>> a trust anchor. >>>>> >>>>> As I said a day or two back in this chain, if the relying >> party who >>>>> installs the certificate as a trust anchor and does not make >>>>> additional >>>>> checks of basic constraints, is susceptible to undetected >> compromise >>>>> of >>>>> this end entity certificate spawning an entire PKI hierarchy. >>>>> >>>>> -----Original Message----- >>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>> Sent: Tuesday, June 10, 2008 6:17 PM >>>>> To: Santosh Chokhani >>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> We're into the realm of discussing _how_ one would modify >>>>> Certificate >>>>> Path Validation to support EE certificates as a trust >> anchor where >>>>> my >>>>> intention was only to support the concept as a discussion point. >>>>> >>>>> Santosh, it isn't that the constraints/extensions are >> ever applied >>>>> to >>>>> the trust anchor credential itself. It is that they are >> applied when >>>>> validating the chain. Take for example Name Constraints or Policy >>>>> Constraints or other Basic Constraints fields such as >>>>> pathLenConstraint which are all in the trust anchor >> certificate and >>>>> then taken into account when validating a certificate >> chain. If the >>>>> trust anchor certificate does not have keyCertSign set then >>>>> logically >>>>> no 'chained' certificates would be valid; just like if the >>>>> pathLenConstraint was '1' but the chain being verified has a path >>>>> length of something greater. >>>>> >>>>> I think this question of EE cert vs CA cert as a trust anchor is >>>>> about >>>>> what should happen if the chain being validated consists >> of only the >>>>> trust anchor. Independent of any questions concerning key usage, >>>>> constraints or anything else. >>>>> >>>>> - max >>>>> >>>>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> The text you cite does not apply to trust anchor. >> Please see X.509 >>>>>> and >>>>>> RFC 5280 path validation text. Nothing needs to be >> verified from a >>>>>> trust anchor. >>>>>> >>>>>> -----Original Message----- >>>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>>>> To: Santosh Chokhani >>>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>>> Subject: Re: RFC 5280 Question >>>>>> >>>>>> >>>>>> Santosh, >>>>>> >>>>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>>>> The cA boolean indicates whether the certified public key may be >>>>>>> used >>>>>>> to verify certificate signatures. If the cA boolean is not >>>>>>> asserted, >>>>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>>>> asserted. If the basic constraints extension is not >> present in a >>>>>>> version 3 certificate, or the extension is present but the cA >>>>>>> boolean >>>>>>> is not asserted, then the certified public key MUST NOT >> be used to >>>>>>> verify certificate signatures. >>>>>> An EE certificate being in the trust store would not cause >>>>>> confusion >>>>>> about this. >>>>>> >>>>>> - max >>>>>> >>>>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>>>> >>>>>>> Max, >>>>>>> >>>>>>> I do not agree with your point on item 2. Once a >> certificate is a >>>>>>> trust >>>>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>>>> being a >>>>>>> issuer. >>>>>>> >>>>>>> Furthermore, path length constraint if present in the >> self-signed >>>>>>> certificate can be ignored by relying parties. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: owner-ietf-pkix@mail.imc.org >>>>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>>>> ] >>>>>>> On Behalf Of max pritikin >>>>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>>>> To: Tim Polk >>>>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>>>> Subject: Re: RFC 5280 Question >>>>>>> >>>>>>> >>>>>>> >>>>>>> A few comments on this thread: >>>>>>> >>>>>>> 1) Any entry in the trust anchor store would seem to be >> "directly >>>>>>> trusted". If so an additional flag isn't needed so much as a >>>>>>> statement >>>>>>> about how path validation proceeds if, during path discovery, it >>>>>>> turns >>>>>>> out the certificate being validated is already directly trusted. >>>>>>> >>>>>>> 2) Inclusion into the trust anchor store doesn't imply that a >>>>>>> cert >>>>>>> is >>>>>>> trusted to issue certificates -- that is directly >> controlled by >>>>>>> the >>>>>>> values within the certificate (chain). >>>>>>> >>>>>>> 3) The out-of-band mechanism is out of scope for >> 5280/3280 but has >>>>>>> been the subject of recent BoF work (and more?). It >> would nice if >>>>>>> that >>>>>>> work also addressed this question. >>>>>>> >>>>>>> Issues related to this come up on a regular basis. Look at the >>>>>>> various >>>>>>> ways browser deal with caching EE certificates to >> "trust this site >>>>>>> always" etc. I think Bob has raised a good point. >>>>>>> >>>>>>> - max >>>>>>> >>>>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>>>> >>>>>>>> Bob, >>>>>>>> >>>>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>>>> Wen- >>>>>>>> Chen Wang have already provided a lot of good feedback. I >>>>>>>> decided >>>>>>>> to respond to the original message because I would like to go >>>>>>>> back >>>>>>>> to the perceived requirement.] >>>>>>>> >>>>>>>> It sounds like you want to construct a list of >> directly trusted >>>>>>>> EE >>>>>>>> certificates, but are trying to satisfy this >> requirement using >>>>>>>> the >>>>>>>> application's trust anchor store. There is nothing inherently >>>>>>>> wrong >>>>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>>>> trusting >>>>>>>> an EE certificate), but you really need a different - and far >>>>>>>> simpler - mechanism. The trust anchor store is >> implicitly linked >>>>>>>> to >>>>>>>> path discovery and validation, which are not relevant here >>>>>>>> since a >>>>>>>> directly trusted certificate cannot be validated. With a >>>>>>>> directly >>>>>>>> trusted certificate, there is also no mechanism to validate >>>>>>>> status >>>>>>>> information. >>>>>>>> >>>>>>>> To further complicate matters, storing the certificate >> you wish >>>>>>>> to >>>>>>>> directly trust in the trust anchor store implies that it is >>>>>>>> trusted >>>>>>>> to issue certificates as well. The path validation inputs >>>>>>>> specified >>>>>>>> in 6.1.1 (d) consider only four aspects of a trust >> anchor (name, >>>>>>>> public key algorithm, public key, and parameters if >> needed). The >>>>>>>> assumption is that the trust anchor's authority to issue >>>>>>>> certificates was verified based on an out-of-band >> trust mechanism >>>>>>>> (which is out of scope for 5280). This makes sense >> since a trust >>>>>>>> anchor might have distributed a v1 certificate (which does not >>>>>>>> include extensions). >>>>>>>> >>>>>>>> As others have noted, direct trust also implies an out-of-band >>>>>>>> trust >>>>>>>> mechanism. I received the EE certificate from a trusted source >>>>>>>> so I >>>>>>>> can trust the binding between the subject name and the key; >>>>>>>> issuer >>>>>>>> name and the signature are irrelevant. If the certificate >>>>>>>> status >>>>>>>> matters, I am also depending on an out-of-band mechanism to >>>>>>>> inform >>>>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>>>> local storage provide the basis for security in this system... >>>>>>>> >>>>>>>> Trying to combine these two mechanisms using a single >> certificate >>>>>>>> store probably requires an additional flag on every entry to >>>>>>>> differentiate between directly trusted certificates and trust >>>>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Tim Polk >>>>>>>> >>>>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>>>> >>>>>>>>> Folks- >>>>>>>>> >>>>>>>>> I am hoping someone can give me the answer to this. Does RFC >>>>>>>>> 5280 >>>>>>>>> adress the case where an end-entity certificate (not >> a CA cert) >>>>>>>>> is >>>>>>>>> installed in the trust anchor list by the user accepting the >>>>>>>>> presented cert as authoritative and then the cert is >>>>>>>>> subsequently >>>>>>>>> presented (in a later access to the site). There should be no >>>>>>>>> path >>>>>>>>> search, since the presented cert is in the trust >> anchor list. >>>>>>>>> So, >>>>>>>>> where is it defined to accept the end-entity cert? >>>>>>>>> >>>>>>>>> Thanks ---- Bob >>>>>>>>> >>>>>>>>> Bob Bell >>>>>>>>> Cisco Systems, Inc. >>>>>>>>> 576 S. Brentwood Ln. >>>>>>>>> Bountiful, UT 84010 >>>>>>>>> 801-294-3034 (v) >>>>>>>>> 801-294-3023 (f) >>>>>>>>> 801-971-4200 (c) >>>>>>>>> rtbell@cisco.com >>>>>>>>> >> ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DIJDTd031495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 11:19:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DIJDOr031494; Fri, 13 Jun 2008 11:19:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from helios.bolet.org (helios.bolet.org [88.191.25.203]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DIJAwG031487 for ; Fri, 13 Jun 2008 11:19:11 -0700 (MST) (envelope-from pornin@helios.bolet.org) Received: by helios.bolet.org (Postfix, from userid 1000) id 24067D986C7; Fri, 13 Jun 2008 20:19:10 +0200 (CEST) Date: Fri, 13 Jun 2008 20:19:10 +0200 From: Thomas Pornin To: ietf-pkix@imc.org Subject: Re: RFC 5280 Question Message-ID: <20080613181910.GA17653@localhost.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Jun 13, 2008 at 12:27:18PM -0400, Kemp, David P. wrote: > The standard defines a trust anchor to be the four items of information > needed to validate the first certificate in a chain. Actually, RFC 5280 does not really define what a trust anchor is. It defines the "trust anchor information", which is the set of four items which is input into the path validation algorithm. The wording of RFC 5280 seems to imply that these items are obtained from some entity called a "trust anchor", which is more alluded to than actually explained. At the end of 6.2, one may find the following two paragraphs: << An implementation MAY augment the algorithm presented in Section 6.1 to further limit the set of valid certification paths that begin with a particular trust anchor. For example, an implementation MAY modify the algorithm to apply a path length constraint to a specific trust anchor during the initialization phase, or the application MAY require the presence of a particular alternative name form in the target certificate, or the application MAY impose requirements on application-specific extensions. Thus, the path validation algorithm presented in Section 6.1 defines the minimum conditions for a path to be considered valid. Where a CA distributes self-signed certificates to specify trust anchor information, certificate extensions can be used to specify recommended inputs to path validation. For example, a policy constraints extension could be included in the self-signed certificate to indicate that paths beginning with this trust anchor should be trusted only for the specified policies. Similarly, a name constraints extension could be included to indicate that paths beginning with this trust anchor should be trusted only for the specified name spaces. The path validation algorithm presented in Section 6.1 does not assume that trust anchor information is provided in self-signed certificates and does not specify processing rules for additional information included in such certificates. Implementations that use self-signed certificates to specify trust anchor information are free to process or ignore such information. >> This somehow settles it. The trust anchor information _may_ be transfered under the guise of self-signed certificates but this is mostly out of scope of RFC 5280. However, RFC 5280 does not _mandate_ that extra information provided along the trust anchor is to be ignored. It explicitely states that implementations are free to enforce additional restrictions on certificate paths. RFC 5280 even explains that nothing prevents such information to be serialized with the trust anchor information as what usually happens to be certificate extensions. Therefore, if an application wishes to use an "augmented trust anchor" which is a set of trust anchor information together with some additional usage restrictions (e.g. maximum path length, explicit policies or name constraints) to be applied when the said trust anchor is used in path validation, then it is free to do so. Moreover, if the said application wishes to receive and/or store this augmented trust anchor as a "self-signed certificate" with the additional restrictions using the format of certificate extensions, then by all means it can, and RFC 5280 even explicitely states that it does not mind. In other words, such an implementation can still claim to be conforming to RFC 5280. Hence there is little problem here. There is a problem, however, in _other_ standard documents (not RFC 5280), such as those presenting signature validation policies. Such policies may include trust anchors, encoded as self-signed certificates. And there is no document anywhere which really defines how you should transform a self-signed certificate into a proper set of inputs for the validation algorithm. It is _customary_ to use the "subjectDN" as trust anchor name, and the "subjectPublicKeyInfo" as public key information (with key type and key parameters, when applicable). Beyond conforming to the Tradition, it is also a quite natural choice. But there is nothing which explicitely defines such usage. And when it comes to how certificate extensions present in that "self-signed certificate" must be interpreted and used, then Tradition is somewhat at a loss, and differing interpretations exist. Theoretically, CA should distribute their public keys along with a "Certificate Policy Statement" which defines (in human language) what they do and thus, indrectly, how paths originating from them as trust anchors should be validated. Human languages are fine for humans but computers are known to be quite thick and literal and often require a more easily and unambiguously decodeable representation of such information. And there is no standard on that. Even worse, there is a widespread practice of using self-signed certificates which implementors often erroneously assume to be sanctioned by RFC 5280 -- and they do not all do so in the same way, of course. Various disasters ensue. Hence the problem with self-signed certificates at trust anchors is NOT that RFC 5280 forbids implementations to use information from the self-signed certificate. To the contrary, RFC 5280 explicitely allows it. The problem is that there is a need for a standard definition of how this extended information may be used; and RFC 5280 explicitely denies having anything to say on that matter. Note that I do NOT claim that RFC 5280 should include such a definition; I merely point out that applications which use path validation often have a need which is often assumed to be fulfilled by RFC 5280, whereas in fact it is not. --Thomas Pornin Received: from torez.tsua.net (torez.tsua.net [212.40.35.214]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5DI2uCj027959 for ; Fri, 13 Jun 2008 11:02:57 -0700 (MST) (envelope-from ietf-mmms-request@imc.org) Date: Fri, 13 Jun 2008 11:02:56 -0700 (MST) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20080613111936.17272.qmail@torez.tsua.net> To: Subject: ietf-pkix-archive@imc.org Save an Additional 73% on Summer. Ends June 11th. From: Online Pharmacy MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Top Offers for Mens Health Medications. Fast Worldwide Shipping! Simply Drugstore - Lowest Prices on Pills !

Women's Health | Men's Health

© 2001-2008 Pfizer Inc. "Click Here!" Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DGRL57007919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 09:27:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DGRLkA007918; Fri, 13 Jun 2008 09:27:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DGRJmC007912 for ; Fri, 13 Jun 2008 09:27:20 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id m5DGRJjB028277 for ; Fri, 13 Jun 2008 12:27:19 -0400 (EDT) X-AuditID: 90333308-000013cc00000188-48-48529fe72121 Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 12:27:18 -0400 Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 12:27:18 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 12:27:18 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjNUnn99vETX4vJSAmOfi3qJ34J7AABsZiAAAW+/LA= References: From: "Kemp, David P." To: X-OriginalArrivalTime: 13 Jun 2008 16:27:18.0958 (UTC) FILETIME=[596164E0:01C8CD72] X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The standard defines a trust anchor to be the four items of information needed to validate the first certificate in a chain. The fact that those items can be extracted from a certificate, and for convenience are often transmitted in the form of a self-signed certificate, confuses users into believing that a self-signed certificate is itself a trust anchor. PKIX could have (and should have) eliminated that confusion by defining an unsigned trust anchor data structure, but it's a bit late for that now. Confusion is the natural and expected result of using the same data structure to represent two semantically different objects. Dave -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Friday, June 13, 2008 9:29 AM To: pgut001; pritikin@cisco.com Cc: ietf-pkix@imc.org; rtbell@cisco.com; tim.polk@nist.gov Subject: RE: RFC 5280 Question We agree on the standard's required behavior, which has been the focus of my posts in this thread. -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Friday, June 13, 2008 8:39 AM To: pgut001@cs.auckland.ac.nz; pritikin@cisco.com; Santosh Chokhani Cc: ietf-pkix@imc.org; rtbell@cisco.com; tim.polk@nist.gov Subject: RE: RFC 5280 Question SChokhani@cygnacom.com writes: >Are you saying that the standard requires you to check and enforce >constraints in a trust anchor which is a self-signed X.509 certificate? No, the standard requires that you not check trust anchors. This is completely contrary to what users (and implementors) seem to expect. Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DFjcag000379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 08:45:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DFjcnU000378; Fri, 13 Jun 2008 08:45:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DFjbE9000362 for ; Fri, 13 Jun 2008 08:45:38 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1K7BT6-0001yt-5R for ietf-pkix@imc.org; Fri, 13 Jun 2008 11:45:36 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 13 Jun 2008 11:45:52 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: Re: RFC 5280 question Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, Yes, I too have been disappointed that the X.509 path validation algorithm says to not use constraints from the TA. I brought this point up on the list a few years ago, because I felt that this was especially bad in the case of name constraints. I agree that such behavior is contrary to user expectations. However, there is a relatively simple way around this that is consistent with the standards. One can extract the contents of a self-signed cert that has been provided as a TA, and issue a new cert under a TA managed locally. This could be done with minimal user effort for most folks, and advanced users could be provided with a menu that allowed more direct control over the process. Any extensions contained in this new cert (which is no longer a TA), will be used to control path validation, as specified by the X.509 and PKIX standards. I have always preferred this model for dealing with TA material, as it also allows an RP to impose constraints (via extensions) on TA material provided by an outside source, even if the source did not put such constraints into the self-signed cert it offered. Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DFCBJH093385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 08:12:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DFCBHS093384; Fri, 13 Jun 2008 08:12:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DFCAUc093378 for ; Fri, 13 Jun 2008 08:12:11 -0700 (MST) (envelope-from mike-list@pobox.com) Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 0994D3830 for ; Fri, 13 Jun 2008 11:12:10 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id AB7DC382F for ; Fri, 13 Jun 2008 11:12:07 -0400 (EDT) Message-ID: <48528E43.4060103@pobox.com> Date: Fri, 13 Jun 2008 08:12:03 -0700 From: Mike User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: RFC 5280 Question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 181BCDB8-395B-11DD-A5E5-F9737025C2AA-38729857!a-sasl-fastnet.pobox.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Fortunately RFC 5280 says in a couple places: Some communities will need to supplement, or possibly replace, this profile in order to meet the requirements of specialized application domains or environments with additional authorization, assurance, or operational requirements. So if you want to check your trust anchors, it seems that you can -- just claim that you are part of a community. If a trust anchor certificate has extensions, what justification is there for just ignoring them? Somebody put them there, and not just for grins. Mike > We agree on the standard's required behavior, which has been the focus > of my posts in this thread. > > -----Original Message----- > From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] > Sent: Friday, June 13, 2008 8:39 AM > To: pgut001@cs.auckland.ac.nz; pritikin@cisco.com; Santosh Chokhani > Cc: ietf-pkix@imc.org; rtbell@cisco.com; tim.polk@nist.gov > Subject: RE: RFC 5280 Question > > SChokhani@cygnacom.com writes: > >> Are you saying that the standard requires you to check and enforce >> constraints in a trust anchor which is a self-signed X.509 certificate? > > No, the standard requires that you not check trust anchors. This is > completely contrary to what users (and implementors) seem to expect. > > Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DE2lxb079281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 07:02:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DE2lCN079280; Fri, 13 Jun 2008 07:02:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DE2kwA079265 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 13 Jun 2008 07:02:46 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,638,1204531200"; d="p7s'?scan'208";a="56697871" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 13 Jun 2008 07:02:44 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5DE2iIe022558; Fri, 13 Jun 2008 07:02:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5DE2i5p005962; Fri, 13 Jun 2008 14:02:44 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 07:02:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 07:02:39 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000D_01C8CD2B.D95540F0" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjM4R2FGr+XJh/aR3icrE8p2IycgQACdOqgAAQzQhAAEVhCQAAHF8BA References: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , "Max Pritikin (pritikin)" Cc: "Tim Polk" , X-OriginalArrivalTime: 13 Jun 2008 14:02:44.0349 (UTC) FILETIME=[26E91AD0:01C8CD5E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19706; t=1213365764; x=1214229764; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=mzHWFQEhcVTROb58tGxYSv7g36wK04d5ltaveasniQ4=; b=HvPLmHfEejf3OeA+S/M9WnMPtGbjwGv3kjk812hiT+U7DbvGq/jCrsx6/w 58V6EKKZQWwmoQa0HZoGJuB4gyfo1B1MlkpdrLIYPykLd+9zc3S6mHyv2BiX w43DaSZcj6; Authentication-Results: sj-dkim-4; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C8CD2B.D95540F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - The only thing I was referring to in verifying the basic constraints was to limit the use of the certificate if the basic constraint CA bit was false and/or the keyCertSign bit was false. In these cases, you cannot use the certificate to validate another certificate. It does not prevent you from validating itself. On the other hand, it was never my intent to cause this much controversy. My original intent was to try to determine which of the interpretations that I and another engineer had concerning 5280 was correct or if they both were flawed. I think I got my answer to that question. I appreciate all of the comments that others have made. Bob > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani > Sent: Friday, 13 June, 2008 04:37 > To: Bob Bell (rtbell); Max Pritikin (pritikin) > Cc: Tim Polk; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Bob, > > If basic constraints is absent or false, a certificate is not > a CA certificate. > > The problem comes in with trust anchors. Any requirements to > process trust anchors is a change in the standard and raises > backward compatibility issues. > > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Thursday, June 12, 2008 10:21 PM > To: Santosh Chokhani; Max Pritikin (pritikin) > Cc: Tim Polk; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Santosh - > > I would recommend that the definition be broadened slightly > to indicate that regardless of whether basic constraints are > present (as long as the CA bit is false or non-existent), and > that the keyCertSign bit is false. This, at least as I read > the definitions, defines the cert as an end-entity cert. > That kind of a cert in the trust store is what is causing > problems for me. > > Bob > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani > > Sent: Thursday, 12 June, 2008 18:21 > > To: Max Pritikin (pritikin) > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > > > > > > Max, > > > > So, are you saying that you wanted to explore the implication of a > > self-signed certificate that does not have basic > constraints extension > > in it and does not set keyCertSign bit in the key usage? I ask > > because that is the certificate Bob sent me. > > > > Please provide a clear, concise and complete description of your > > issues so that we have the same point of reference for discussions. > > > > -----Original Message----- > > From: max pritikin [mailto:pritikin@cisco.com] > > Sent: Thursday, June 12, 2008 7:07 PM > > To: Santosh Chokhani > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > Subject: Re: RFC 5280 Question > > > > > > I think Bob's question touched on an important issue. The > inclusion of > > self-signed or EE certificates into the certificate store. > > > > For an example one should experiment with how the various major web > > browsers handle "trust this certificate" (sometimes called > "trust this > > web page" etc). They all do it differently. > > > > - max > > > > On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: > > > > > > > > Max, > > > > > > I do not understand from your posting what the specific > concern or > > > issue you want to bring to the attention of PKIX. > > > > > > We have had lot of digressions on this topic. > > > > > > Please restate what your concerns are. > > > > > > -----Original Message----- > > > From: max pritikin [mailto:pritikin@cisco.com] > > > Sent: Tuesday, June 10, 2008 11:11 PM > > > To: Santosh Chokhani > > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > > Subject: Re: RFC 5280 Question > > > > > > > > > I'm not sure what Bob's goals are, perhaps just to ask > the question. > > > We don't work very closely together. > > > > > > This just struck a note with me because I've seen it raised as a > > > problem in other cases as well. > > > > > > - max > > > > > > On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > > > > >> > > >> Max, > > >> > > >> I am just responding to inaccuracies in what you are saying. > > >> > > >> Can you and Bob tell me why you started this thread and > > what you are > > >> seeking from the PKIX community? > > >> > > >> I for sure am clueless except for pointing out > inaccuracies in your > > >> assertions and/or conclusions. > > >> > > >> -----Original Message----- > > >> From: max pritikin [mailto:pritikin@cisco.com] > > >> Sent: Tuesday, June 10, 2008 6:51 PM > > >> To: Santosh Chokhani > > >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > >> Subject: Re: RFC 5280 Question > > >> > > >> > > >> Santosh, you've moved the conversation back to a > discussion of item > > >> (3) in my comments below: out-of-scope population of the trust > > >> anchors. I think this is orthogonal to a discussion of > dealing with > > >> trust-anchors that exactly match a single certificate being > > >> validated. > > >> > > >> - max > > >> > > >> > > >> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > > >> > > >>> > > >>> Max, > > >>> > > >>> I do not have any problem with successfully verifying > > signature made > > >>> by > > >>> a trust anchor. > > >>> > > >>> As I said a day or two back in this chain, if the relying > > party who > > >>> installs the certificate as a trust anchor and does not make > > >>> additional checks of basic constraints, is susceptible to > > >>> undetected > > compromise > > >>> of > > >>> this end entity certificate spawning an entire PKI hierarchy. > > >>> > > >>> -----Original Message----- > > >>> From: max pritikin [mailto:pritikin@cisco.com] > > >>> Sent: Tuesday, June 10, 2008 6:17 PM > > >>> To: Santosh Chokhani > > >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > >>> Subject: Re: RFC 5280 Question > > >>> > > >>> > > >>> We're into the realm of discussing _how_ one would modify > > >>> Certificate Path Validation to support EE certificates > as a trust > > anchor where > > >>> my > > >>> intention was only to support the concept as a discussion point. > > >>> > > >>> Santosh, it isn't that the constraints/extensions are > > ever applied > > >>> to > > >>> the trust anchor credential itself. It is that they are > > applied when > > >>> validating the chain. Take for example Name Constraints > or Policy > > >>> Constraints or other Basic Constraints fields such as > > >>> pathLenConstraint which are all in the trust anchor > > certificate and > > >>> then taken into account when validating a certificate > > chain. If the > > >>> trust anchor certificate does not have keyCertSign set then > > >>> logically no 'chained' certificates would be valid; > just like if > > >>> the pathLenConstraint was '1' but the chain being > verified has a > > >>> path length of something greater. > > >>> > > >>> I think this question of EE cert vs CA cert as a trust > anchor is > > >>> about what should happen if the chain being validated consists > > of only the > > >>> trust anchor. Independent of any questions concerning > key usage, > > >>> constraints or anything else. > > >>> > > >>> - max > > >>> > > >>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > > >>> > > >>>> > > >>>> Max, > > >>>> > > >>>> The text you cite does not apply to trust anchor. > > Please see X.509 > > >>>> and > > >>>> RFC 5280 path validation text. Nothing needs to be > > verified from a > > >>>> trust anchor. > > >>>> > > >>>> -----Original Message----- > > >>>> From: max pritikin [mailto:pritikin@cisco.com] > > >>>> Sent: Tuesday, June 10, 2008 4:47 PM > > >>>> To: Santosh Chokhani > > >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > >>>> Subject: Re: RFC 5280 Question > > >>>> > > >>>> > > >>>> Santosh, > > >>>> > > >>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: > > >>>>> The cA boolean indicates whether the certified public > key may be > > >>>>> used to verify certificate signatures. If the cA > boolean is not > > >>>>> asserted, then the keyCertSign bit in the key usage extension > > >>>>> MUST NOT be asserted. If the basic constraints > extension is not > > present in a > > >>>>> version 3 certificate, or the extension is present but the cA > > >>>>> boolean is not asserted, then the certified public > key MUST NOT > > be used to > > >>>>> verify certificate signatures. > > >>>> > > >>>> An EE certificate being in the trust store would not cause > > >>>> confusion about this. > > >>>> > > >>>> - max > > >>>> > > >>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > > >>>> > > >>>>> Max, > > >>>>> > > >>>>> I do not agree with your point on item 2. Once a > > certificate is a > > >>>>> trust > > >>>>> anchor, neither X.509 not 5280 have any constraints > on it from > > >>>>> being a issuer. > > >>>>> > > >>>>> Furthermore, path length constraint if present in the > > self-signed > > >>>>> certificate can be ignored by relying parties. > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: owner-ietf-pkix@mail.imc.org > > >>>> [mailto:owner-ietf-pkix@mail.imc.org > > >>>>> ] > > >>>>> On Behalf Of max pritikin > > >>>>> Sent: Tuesday, June 10, 2008 2:35 PM > > >>>>> To: Tim Polk > > >>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org > > >>>>> Subject: Re: RFC 5280 Question > > >>>>> > > >>>>> > > >>>>> > > >>>>> A few comments on this thread: > > >>>>> > > >>>>> 1) Any entry in the trust anchor store would seem to be > > "directly > > >>>>> trusted". If so an additional flag isn't needed so much as a > > >>>>> statement about how path validation proceeds if, during path > > >>>>> discovery, it turns out the certificate being validated is > > >>>>> already directly trusted. > > >>>>> > > >>>>> 2) Inclusion into the trust anchor store doesn't > imply that a > > >>>>> cert is trusted to issue certificates -- that is directly > > controlled by > > >>>>> the > > >>>>> values within the certificate (chain). > > >>>>> > > >>>>> 3) The out-of-band mechanism is out of scope for > > 5280/3280 but has > > >>>>> been the subject of recent BoF work (and more?). It > > would nice if > > >>>>> that > > >>>>> work also addressed this question. > > >>>>> > > >>>>> Issues related to this come up on a regular basis. > Look at the > > >>>>> various ways browser deal with caching EE certificates to > > "trust this site > > >>>>> always" etc. I think Bob has raised a good point. > > >>>>> > > >>>>> - max > > >>>>> > > >>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > > >>>>> > > >>>>>> > > >>>>>> Bob, > > >>>>>> > > >>>>>> [I realize I am late to the party, and that Santosh, > Steve, and > > >>>>>> Wen- > > >>>>>> Chen Wang have already provided a lot of good feedback. I > > >>>>>> decided to respond to the original message because I > would like > > >>>>>> to go back to the perceived requirement.] > > >>>>>> > > >>>>>> It sounds like you want to construct a list of > > directly trusted > > >>>>>> EE > > >>>>>> certificates, but are trying to satisfy this > > requirement using > > >>>>>> the > > >>>>>> application's trust anchor store. There is nothing > inherently > > >>>>>> wrong with direct trust (and RFC 5280 does not preclude > > >>>>>> directly trusting an EE certificate), but you really need a > > >>>>>> different - and far simpler - mechanism. The trust anchor > > >>>>>> store is > > implicitly linked > > >>>>>> to > > >>>>>> path discovery and validation, which are not relevant here > > >>>>>> since a directly trusted certificate cannot be > validated. With > > >>>>>> a directly trusted certificate, there is also no > mechanism to > > >>>>>> validate status information. > > >>>>>> > > >>>>>> To further complicate matters, storing the certificate > > you wish > > >>>>>> to > > >>>>>> directly trust in the trust anchor store implies that it is > > >>>>>> trusted to issue certificates as well. The path validation > > >>>>>> inputs specified in 6.1.1 (d) consider only four > aspects of a > > >>>>>> trust > > anchor (name, > > >>>>>> public key algorithm, public key, and parameters if > > needed). The > > >>>>>> assumption is that the trust anchor's authority to issue > > >>>>>> certificates was verified based on an out-of-band > > trust mechanism > > >>>>>> (which is out of scope for 5280). This makes sense > > since a trust > > >>>>>> anchor might have distributed a v1 certificate > (which does not > > >>>>>> include extensions). > > >>>>>> > > >>>>>> As others have noted, direct trust also implies an > out-of-band > > >>>>>> trust mechanism. I received the EE certificate from > a trusted > > >>>>>> source so I can trust the binding between the > subject name and > > >>>>>> the key; issuer > > >>>>>> name and the signature are irrelevant. If the certificate > > >>>>>> status > > >>>>>> matters, I am also depending on an out-of-band mechanism to > > >>>>>> inform me! The out-of-band mechanism(s) in combination with > > >>>>>> protected local storage provide the basis for > security in this > > >>>>>> system... > > >>>>>> > > >>>>>> Trying to combine these two mechanisms using a single > > certificate > > >>>>>> store probably requires an additional flag on every entry to > > >>>>>> differentiate between directly trusted certificates > and trust > > >>>>>> anchors. Two separate stores might be cleaner in > the long run. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> > > >>>>>> Tim Polk > > >>>>>> > > >>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > > >>>>>> > > >>>>>>> Folks- > > >>>>>>> > > >>>>>>> I am hoping someone can give me the answer to this. > Does RFC > > >>>>>>> 5280 adress the case where an end-entity certificate (not > > a CA cert) > > >>>>>>> is > > >>>>>>> installed in the trust anchor list by the user > accepting the > > >>>>>>> presented cert as authoritative and then the cert is > > >>>>>>> subsequently presented (in a later access to the > site). There > > >>>>>>> should be no path search, since the presented cert > is in the > > >>>>>>> trust > > anchor list. > > >>>>>>> So, > > >>>>>>> where is it defined to accept the end-entity cert? > > >>>>>>> > > >>>>>>> Thanks ---- Bob > > >>>>>>> > > >>>>>>> Bob Bell > > >>>>>>> Cisco Systems, Inc. > > >>>>>>> 576 S. Brentwood Ln. > > >>>>>>> Bountiful, UT 84010 > > >>>>>>> 801-294-3034 (v) > > >>>>>>> 801-294-3023 (f) > > >>>>>>> 801-971-4200 (c) > > >>>>>>> rtbell@cisco.com > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > > > > > ------=_NextPart_000_000D_01C8CD2B.D95540F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTMxNDAyMzlaMCMGCSqGSIb3DQEJBDEWBBTNcw0dIyKqY3YeZt2o 3s6NnbK0ezBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYAo/GyL2x66z20CSnaQzRN/6i5ssy+pEj2+HcFlTkw3JniNv06K4uXquDgb18yecFnJ6jdb LKBNhqYUqauKcAnBjDs16pI8QmzqLFgf4CQD3XT5vi87XEa1XTmqllFfEROOldZl4F1hn4VEXmhY YF3Sk+8Of/+lgU0KD9Mo2eBh6gAAAAAAAA== ------=_NextPart_000_000D_01C8CD2B.D95540F0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DDSpXr073447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 06:28:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DDSpuu073446; Fri, 13 Jun 2008 06:28:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5DDSnOO073431 for ; Fri, 13 Jun 2008 06:28:50 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 3263 invoked from network); 13 Jun 2008 13:18:30 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Jun 2008 13:18:30 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Jun 2008 13:18:30 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 09:28:48 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjNUnn99vETX4vJSAmOfi3qJ34J7AABsZiA References: From: "Santosh Chokhani" To: "pgut001" , Cc: , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We agree on the standard's required behavior, which has been the focus of my posts in this thread. -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Friday, June 13, 2008 8:39 AM To: pgut001@cs.auckland.ac.nz; pritikin@cisco.com; Santosh Chokhani Cc: ietf-pkix@imc.org; rtbell@cisco.com; tim.polk@nist.gov Subject: RE: RFC 5280 Question SChokhani@cygnacom.com writes: >Are you saying that the standard requires you to check and enforce >constraints in a trust anchor which is a self-signed X.509 certificate? No, the standard requires that you not check trust anchors. This is completely contrary to what users (and implementors) seem to expect. Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DCdA9V064173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 05:39:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DCdA5g064171; Fri, 13 Jun 2008 05:39:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DCd8l1064142 for ; Fri, 13 Jun 2008 05:39:09 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2BA289C5BE; Sat, 14 Jun 2008 00:39:08 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSngzkJThewf; Sat, 14 Jun 2008 00:39:08 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7A78E9C5BC; Sat, 14 Jun 2008 00:39:07 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id F31D919EC0BA; Sat, 14 Jun 2008 00:39:02 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1K78YY-0004kk-Rp; Sat, 14 Jun 2008 00:39:02 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, pritikin@cisco.com, SChokhani@cygnacom.com Subject: RE: RFC 5280 Question Cc: ietf-pkix@imc.org, rtbell@cisco.com, tim.polk@nist.gov In-Reply-To: Message-Id: Date: Sat, 14 Jun 2008 00:39:02 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: SChokhani@cygnacom.com writes: >Are you saying that the standard requires you to check and enforce >constraints in a trust anchor which is a self-signed X.509 certificate? No, the standard requires that you not check trust anchors. This is completely contrary to what users (and implementors) seem to expect. Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DBdmmi051212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 04:39:48 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DBdm53051211; Fri, 13 Jun 2008 04:39:48 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5DBdkkj051198 for ; Fri, 13 Jun 2008 04:39:47 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 2452 invoked from network); 13 Jun 2008 11:29:27 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Jun 2008 11:29:27 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Jun 2008 11:29:27 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 07:39:45 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjNSbJckqAY98ZpRRWG76P16dRz0QAAEsjg References: From: "Santosh Chokhani" To: "pgut001" , Cc: , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Are you saying that the standard requires you to check and enforce constraints in a trust anchor which is a self-signed X.509 certificate? -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Friday, June 13, 2008 7:36 AM To: pgut001@cs.auckland.ac.nz; pritikin@cisco.com; Santosh Chokhani Cc: ietf-pkix@imc.org; rtbell@cisco.com; tim.polk@nist.gov Subject: RE: RFC 5280 Question "Santosh Chokhani" writes: >So you agree that standard does not require it and changing it is a change in >standard. I was told by the X.509 person that the standard does require it, and from the=20 text they forwarded me I would agree that it does. OTOH it doesn't make any=20 sense for the standard to require it, and it seems to (from my informal=20 survey) do the complete opposite of what customers expect. In other words it=20 violates the principle of least surprise. >And assuming that clients check it, is risky albeit many may check. Again, from an informal survey I'd say that the majority don't check, and that the developers of the apps don't even know of this requirement. In my case I do know of it but since the response from users about whether they wanted (or would ever expect) this behaviour was 100% negative, I explicitly don't implement it. Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DBaHrR050453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 04:36:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DBaHB6050452; Fri, 13 Jun 2008 04:36:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DBaG0M050437 for ; Fri, 13 Jun 2008 04:36:16 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 91E814809AB; Fri, 13 Jun 2008 23:36:15 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSgHAlefXh2h; Fri, 13 Jun 2008 23:36:15 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2DF974809A8; Fri, 13 Jun 2008 23:36:15 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id A6AF019EC0BA; Fri, 13 Jun 2008 23:36:08 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1K77Zg-0001qr-HN; Fri, 13 Jun 2008 23:36:08 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, pritikin@cisco.com, SChokhani@cygnacom.com Subject: RE: RFC 5280 Question Cc: ietf-pkix@imc.org, rtbell@cisco.com, tim.polk@nist.gov In-Reply-To: Message-Id: Date: Fri, 13 Jun 2008 23:36:08 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Santosh Chokhani" writes: >So you agree that standard does not require it and changing it is a change in >standard. I was told by the X.509 person that the standard does require it, and from the text they forwarded me I would agree that it does. OTOH it doesn't make any sense for the standard to require it, and it seems to (from my informal survey) do the complete opposite of what customers expect. In other words it violates the principle of least surprise. >And assuming that clients check it, is risky albeit many may check. Again, from an informal survey I'd say that the majority don't check, and that the developers of the apps don't even know of this requirement. In my case I do know of it but since the response from users about whether they wanted (or would ever expect) this behaviour was 100% negative, I explicitly don't implement it. Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DAtBJK042183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 03:55:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DAtBJ6042182; Fri, 13 Jun 2008 03:55:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5DAt9QX042165 for ; Fri, 13 Jun 2008 03:55:10 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 2193 invoked from network); 13 Jun 2008 10:44:51 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Jun 2008 10:44:51 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Jun 2008 10:44:50 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 06:55:08 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjNQ48rVMCZ7gAGTDW/c9JnYbl/+QAAEVXw References: From: "Santosh Chokhani" To: "pgut001" , Cc: , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: So you agree that standard does not require it and changing it is a change in standard. And assuming that clients check it, is risky albeit many may check. -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Friday, June 13, 2008 6:52 AM To: pritikin@cisco.com; Santosh Chokhani Cc: ietf-pkix@imc.org; rtbell@cisco.com; tim.polk@nist.gov Subject: RE: RFC 5280 Question "Santosh Chokhani" writes: >The text you cite does not apply to trust anchor. Please see X.509 and RFC >5280 path validation text. Nothing needs to be verified from a trust anchor. Right, but when I checked about two years ago a significant number of PKI=20 implementors weren't even aware that this crazy requirement exists, let alone=20 implemented it in their code (when alerted to the requirement, several said=20 they would explicitly not implement it because it constituted broken behaviour=20 and they didn't want to deal with the customer support issues). The only=20 reason I know it exists was because someone on the X.509 standards committee=20 told me about it. I asked for a reference, because I couldn't believe that=20 explicitly ignoring everything in a root cert was required by the standard,=20 and they said they'd get back to me. Two weeks later they'd managed to find=20 it in the spec, and this was one of the people responsible for writing it! So in general proceeding under the assumption that many (most?)=20 implementations aren't going to do ignore checking of root certs/trust anchors=20 is safe. Or if you want to be strict about it, proceeding under the=20 assumption that whether an implementation checks or not is pretty much a coin-toss is safe. Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DAqMoP041907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 03:52:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DAqMJC041906; Fri, 13 Jun 2008 03:52:22 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DAqJsE041899 for ; Fri, 13 Jun 2008 03:52:22 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0A1FE9C60C; Fri, 13 Jun 2008 22:52:10 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKqaKyEjUcrk; Fri, 13 Jun 2008 22:52:09 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EF6239C5FB; Fri, 13 Jun 2008 22:52:08 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id DE47F19EC0BA; Fri, 13 Jun 2008 22:52:01 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1K76sz-00084o-Pz; Fri, 13 Jun 2008 22:52:01 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pritikin@cisco.com, SChokhani@cygnacom.com Subject: RE: RFC 5280 Question Cc: ietf-pkix@imc.org, rtbell@cisco.com, tim.polk@nist.gov In-Reply-To: Message-Id: Date: Fri, 13 Jun 2008 22:52:01 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Santosh Chokhani" writes: >The text you cite does not apply to trust anchor. Please see X.509 and RFC >5280 path validation text. Nothing needs to be verified from a trust anchor. Right, but when I checked about two years ago a significant number of PKI implementors weren't even aware that this crazy requirement exists, let alone implemented it in their code (when alerted to the requirement, several said they would explicitly not implement it because it constituted broken behaviour and they didn't want to deal with the customer support issues). The only reason I know it exists was because someone on the X.509 standards committee told me about it. I asked for a reference, because I couldn't believe that explicitly ignoring everything in a root cert was required by the standard, and they said they'd get back to me. Two weeks later they'd managed to find it in the spec, and this was one of the people responsible for writing it! So in general proceeding under the assumption that many (most?) implementations aren't going to do ignore checking of root certs/trust anchors is safe. Or if you want to be strict about it, proceeding under the assumption that whether an implementation checks or not is pretty much a coin-toss is safe. Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5DAaxL5038529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 03:36:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5DAaxkk038528; Fri, 13 Jun 2008 03:36:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5DAavfW038522 for ; Fri, 13 Jun 2008 03:36:58 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 2101 invoked from network); 13 Jun 2008 10:26:38 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Jun 2008 10:26:38 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Jun 2008 10:26:37 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Fri, 13 Jun 2008 06:36:55 -0400 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0034_01C8CD1F.DA0F3890" Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjM4R2FGr+XJh/aR3icrE8p2IycgQACdOqgAAQzQhAAEVhCQA== References: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , "Max Pritikin (pritikin)" Cc: "Tim Polk" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C8CD1F.DA0F3890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bob, If basic constraints is absent or false, a certificate is not a CA certificate. The problem comes in with trust anchors. Any requirements to process trust anchors is a change in the standard and raises backward compatibility issues. -----Original Message----- From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] Sent: Thursday, June 12, 2008 10:21 PM To: Santosh Chokhani; Max Pritikin (pritikin) Cc: Tim Polk; ietf-pkix@imc.org Subject: RE: RFC 5280 Question Santosh - I would recommend that the definition be broadened slightly to indicate that regardless of whether basic constraints are present (as long as the CA bit is false or non-existent), and that the keyCertSign bit is false. This, at least as I read the definitions, defines the cert as an end-entity cert. That kind of a cert in the trust store is what is causing problems for me. Bob > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani > Sent: Thursday, 12 June, 2008 18:21 > To: Max Pritikin (pritikin) > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > > Max, > > So, are you saying that you wanted to explore the implication > of a self-signed certificate that does not have basic > constraints extension in it and does not set keyCertSign bit > in the key usage? I ask because that is the certificate Bob sent me. > > Please provide a clear, concise and complete description of > your issues so that we have the same point of reference for > discussions. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Thursday, June 12, 2008 7:07 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > I think Bob's question touched on an important issue. The > inclusion of > self-signed or EE certificates into the certificate store. > > For an example one should experiment with how the various major web > browsers handle "trust this certificate" (sometimes called > "trust this > web page" etc). They all do it differently. > > - max > > On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: > > > > > Max, > > > > I do not understand from your posting what the specific concern or > > issue > > you want to bring to the attention of PKIX. > > > > We have had lot of digressions on this topic. > > > > Please restate what your concerns are. > > > > -----Original Message----- > > From: max pritikin [mailto:pritikin@cisco.com] > > Sent: Tuesday, June 10, 2008 11:11 PM > > To: Santosh Chokhani > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > Subject: Re: RFC 5280 Question > > > > > > I'm not sure what Bob's goals are, perhaps just to ask the question. > > We don't work very closely together. > > > > This just struck a note with me because I've seen it raised as a > > problem in other cases as well. > > > > - max > > > > On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > > >> > >> Max, > >> > >> I am just responding to inaccuracies in what you are saying. > >> > >> Can you and Bob tell me why you started this thread and > what you are > >> seeking from the PKIX community? > >> > >> I for sure am clueless except for pointing out inaccuracies in your > >> assertions and/or conclusions. > >> > >> -----Original Message----- > >> From: max pritikin [mailto:pritikin@cisco.com] > >> Sent: Tuesday, June 10, 2008 6:51 PM > >> To: Santosh Chokhani > >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >> Subject: Re: RFC 5280 Question > >> > >> > >> Santosh, you've moved the conversation back to a discussion of item > >> (3) in my comments below: out-of-scope population of the trust > >> anchors. I think this is orthogonal to a discussion of dealing with > >> trust-anchors that exactly match a single certificate being > >> validated. > >> > >> - max > >> > >> > >> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > >> > >>> > >>> Max, > >>> > >>> I do not have any problem with successfully verifying > signature made > >>> by > >>> a trust anchor. > >>> > >>> As I said a day or two back in this chain, if the relying > party who > >>> installs the certificate as a trust anchor and does not make > >>> additional > >>> checks of basic constraints, is susceptible to undetected > compromise > >>> of > >>> this end entity certificate spawning an entire PKI hierarchy. > >>> > >>> -----Original Message----- > >>> From: max pritikin [mailto:pritikin@cisco.com] > >>> Sent: Tuesday, June 10, 2008 6:17 PM > >>> To: Santosh Chokhani > >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >>> Subject: Re: RFC 5280 Question > >>> > >>> > >>> We're into the realm of discussing _how_ one would modify > >>> Certificate > >>> Path Validation to support EE certificates as a trust > anchor where > >>> my > >>> intention was only to support the concept as a discussion point. > >>> > >>> Santosh, it isn't that the constraints/extensions are > ever applied > >>> to > >>> the trust anchor credential itself. It is that they are > applied when > >>> validating the chain. Take for example Name Constraints or Policy > >>> Constraints or other Basic Constraints fields such as > >>> pathLenConstraint which are all in the trust anchor > certificate and > >>> then taken into account when validating a certificate > chain. If the > >>> trust anchor certificate does not have keyCertSign set then > >>> logically > >>> no 'chained' certificates would be valid; just like if the > >>> pathLenConstraint was '1' but the chain being verified has a path > >>> length of something greater. > >>> > >>> I think this question of EE cert vs CA cert as a trust anchor is > >>> about > >>> what should happen if the chain being validated consists > of only the > >>> trust anchor. Independent of any questions concerning key usage, > >>> constraints or anything else. > >>> > >>> - max > >>> > >>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > >>> > >>>> > >>>> Max, > >>>> > >>>> The text you cite does not apply to trust anchor. > Please see X.509 > >>>> and > >>>> RFC 5280 path validation text. Nothing needs to be > verified from a > >>>> trust anchor. > >>>> > >>>> -----Original Message----- > >>>> From: max pritikin [mailto:pritikin@cisco.com] > >>>> Sent: Tuesday, June 10, 2008 4:47 PM > >>>> To: Santosh Chokhani > >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >>>> Subject: Re: RFC 5280 Question > >>>> > >>>> > >>>> Santosh, > >>>> > >>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: > >>>>> The cA boolean indicates whether the certified public key may be > >>>>> used > >>>>> to verify certificate signatures. If the cA boolean is not > >>>>> asserted, > >>>>> then the keyCertSign bit in the key usage extension MUST NOT be > >>>>> asserted. If the basic constraints extension is not > present in a > >>>>> version 3 certificate, or the extension is present but the cA > >>>>> boolean > >>>>> is not asserted, then the certified public key MUST NOT > be used to > >>>>> verify certificate signatures. > >>>> > >>>> An EE certificate being in the trust store would not cause > >>>> confusion > >>>> about this. > >>>> > >>>> - max > >>>> > >>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > >>>> > >>>>> Max, > >>>>> > >>>>> I do not agree with your point on item 2. Once a > certificate is a > >>>>> trust > >>>>> anchor, neither X.509 not 5280 have any constraints on it from > >>>>> being a > >>>>> issuer. > >>>>> > >>>>> Furthermore, path length constraint if present in the > self-signed > >>>>> certificate can be ignored by relying parties. > >>>>> > >>>>> -----Original Message----- > >>>>> From: owner-ietf-pkix@mail.imc.org > >>>> [mailto:owner-ietf-pkix@mail.imc.org > >>>>> ] > >>>>> On Behalf Of max pritikin > >>>>> Sent: Tuesday, June 10, 2008 2:35 PM > >>>>> To: Tim Polk > >>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org > >>>>> Subject: Re: RFC 5280 Question > >>>>> > >>>>> > >>>>> > >>>>> A few comments on this thread: > >>>>> > >>>>> 1) Any entry in the trust anchor store would seem to be > "directly > >>>>> trusted". If so an additional flag isn't needed so much as a > >>>>> statement > >>>>> about how path validation proceeds if, during path discovery, it > >>>>> turns > >>>>> out the certificate being validated is already directly trusted. > >>>>> > >>>>> 2) Inclusion into the trust anchor store doesn't imply that a > >>>>> cert > >>>>> is > >>>>> trusted to issue certificates -- that is directly > controlled by > >>>>> the > >>>>> values within the certificate (chain). > >>>>> > >>>>> 3) The out-of-band mechanism is out of scope for > 5280/3280 but has > >>>>> been the subject of recent BoF work (and more?). It > would nice if > >>>>> that > >>>>> work also addressed this question. > >>>>> > >>>>> Issues related to this come up on a regular basis. Look at the > >>>>> various > >>>>> ways browser deal with caching EE certificates to > "trust this site > >>>>> always" etc. I think Bob has raised a good point. > >>>>> > >>>>> - max > >>>>> > >>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > >>>>> > >>>>>> > >>>>>> Bob, > >>>>>> > >>>>>> [I realize I am late to the party, and that Santosh, Steve, and > >>>>>> Wen- > >>>>>> Chen Wang have already provided a lot of good feedback. I > >>>>>> decided > >>>>>> to respond to the original message because I would like to go > >>>>>> back > >>>>>> to the perceived requirement.] > >>>>>> > >>>>>> It sounds like you want to construct a list of > directly trusted > >>>>>> EE > >>>>>> certificates, but are trying to satisfy this > requirement using > >>>>>> the > >>>>>> application's trust anchor store. There is nothing inherently > >>>>>> wrong > >>>>>> with direct trust (and RFC 5280 does not preclude directly > >>>>>> trusting > >>>>>> an EE certificate), but you really need a different - and far > >>>>>> simpler - mechanism. The trust anchor store is > implicitly linked > >>>>>> to > >>>>>> path discovery and validation, which are not relevant here > >>>>>> since a > >>>>>> directly trusted certificate cannot be validated. With a > >>>>>> directly > >>>>>> trusted certificate, there is also no mechanism to validate > >>>>>> status > >>>>>> information. > >>>>>> > >>>>>> To further complicate matters, storing the certificate > you wish > >>>>>> to > >>>>>> directly trust in the trust anchor store implies that it is > >>>>>> trusted > >>>>>> to issue certificates as well. The path validation inputs > >>>>>> specified > >>>>>> in 6.1.1 (d) consider only four aspects of a trust > anchor (name, > >>>>>> public key algorithm, public key, and parameters if > needed). The > >>>>>> assumption is that the trust anchor's authority to issue > >>>>>> certificates was verified based on an out-of-band > trust mechanism > >>>>>> (which is out of scope for 5280). This makes sense > since a trust > >>>>>> anchor might have distributed a v1 certificate (which does not > >>>>>> include extensions). > >>>>>> > >>>>>> As others have noted, direct trust also implies an out-of-band > >>>>>> trust > >>>>>> mechanism. I received the EE certificate from a trusted source > >>>>>> so I > >>>>>> can trust the binding between the subject name and the key; > >>>>>> issuer > >>>>>> name and the signature are irrelevant. If the certificate > >>>>>> status > >>>>>> matters, I am also depending on an out-of-band mechanism to > >>>>>> inform > >>>>>> me! The out-of-band mechanism(s) in combination with protected > >>>>>> local storage provide the basis for security in this system... > >>>>>> > >>>>>> Trying to combine these two mechanisms using a single > certificate > >>>>>> store probably requires an additional flag on every entry to > >>>>>> differentiate between directly trusted certificates and trust > >>>>>> anchors. Two separate stores might be cleaner in the long run. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Tim Polk > >>>>>> > >>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > >>>>>> > >>>>>>> Folks- > >>>>>>> > >>>>>>> I am hoping someone can give me the answer to this. Does RFC > >>>>>>> 5280 > >>>>>>> adress the case where an end-entity certificate (not > a CA cert) > >>>>>>> is > >>>>>>> installed in the trust anchor list by the user accepting the > >>>>>>> presented cert as authoritative and then the cert is > >>>>>>> subsequently > >>>>>>> presented (in a later access to the site). There should be no > >>>>>>> path > >>>>>>> search, since the presented cert is in the trust > anchor list. > >>>>>>> So, > >>>>>>> where is it defined to accept the end-entity cert? > >>>>>>> > >>>>>>> Thanks ---- Bob > >>>>>>> > >>>>>>> Bob Bell > >>>>>>> Cisco Systems, Inc. > >>>>>>> 576 S. Brentwood Ln. > >>>>>>> Bountiful, UT 84010 > >>>>>>> 801-294-3034 (v) > >>>>>>> 801-294-3023 (f) > >>>>>>> 801-971-4200 (c) > >>>>>>> rtbell@cisco.com > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > ------=_NextPart_000_0034_01C8CD1F.DA0F3890 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCCA60w ggKVoAMCAQICBECEF1YwDQYJKoZIhvcNAQEFBQAwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5 Z25hY29tMB4XDTA0MDQxOTE3NDYwMVoXDTI0MDQxOTE4MTYwMVowIDELMAkGA1UEBhMCdXMxETAP BgNVBAoTCGN5Z25hY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuw8jjNSH/3qx UShITC4+vYJG8TZsE2f4pbGUhcXe+v0PChxtWvVpOAVqXm/7y1hdBKKMjdg98Xo/jmVtFPGlKXhV v9FYyK1zxydN1YgEjRzmuSd9RNNm9YL2rgg2Q/TtT3hDwDiT4rj62ukIKYTlZHNLm1t7uYa8K/44 F5jJvo6zPkWtRqrKBFJfBblKFaPteEXU5JIKX8cbwIF3HJx9+P15S0wRngCKb0+1/d9pIuwS4Frg 1R98hG+jRXiS8klB6TncucWH2w1OqYouzUGSncb+o+EVx4PHwsE7kKxIMAsQC6zbHsAS0CAOb6hw JW7P+dtaR/9Gi8NdKsgkFlQjbQIDAQABo4HuMIHrMEIGA1UdHwQ7MDkwN6A1oDOkMTAvMQswCQYD VQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20xDTALBgNVBAMTBENSTDEwKwYDVR0QBCQwIoAPMjAw NDA0MTkxNzQ2MDFagQ8yMDI0MDQxOTE4MTYwMVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFHqT o3DI3p2/kOS+O6DeN/DUalp5MB0GA1UdDgQWBBR6k6NwyN6dv5Dkvjug3jfw1GpaeTAMBgNVHRME BTADAQH/MB0GCSqGSIb2fQdBAAQQMA4bCFY3LjA6NC4wAwIEkDANBgkqhkiG9w0BAQUFAAOCAQEA aHtrFA6rDnATj2GxfNuRLFVrsWBLSCYUdMs6YbssKI2f/Fh/o382eAnvvcpI76koLijn4Cbj482A tkWgw6hOhgESamFWaY951O0nUrk43KG5Nv4KQjXiNArFwf1ATEtB6KTeiaffh2vVbUWodZ+uwnTh X6ZlPmVooWFcB9NH+9GteR7zIJA/Eq0p0CHiCozIhOp1QGJ2cXTtHQk4Cq+sYh8du6ry0xRB3b5Z Jw/iewtxAoge2e/vh0f46mgrSdmCuPzjVLvyLg63ktN9hJe8Iiy4JiKqplnsMGizW2lxKwl/Ys0L alsltxYuLF1jytrzGJEit+5acGcjhdhijL0IojCCA7cwggKfoAMCAQICBECEfaYwDQYJKoZIhvcN AQEFBQAwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tMB4XDTA4MDIwNDE5MzE1N1oX DTExMDIwNDIwMDE1N1owOzELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tMRkwFwYDVQQD ExBTYW50b3NoIENob2toYW5pMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs9o3aeGJ DZDK4g4sEFFK6w+OkEcGHDQjYRCIuqh7uC3mVnPAk3lyUaRoVXJtZw3w8kD0XVbSH86u090X60cP zAtgW4irh9vEKQ/B2ze/D9DHjNp6y5t3Eq/LyPYLPFFivWfccVygX0ufdgJ37z2lXZhg+mVIms48 PxBOtRWGH66wNc75+NkmpRDgi4byKUOKcfy8Fm52lUrnN4GEuv/fFBSBQAWdbafCHbuDJp/KZMEX lEqnQ1GemkuAbMmj37dcP5Vw57UQlF2LILXswfmTH2JQdqTXz635HlPfJQS9yuX/MP+upkPGRToy RMFrufttu7M3mmPofNW7kFgT0jL+eQIDAQABo4HdMIHaMCEGA1UdEQQaMBiBFnNjaG9raGFuaUBj eWduYWNvbS5jb20wQgYDVR0fBDswOTA3oDWgM6QxMC8xCzAJBgNVBAYTAnVzMREwDwYDVQQKEwhj eWduYWNvbTENMAsGA1UEAxMEQ1JMMTALBgNVHQ8EBAMCBSAwHwYDVR0jBBgwFoAUepOjcMjenb+Q 5L47oN438NRqWnkwHQYDVR0OBBYEFN3Oy0J5Tcq3swE9ftXJsWLGkP/RMAkGA1UdEwQCMAAwGQYJ KoZIhvZ9B0EABAwwChsEVjcuMAMCBJAwDQYJKoZIhvcNAQEFBQADggEBABhU71iFvfdyRs+fo+it Pum3CUTu4aufARo9Rva+r/fmeBFyFc/jryqFtqoqS17dATYAgjr/7Yk12g72o4TsKN5ganteAM2r r61E5+4h2ucGHLfWykqZtKg2w84n5wbIGXG6PgAaFxk9KwbQEhcHKGRESN9HszXdonYBjMwQLqb2 VSzP+PDD0ACSHPlaL4KdaQ+pnUtdmHpTK1Yr0HoxQ6vc8xXdKQvFV6xmrAJBDGFkHf5INrkSBMhP W1xf+ogv94VptXt0DLW06mhvkp3sniARXFFWKFfPxqsLAsmR2c/uJfr4zjSi4t2h6L41NgeM5+AN ezuwuorXARAk+uaOC5MwggPmMIICzqADAgECAgRAhH2oMA0GCSqGSIb3DQEBBQUAMCAxCzAJBgNV BAYTAnVzMREwDwYDVQQKEwhjeWduYWNvbTAeFw0wODAyMDQxOTM1NTlaFw0xMTAyMDQyMDA1NTla MDsxCzAJBgNVBAYTAnVzMREwDwYDVQQKEwhjeWduYWNvbTEZMBcGA1UEAxMQU2FudG9zaCBDaG9r aGFuaTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ1rEVGyPcyt6QIby/uVXD9cMpBF wYLQjOM6dNXMzQIEUXRtcT0W8tC41xHPKyFLWAp9FYz6S8bLV59/M0+yi+fTRFvz0Nzpp8Gl4XZD xE5oucsywODMnZUnPyEjasL6v02CDu5Q4MEGNu0Wg1VeryppZrK2IZ0BEwK1Of2bgLWkPfbJuflS 9QOAMwKhSpJ6rb1o8WCqms6CC3Y9hf3HG7yYfc8k7gievsnZhSUWTOChPul963Q4qLxvC6MDxF2O kM+bnGW5WY7EpneZAsM8K/B/8VTg8YnBcQJdVrhQkoBMhJc7m3YPU3zGFpjhjzWDL3nHsxSSw85O QI52kMxU1J0CAwEAAaOCAQswggEHMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDA4MDIwNDE5 MzU1OVqBDzIwMTAwMzEzMDAwNTU5WjAhBgNVHREEGjAYgRZzY2hva2hhbmlAY3lnbmFjb20uY29t MEIGA1UdHwQ7MDkwN6A1oDOkMTAvMQswCQYDVQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20xDTAL BgNVBAMTBENSTDEwHwYDVR0jBBgwFoAUepOjcMjenb+Q5L47oN438NRqWnkwHQYDVR0OBBYEFMpd jcqM0dS0T98qfQfCqOQmoEhLMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMAMCBLAw DQYJKoZIhvcNAQEFBQADggEBAA/ZNrruYd642E8uMJ1EIDbQNsbPuNO7KXZpTcRT9DxntFCfMFkR hnIZDETqQaIVtCCMRd0kOk+rf8PCYhyqybY0S/fovU3zW3LIVLICCN01CgUpQwejJxVsGFBVPdtK AwOHneG99t6Etr2NuWCGKR6Z4pRtYjLsI80NoZz8pC5WnjFuClbse5S/PQ1L9PhdLTS/xk2bn/Rx +wYMamRki4Ec6Wgu47ud3JfmNhrmmN5TuGocHG7XwS6JtXb3wG0qcXlzg8sNlqk1doswxsMTQHUt eqK8JASKjmkIl5MusXaZRvSD6DJQzkQxpJeEujTsUrPUtCHVHoYmQGKseTEc8CkxggKNMIICiQIB ATAoMCAxCzAJBgNVBAYTAnVzMREwDwYDVQQKEwhjeWduYWNvbQIEQIR9qDAJBgUrDgMCGgUAoIIB OjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MTMxMDM2NDZa MCMGCSqGSIb3DQEJBDEWBBRyWpM0QzCxpNvt6n7asY9OCWWffzA3BgkrBgEEAYI3EAQxKjAoMCAx CzAJBgNVBAYTAnVzMREwDwYDVQQKEwhjeWduYWNvbQIEQIR9pjA5BgsqhkiG9w0BCRACCzEqoCgw IDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tAgRAhH2mMGcGCSqGSIb3DQEJDzFaMFgw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAB78wXuLV7x2 mNUW3wFO9Ga8hSTgTy64EwvEVWHtYfj21rTRJuD7ldaxPecp6hH2fMVRb7mPA5Fuqu8njtAOmO4r 0U9i7ynxSES9/zId4aR516SPyLIsiUtFSfxRkU09lTgDnSbGhmf8aKxxWMWShByr6Q5iQFGX6WYS YJ4FARrX7Xqs+HGxy25aqnp6k/dpebSC/kEY3fpGkT26pT8ro02Z1EISRsJO1YQIPLIJjkxYOarB RGUQTvyPsJ5VoXRMgVsyZi0ij8LGjYVJ4jTsnjoaGLCpCsTneinOgILHK8b4Lu9RRX6S7LtWXKTm 83ba4wkxPTJNpaXeo5wvJajQGZIAAAAAAAA= ------=_NextPart_000_0034_01C8CD1F.DA0F3890-- Received: from [77.76.64.199] ([77.76.64.199]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5D9tsq8027702 for ; Fri, 13 Jun 2008 02:55:59 -0700 (MST) (envelope-from confient1956@PROMHOME.COM) To: ietf-pkix-archive@imc.org Subject: Get all your needed meds here From: Ganim Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Fri, 13 Jun 2008 10:55:59 +0100 Message-ID: User-Agent: Opera Mail/9.50 (Win32) Order your regular meds online now for super discounts and fast delivery http://www.bilkaten.com/ -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5D8j96m012455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 01:45:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5D8j9OF012454; Fri, 13 Jun 2008 01:45:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (kraid.ipv6.nerim.net [IPv6:2001:7a8:1:1::95]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5D8j73o012447 for ; Fri, 13 Jun 2008 01:45:08 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id A2B1CCF095; Fri, 13 Jun 2008 10:45:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 0DA00442A0; Fri, 13 Jun 2008 10:45:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqIHsSDrauUA; Fri, 13 Jun 2008 10:44:59 +0200 (CEST) Received: from [10.0.1.15] (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with ESMTP id 7487749717; Fri, 13 Jun 2008 10:13:52 +0200 (CEST) Message-ID: <48522C3F.4050103@cryptolog.com> Date: Fri, 13 Jun 2008 10:13:51 +0200 From: Julien Stern User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: "Bob Bell (rtbell)" Cc: Santosh Chokhani , "Max Pritikin (pritikin)" , Tim Polk , ietf-pkix@imc.org Subject: Re: RFC 5280 Question References: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If I may (briefly) jump into the discussion. There seem to be a misunderstanding regarding "trusted certificates" and "trust store". Neither X.509 nor 5280 define the notion of trust store or trusted certificate. This does not exist and there is no such thing as trusted EE certificates or trusted CA certificates. You can have a "Trust Anchor" that is a DN and a public Key (see X.509 p.6 for the definition) which can be used to verify other certificates. In practice, the DN and the public key, are commonly distributed as an X.509 certificate, but that's to make things simple. Extensions/constraints, etc are not supposed to apply (See validation algorithm in X.509, p.50) Then, you have the notion of "Direct Trust", which is not clearly expressed in X.509 or 5280, but which is natural in a PKI. Direct Trust means that you have verified the binding between a DN and a public key by out of band means. In other words, it means you know the owner of the key. It this owner happens to be a CA, you are essentially in the "Trust Anchor" case. Otherwise, you are also supposed to know (by out of band means) what the public key can be used for. In your specific case, my reading of the standard is the following: 1) you insert a "certificate" in a "trust store" => This means that you insert only the public key and the DN as trusted and as a CA (the rest of the certificate is irrelevant). 2) You want to try to use standard validation mechanisms (and not direct trust). You take your EE cert, and since it is self signed and self-issued, it will validate up to the trust anchor that you have entered. 3) Be warned, however, that the owner of this public key will now be able to issue as many certificates for other DNs that he wishes. Alternative option: you use "direct trust". 1) You insert your certificate in a "direct trust store". 2) When encountering the certificate, you do not perform the X.509 validation if is it "directly trusted" 3) Be warned that you can only revoke by hand. Now, I believe (experts, please correct me if I'm wrong), that you are free to modify the X.509 or the 5280 validation algorithm as long as you are more restrictive. So, I assume you could define a "trust store with constraints" that would be populated with "trust anchors with constraints" in any way you see fit. Hope this helps. Regards, -- Julien Bob Bell (rtbell) wrote: > Santosh - > > I would recommend that the definition be broadened slightly to indicate that > regardless of whether basic constraints are present (as long as the CA bit > is false or non-existent), and that the keyCertSign bit is false. This, at > least as I read the definitions, defines the cert as an end-entity cert. > That kind of a cert in the trust store is what is causing problems for me. > > Bob > >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org >> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani >> Sent: Thursday, 12 June, 2008 18:21 >> To: Max Pritikin (pritikin) >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> >> Max, >> >> So, are you saying that you wanted to explore the implication >> of a self-signed certificate that does not have basic >> constraints extension in it and does not set keyCertSign bit >> in the key usage? I ask because that is the certificate Bob sent me. >> >> Please provide a clear, concise and complete description of >> your issues so that we have the same point of reference for >> discussions. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Thursday, June 12, 2008 7:07 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> I think Bob's question touched on an important issue. The >> inclusion of >> self-signed or EE certificates into the certificate store. >> >> For an example one should experiment with how the various major web >> browsers handle "trust this certificate" (sometimes called >> "trust this >> web page" etc). They all do it differently. >> >> - max >> >> On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: >> >>> Max, >>> >>> I do not understand from your posting what the specific concern or >>> issue >>> you want to bring to the attention of PKIX. >>> >>> We have had lot of digressions on this topic. >>> >>> Please restate what your concerns are. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 11:11 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> I'm not sure what Bob's goals are, perhaps just to ask the question. >>> We don't work very closely together. >>> >>> This just struck a note with me because I've seen it raised as a >>> problem in other cases as well. >>> >>> - max >>> >>> On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I am just responding to inaccuracies in what you are saying. >>>> >>>> Can you and Bob tell me why you started this thread and >> what you are >>>> seeking from the PKIX community? >>>> >>>> I for sure am clueless except for pointing out inaccuracies in your >>>> assertions and/or conclusions. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 6:51 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> Santosh, you've moved the conversation back to a discussion of item >>>> (3) in my comments below: out-of-scope population of the trust >>>> anchors. I think this is orthogonal to a discussion of dealing with >>>> trust-anchors that exactly match a single certificate being >>>> validated. >>>> >>>> - max >>>> >>>> >>>> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I do not have any problem with successfully verifying >> signature made >>>>> by >>>>> a trust anchor. >>>>> >>>>> As I said a day or two back in this chain, if the relying >> party who >>>>> installs the certificate as a trust anchor and does not make >>>>> additional >>>>> checks of basic constraints, is susceptible to undetected >> compromise >>>>> of >>>>> this end entity certificate spawning an entire PKI hierarchy. >>>>> >>>>> -----Original Message----- >>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>> Sent: Tuesday, June 10, 2008 6:17 PM >>>>> To: Santosh Chokhani >>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> We're into the realm of discussing _how_ one would modify >>>>> Certificate >>>>> Path Validation to support EE certificates as a trust >> anchor where >>>>> my >>>>> intention was only to support the concept as a discussion point. >>>>> >>>>> Santosh, it isn't that the constraints/extensions are >> ever applied >>>>> to >>>>> the trust anchor credential itself. It is that they are >> applied when >>>>> validating the chain. Take for example Name Constraints or Policy >>>>> Constraints or other Basic Constraints fields such as >>>>> pathLenConstraint which are all in the trust anchor >> certificate and >>>>> then taken into account when validating a certificate >> chain. If the >>>>> trust anchor certificate does not have keyCertSign set then >>>>> logically >>>>> no 'chained' certificates would be valid; just like if the >>>>> pathLenConstraint was '1' but the chain being verified has a path >>>>> length of something greater. >>>>> >>>>> I think this question of EE cert vs CA cert as a trust anchor is >>>>> about >>>>> what should happen if the chain being validated consists >> of only the >>>>> trust anchor. Independent of any questions concerning key usage, >>>>> constraints or anything else. >>>>> >>>>> - max >>>>> >>>>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> The text you cite does not apply to trust anchor. >> Please see X.509 >>>>>> and >>>>>> RFC 5280 path validation text. Nothing needs to be >> verified from a >>>>>> trust anchor. >>>>>> >>>>>> -----Original Message----- >>>>>> From: max pritikin [mailto:pritikin@cisco.com] >>>>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>>>> To: Santosh Chokhani >>>>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>>>> Subject: Re: RFC 5280 Question >>>>>> >>>>>> >>>>>> Santosh, >>>>>> >>>>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>>>> The cA boolean indicates whether the certified public key may be >>>>>>> used >>>>>>> to verify certificate signatures. If the cA boolean is not >>>>>>> asserted, >>>>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>>>> asserted. If the basic constraints extension is not >> present in a >>>>>>> version 3 certificate, or the extension is present but the cA >>>>>>> boolean >>>>>>> is not asserted, then the certified public key MUST NOT >> be used to >>>>>>> verify certificate signatures. >>>>>> An EE certificate being in the trust store would not cause >>>>>> confusion >>>>>> about this. >>>>>> >>>>>> - max >>>>>> >>>>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>>>> >>>>>>> Max, >>>>>>> >>>>>>> I do not agree with your point on item 2. Once a >> certificate is a >>>>>>> trust >>>>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>>>> being a >>>>>>> issuer. >>>>>>> >>>>>>> Furthermore, path length constraint if present in the >> self-signed >>>>>>> certificate can be ignored by relying parties. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: owner-ietf-pkix@mail.imc.org >>>>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>>>> ] >>>>>>> On Behalf Of max pritikin >>>>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>>>> To: Tim Polk >>>>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>>>> Subject: Re: RFC 5280 Question >>>>>>> >>>>>>> >>>>>>> >>>>>>> A few comments on this thread: >>>>>>> >>>>>>> 1) Any entry in the trust anchor store would seem to be >> "directly >>>>>>> trusted". If so an additional flag isn't needed so much as a >>>>>>> statement >>>>>>> about how path validation proceeds if, during path discovery, it >>>>>>> turns >>>>>>> out the certificate being validated is already directly trusted. >>>>>>> >>>>>>> 2) Inclusion into the trust anchor store doesn't imply that a >>>>>>> cert >>>>>>> is >>>>>>> trusted to issue certificates -- that is directly >> controlled by >>>>>>> the >>>>>>> values within the certificate (chain). >>>>>>> >>>>>>> 3) The out-of-band mechanism is out of scope for >> 5280/3280 but has >>>>>>> been the subject of recent BoF work (and more?). It >> would nice if >>>>>>> that >>>>>>> work also addressed this question. >>>>>>> >>>>>>> Issues related to this come up on a regular basis. Look at the >>>>>>> various >>>>>>> ways browser deal with caching EE certificates to >> "trust this site >>>>>>> always" etc. I think Bob has raised a good point. >>>>>>> >>>>>>> - max >>>>>>> >>>>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>>>> >>>>>>>> Bob, >>>>>>>> >>>>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>>>> Wen- >>>>>>>> Chen Wang have already provided a lot of good feedback. I >>>>>>>> decided >>>>>>>> to respond to the original message because I would like to go >>>>>>>> back >>>>>>>> to the perceived requirement.] >>>>>>>> >>>>>>>> It sounds like you want to construct a list of >> directly trusted >>>>>>>> EE >>>>>>>> certificates, but are trying to satisfy this >> requirement using >>>>>>>> the >>>>>>>> application's trust anchor store. There is nothing inherently >>>>>>>> wrong >>>>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>>>> trusting >>>>>>>> an EE certificate), but you really need a different - and far >>>>>>>> simpler - mechanism. The trust anchor store is >> implicitly linked >>>>>>>> to >>>>>>>> path discovery and validation, which are not relevant here >>>>>>>> since a >>>>>>>> directly trusted certificate cannot be validated. With a >>>>>>>> directly >>>>>>>> trusted certificate, there is also no mechanism to validate >>>>>>>> status >>>>>>>> information. >>>>>>>> >>>>>>>> To further complicate matters, storing the certificate >> you wish >>>>>>>> to >>>>>>>> directly trust in the trust anchor store implies that it is >>>>>>>> trusted >>>>>>>> to issue certificates as well. The path validation inputs >>>>>>>> specified >>>>>>>> in 6.1.1 (d) consider only four aspects of a trust >> anchor (name, >>>>>>>> public key algorithm, public key, and parameters if >> needed). The >>>>>>>> assumption is that the trust anchor's authority to issue >>>>>>>> certificates was verified based on an out-of-band >> trust mechanism >>>>>>>> (which is out of scope for 5280). This makes sense >> since a trust >>>>>>>> anchor might have distributed a v1 certificate (which does not >>>>>>>> include extensions). >>>>>>>> >>>>>>>> As others have noted, direct trust also implies an out-of-band >>>>>>>> trust >>>>>>>> mechanism. I received the EE certificate from a trusted source >>>>>>>> so I >>>>>>>> can trust the binding between the subject name and the key; >>>>>>>> issuer >>>>>>>> name and the signature are irrelevant. If the certificate >>>>>>>> status >>>>>>>> matters, I am also depending on an out-of-band mechanism to >>>>>>>> inform >>>>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>>>> local storage provide the basis for security in this system... >>>>>>>> >>>>>>>> Trying to combine these two mechanisms using a single >> certificate >>>>>>>> store probably requires an additional flag on every entry to >>>>>>>> differentiate between directly trusted certificates and trust >>>>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Tim Polk >>>>>>>> >>>>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>>>> >>>>>>>>> Folks- >>>>>>>>> >>>>>>>>> I am hoping someone can give me the answer to this. Does RFC >>>>>>>>> 5280 >>>>>>>>> adress the case where an end-entity certificate (not >> a CA cert) >>>>>>>>> is >>>>>>>>> installed in the trust anchor list by the user accepting the >>>>>>>>> presented cert as authoritative and then the cert is >>>>>>>>> subsequently >>>>>>>>> presented (in a later access to the site). There should be no >>>>>>>>> path >>>>>>>>> search, since the presented cert is in the trust >> anchor list. >>>>>>>>> So, >>>>>>>>> where is it defined to accept the end-entity cert? >>>>>>>>> >>>>>>>>> Thanks ---- Bob >>>>>>>>> >>>>>>>>> Bob Bell >>>>>>>>> Cisco Systems, Inc. >>>>>>>>> 576 S. Brentwood Ln. >>>>>>>>> Bountiful, UT 84010 >>>>>>>>> 801-294-3034 (v) >>>>>>>>> 801-294-3023 (f) >>>>>>>>> 801-971-4200 (c) >>>>>>>>> rtbell@cisco.com >>>>>>>>> >> Received: from [200.72.199.93] ([200.72.199.148]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5D4dspZ059293 for ; Thu, 12 Jun 2008 21:40:03 -0700 (MST) (envelope-from raffaele-pranzano@Rientjes.Nl) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_cohEfOQKZUJat7vtQuUKQB)" Message-id: From: raffaele To: ietf-pkix-archive@imc.org Subject: Slim and trim with us Date: Fri, 13 Jun 2008 00:39:59 +0200 X-Mailer: Apple Mail (2.924) --Boundary_(ID_cohEfOQKZUJat7vtQuUKQB) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT My granddad is immobile and this is a great way to get his medical supplies http://www.tryoklate.com/ --Boundary_(ID_cohEfOQKZUJat7vtQuUKQB) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT My granddad is immobile and this is a great way to get his medical supplies --Boundary_(ID_cohEfOQKZUJat7vtQuUKQB)-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5D2KvLe032541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 19:20:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5D2KvWo032540; Thu, 12 Jun 2008 19:20:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5D2KtS1032517 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Thu, 12 Jun 2008 19:20:56 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,635,1204531200"; d="p7s'?scan'208";a="112674539" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2008 19:20:55 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5D2KtWH032647; Thu, 12 Jun 2008 19:20:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5D2KsNr000755; Fri, 13 Jun 2008 02:20:55 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 19:20:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Thu, 12 Jun 2008 19:20:51 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0153_01C8CCC9.CF04CBF0" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjM4R2FGr+XJh/aR3icrE8p2IycgQACdOqgAAQzQhA= References: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , "Max Pritikin (pritikin)" Cc: "Tim Polk" , X-OriginalArrivalTime: 13 Jun 2008 02:20:54.0789 (UTC) FILETIME=[1BA82B50:01C8CCFC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17571; t=1213323655; x=1214187655; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=szJwRVVOmyAphJWUB3VyvqTiOoWK7USmixJBG8TJHpY=; b=khO0HK6811HW1DNlAkI2nKuyCV1T42YDsBRH+K9e5XK2AdyFjAsfAnUpLn RaeL9y3HXDFGtIlZ0vtYtHdE4blvOfqMv2mHIQg2CWwzS05lb3/Wfx0PtE3T Q6uNtJlaAYRgD3FAdE5bzH8+hzm0RrH6naU/i7p+sN7ADRwb74bKM=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0153_01C8CCC9.CF04CBF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - I would recommend that the definition be broadened slightly to indicate that regardless of whether basic constraints are present (as long as the CA bit is false or non-existent), and that the keyCertSign bit is false. This, at least as I read the definitions, defines the cert as an end-entity cert. That kind of a cert in the trust store is what is causing problems for me. Bob > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani > Sent: Thursday, 12 June, 2008 18:21 > To: Max Pritikin (pritikin) > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > > Max, > > So, are you saying that you wanted to explore the implication > of a self-signed certificate that does not have basic > constraints extension in it and does not set keyCertSign bit > in the key usage? I ask because that is the certificate Bob sent me. > > Please provide a clear, concise and complete description of > your issues so that we have the same point of reference for > discussions. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Thursday, June 12, 2008 7:07 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > I think Bob's question touched on an important issue. The > inclusion of > self-signed or EE certificates into the certificate store. > > For an example one should experiment with how the various major web > browsers handle "trust this certificate" (sometimes called > "trust this > web page" etc). They all do it differently. > > - max > > On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: > > > > > Max, > > > > I do not understand from your posting what the specific concern or > > issue > > you want to bring to the attention of PKIX. > > > > We have had lot of digressions on this topic. > > > > Please restate what your concerns are. > > > > -----Original Message----- > > From: max pritikin [mailto:pritikin@cisco.com] > > Sent: Tuesday, June 10, 2008 11:11 PM > > To: Santosh Chokhani > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > Subject: Re: RFC 5280 Question > > > > > > I'm not sure what Bob's goals are, perhaps just to ask the question. > > We don't work very closely together. > > > > This just struck a note with me because I've seen it raised as a > > problem in other cases as well. > > > > - max > > > > On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > > >> > >> Max, > >> > >> I am just responding to inaccuracies in what you are saying. > >> > >> Can you and Bob tell me why you started this thread and > what you are > >> seeking from the PKIX community? > >> > >> I for sure am clueless except for pointing out inaccuracies in your > >> assertions and/or conclusions. > >> > >> -----Original Message----- > >> From: max pritikin [mailto:pritikin@cisco.com] > >> Sent: Tuesday, June 10, 2008 6:51 PM > >> To: Santosh Chokhani > >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >> Subject: Re: RFC 5280 Question > >> > >> > >> Santosh, you've moved the conversation back to a discussion of item > >> (3) in my comments below: out-of-scope population of the trust > >> anchors. I think this is orthogonal to a discussion of dealing with > >> trust-anchors that exactly match a single certificate being > >> validated. > >> > >> - max > >> > >> > >> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > >> > >>> > >>> Max, > >>> > >>> I do not have any problem with successfully verifying > signature made > >>> by > >>> a trust anchor. > >>> > >>> As I said a day or two back in this chain, if the relying > party who > >>> installs the certificate as a trust anchor and does not make > >>> additional > >>> checks of basic constraints, is susceptible to undetected > compromise > >>> of > >>> this end entity certificate spawning an entire PKI hierarchy. > >>> > >>> -----Original Message----- > >>> From: max pritikin [mailto:pritikin@cisco.com] > >>> Sent: Tuesday, June 10, 2008 6:17 PM > >>> To: Santosh Chokhani > >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >>> Subject: Re: RFC 5280 Question > >>> > >>> > >>> We're into the realm of discussing _how_ one would modify > >>> Certificate > >>> Path Validation to support EE certificates as a trust > anchor where > >>> my > >>> intention was only to support the concept as a discussion point. > >>> > >>> Santosh, it isn't that the constraints/extensions are > ever applied > >>> to > >>> the trust anchor credential itself. It is that they are > applied when > >>> validating the chain. Take for example Name Constraints or Policy > >>> Constraints or other Basic Constraints fields such as > >>> pathLenConstraint which are all in the trust anchor > certificate and > >>> then taken into account when validating a certificate > chain. If the > >>> trust anchor certificate does not have keyCertSign set then > >>> logically > >>> no 'chained' certificates would be valid; just like if the > >>> pathLenConstraint was '1' but the chain being verified has a path > >>> length of something greater. > >>> > >>> I think this question of EE cert vs CA cert as a trust anchor is > >>> about > >>> what should happen if the chain being validated consists > of only the > >>> trust anchor. Independent of any questions concerning key usage, > >>> constraints or anything else. > >>> > >>> - max > >>> > >>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > >>> > >>>> > >>>> Max, > >>>> > >>>> The text you cite does not apply to trust anchor. > Please see X.509 > >>>> and > >>>> RFC 5280 path validation text. Nothing needs to be > verified from a > >>>> trust anchor. > >>>> > >>>> -----Original Message----- > >>>> From: max pritikin [mailto:pritikin@cisco.com] > >>>> Sent: Tuesday, June 10, 2008 4:47 PM > >>>> To: Santosh Chokhani > >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >>>> Subject: Re: RFC 5280 Question > >>>> > >>>> > >>>> Santosh, > >>>> > >>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: > >>>>> The cA boolean indicates whether the certified public key may be > >>>>> used > >>>>> to verify certificate signatures. If the cA boolean is not > >>>>> asserted, > >>>>> then the keyCertSign bit in the key usage extension MUST NOT be > >>>>> asserted. If the basic constraints extension is not > present in a > >>>>> version 3 certificate, or the extension is present but the cA > >>>>> boolean > >>>>> is not asserted, then the certified public key MUST NOT > be used to > >>>>> verify certificate signatures. > >>>> > >>>> An EE certificate being in the trust store would not cause > >>>> confusion > >>>> about this. > >>>> > >>>> - max > >>>> > >>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > >>>> > >>>>> Max, > >>>>> > >>>>> I do not agree with your point on item 2. Once a > certificate is a > >>>>> trust > >>>>> anchor, neither X.509 not 5280 have any constraints on it from > >>>>> being a > >>>>> issuer. > >>>>> > >>>>> Furthermore, path length constraint if present in the > self-signed > >>>>> certificate can be ignored by relying parties. > >>>>> > >>>>> -----Original Message----- > >>>>> From: owner-ietf-pkix@mail.imc.org > >>>> [mailto:owner-ietf-pkix@mail.imc.org > >>>>> ] > >>>>> On Behalf Of max pritikin > >>>>> Sent: Tuesday, June 10, 2008 2:35 PM > >>>>> To: Tim Polk > >>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org > >>>>> Subject: Re: RFC 5280 Question > >>>>> > >>>>> > >>>>> > >>>>> A few comments on this thread: > >>>>> > >>>>> 1) Any entry in the trust anchor store would seem to be > "directly > >>>>> trusted". If so an additional flag isn't needed so much as a > >>>>> statement > >>>>> about how path validation proceeds if, during path discovery, it > >>>>> turns > >>>>> out the certificate being validated is already directly trusted. > >>>>> > >>>>> 2) Inclusion into the trust anchor store doesn't imply that a > >>>>> cert > >>>>> is > >>>>> trusted to issue certificates -- that is directly > controlled by > >>>>> the > >>>>> values within the certificate (chain). > >>>>> > >>>>> 3) The out-of-band mechanism is out of scope for > 5280/3280 but has > >>>>> been the subject of recent BoF work (and more?). It > would nice if > >>>>> that > >>>>> work also addressed this question. > >>>>> > >>>>> Issues related to this come up on a regular basis. Look at the > >>>>> various > >>>>> ways browser deal with caching EE certificates to > "trust this site > >>>>> always" etc. I think Bob has raised a good point. > >>>>> > >>>>> - max > >>>>> > >>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > >>>>> > >>>>>> > >>>>>> Bob, > >>>>>> > >>>>>> [I realize I am late to the party, and that Santosh, Steve, and > >>>>>> Wen- > >>>>>> Chen Wang have already provided a lot of good feedback. I > >>>>>> decided > >>>>>> to respond to the original message because I would like to go > >>>>>> back > >>>>>> to the perceived requirement.] > >>>>>> > >>>>>> It sounds like you want to construct a list of > directly trusted > >>>>>> EE > >>>>>> certificates, but are trying to satisfy this > requirement using > >>>>>> the > >>>>>> application's trust anchor store. There is nothing inherently > >>>>>> wrong > >>>>>> with direct trust (and RFC 5280 does not preclude directly > >>>>>> trusting > >>>>>> an EE certificate), but you really need a different - and far > >>>>>> simpler - mechanism. The trust anchor store is > implicitly linked > >>>>>> to > >>>>>> path discovery and validation, which are not relevant here > >>>>>> since a > >>>>>> directly trusted certificate cannot be validated. With a > >>>>>> directly > >>>>>> trusted certificate, there is also no mechanism to validate > >>>>>> status > >>>>>> information. > >>>>>> > >>>>>> To further complicate matters, storing the certificate > you wish > >>>>>> to > >>>>>> directly trust in the trust anchor store implies that it is > >>>>>> trusted > >>>>>> to issue certificates as well. The path validation inputs > >>>>>> specified > >>>>>> in 6.1.1 (d) consider only four aspects of a trust > anchor (name, > >>>>>> public key algorithm, public key, and parameters if > needed). The > >>>>>> assumption is that the trust anchor's authority to issue > >>>>>> certificates was verified based on an out-of-band > trust mechanism > >>>>>> (which is out of scope for 5280). This makes sense > since a trust > >>>>>> anchor might have distributed a v1 certificate (which does not > >>>>>> include extensions). > >>>>>> > >>>>>> As others have noted, direct trust also implies an out-of-band > >>>>>> trust > >>>>>> mechanism. I received the EE certificate from a trusted source > >>>>>> so I > >>>>>> can trust the binding between the subject name and the key; > >>>>>> issuer > >>>>>> name and the signature are irrelevant. If the certificate > >>>>>> status > >>>>>> matters, I am also depending on an out-of-band mechanism to > >>>>>> inform > >>>>>> me! The out-of-band mechanism(s) in combination with protected > >>>>>> local storage provide the basis for security in this system... > >>>>>> > >>>>>> Trying to combine these two mechanisms using a single > certificate > >>>>>> store probably requires an additional flag on every entry to > >>>>>> differentiate between directly trusted certificates and trust > >>>>>> anchors. Two separate stores might be cleaner in the long run. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Tim Polk > >>>>>> > >>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > >>>>>> > >>>>>>> Folks- > >>>>>>> > >>>>>>> I am hoping someone can give me the answer to this. Does RFC > >>>>>>> 5280 > >>>>>>> adress the case where an end-entity certificate (not > a CA cert) > >>>>>>> is > >>>>>>> installed in the trust anchor list by the user accepting the > >>>>>>> presented cert as authoritative and then the cert is > >>>>>>> subsequently > >>>>>>> presented (in a later access to the site). There should be no > >>>>>>> path > >>>>>>> search, since the presented cert is in the trust > anchor list. > >>>>>>> So, > >>>>>>> where is it defined to accept the end-entity cert? > >>>>>>> > >>>>>>> Thanks ---- Bob > >>>>>>> > >>>>>>> Bob Bell > >>>>>>> Cisco Systems, Inc. > >>>>>>> 576 S. Brentwood Ln. > >>>>>>> Bountiful, UT 84010 > >>>>>>> 801-294-3034 (v) > >>>>>>> 801-294-3023 (f) > >>>>>>> 801-971-4200 (c) > >>>>>>> rtbell@cisco.com > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > ------=_NextPart_000_0153_01C8CCC9.CF04CBF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTMwMjIwNTFaMCMGCSqGSIb3DQEJBDEWBBRjgVvC+97VhS9qHdoo /Wcumg/mqDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYCspFhnMK6kov9ErpMlQx7a7WoH+b0dF4s/nm20gLdRASpbMgmit4wUeAkV0RZJfCYwXEKU /9f96IvCbFkI4HTMNX655fXWazSVr4iQZiM+b1LMfTtbS+0oZY8pZz5Asub7gM4krxPC9FLXQ06Z zjBUg1jzu8Lv8kCiVmCXhpQ66gAAAAAAAA== ------=_NextPart_000_0153_01C8CCC9.CF04CBF0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5D0LEC7005437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 17:21:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5D0LEFB005436; Thu, 12 Jun 2008 17:21:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5D0LCEh005430 for ; Thu, 12 Jun 2008 17:21:13 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 27632 invoked from network); 13 Jun 2008 00:10:53 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Jun 2008 00:10:53 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Jun 2008 00:10:53 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Thu, 12 Jun 2008 20:21:04 -0400 Message-ID: In-Reply-To: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjM4R2FGr+XJh/aR3icrE8p2IycgQACdOqg References: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> From: "Santosh Chokhani" To: "max pritikin" Cc: "Tim Polk" , "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, So, are you saying that you wanted to explore the implication of a self-signed certificate that does not have basic constraints extension in it and does not set keyCertSign bit in the key usage? I ask because that is the certificate Bob sent me. Please provide a clear, concise and complete description of your issues so that we have the same point of reference for discussions. -----Original Message----- From: max pritikin [mailto:pritikin@cisco.com]=20 Sent: Thursday, June 12, 2008 7:07 PM To: Santosh Chokhani Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org Subject: Re: RFC 5280 Question I think Bob's question touched on an important issue. The inclusion of =20 self-signed or EE certificates into the certificate store. For an example one should experiment with how the various major web =20 browsers handle "trust this certificate" (sometimes called "trust this =20 web page" etc). They all do it differently. - max On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: > > Max, > > I do not understand from your posting what the specific concern or =20 > issue > you want to bring to the attention of PKIX. > > We have had lot of digressions on this topic. > > Please restate what your concerns are. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 11:11 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > I'm not sure what Bob's goals are, perhaps just to ask the question. > We don't work very closely together. > > This just struck a note with me because I've seen it raised as a > problem in other cases as well. > > - max > > On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > >> >> Max, >> >> I am just responding to inaccuracies in what you are saying. >> >> Can you and Bob tell me why you started this thread and what you are >> seeking from the PKIX community? >> >> I for sure am clueless except for pointing out inaccuracies in your >> assertions and/or conclusions. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 6:51 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> Santosh, you've moved the conversation back to a discussion of item >> (3) in my comments below: out-of-scope population of the trust >> anchors. I think this is orthogonal to a discussion of dealing with >> trust-anchors that exactly match a single certificate being =20 >> validated. >> >> - max >> >> >> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >> >>> >>> Max, >>> >>> I do not have any problem with successfully verifying signature made >>> by >>> a trust anchor. >>> >>> As I said a day or two back in this chain, if the relying party who >>> installs the certificate as a trust anchor and does not make >>> additional >>> checks of basic constraints, is susceptible to undetected compromise >>> of >>> this end entity certificate spawning an entire PKI hierarchy. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 6:17 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> We're into the realm of discussing _how_ one would modify =20 >>> Certificate >>> Path Validation to support EE certificates as a trust anchor where =20 >>> my >>> intention was only to support the concept as a discussion point. >>> >>> Santosh, it isn't that the constraints/extensions are ever applied =20 >>> to >>> the trust anchor credential itself. It is that they are applied when >>> validating the chain. Take for example Name Constraints or Policy >>> Constraints or other Basic Constraints fields such as >>> pathLenConstraint which are all in the trust anchor certificate and >>> then taken into account when validating a certificate chain. If the >>> trust anchor certificate does not have keyCertSign set then =20 >>> logically >>> no 'chained' certificates would be valid; just like if the >>> pathLenConstraint was '1' but the chain being verified has a path >>> length of something greater. >>> >>> I think this question of EE cert vs CA cert as a trust anchor is >>> about >>> what should happen if the chain being validated consists of only the >>> trust anchor. Independent of any questions concerning key usage, >>> constraints or anything else. >>> >>> - max >>> >>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>> >>>> >>>> Max, >>>> >>>> The text you cite does not apply to trust anchor. Please see X.509 >>>> and >>>> RFC 5280 path validation text. Nothing needs to be verified from a >>>> trust anchor. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> Santosh, >>>> >>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>> The cA boolean indicates whether the certified public key may be >>>>> used >>>>> to verify certificate signatures. If the cA boolean is not >>>>> asserted, >>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>> asserted. If the basic constraints extension is not present in a >>>>> version 3 certificate, or the extension is present but the cA >>>>> boolean >>>>> is not asserted, then the certified public key MUST NOT be used to >>>>> verify certificate signatures. >>>> >>>> An EE certificate being in the trust store would not cause =20 >>>> confusion >>>> about this. >>>> >>>> - max >>>> >>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I do not agree with your point on item 2. Once a certificate is a >>>>> trust >>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>> being a >>>>> issuer. >>>>> >>>>> Furthermore, path length constraint if present in the self-signed >>>>> certificate can be ignored by relying parties. >>>>> >>>>> -----Original Message----- >>>>> From: owner-ietf-pkix@mail.imc.org >>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>> ] >>>>> On Behalf Of max pritikin >>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>> To: Tim Polk >>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> >>>>> A few comments on this thread: >>>>> >>>>> 1) Any entry in the trust anchor store would seem to be "directly >>>>> trusted". If so an additional flag isn't needed so much as a >>>>> statement >>>>> about how path validation proceeds if, during path discovery, it >>>>> turns >>>>> out the certificate being validated is already directly trusted. >>>>> >>>>> 2) Inclusion into the trust anchor store doesn't imply that a =20 >>>>> cert >>>>> is >>>>> trusted to issue certificates -- that is directly controlled by =20 >>>>> the >>>>> values within the certificate (chain). >>>>> >>>>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>>>> been the subject of recent BoF work (and more?). It would nice if >>>>> that >>>>> work also addressed this question. >>>>> >>>>> Issues related to this come up on a regular basis. Look at the >>>>> various >>>>> ways browser deal with caching EE certificates to "trust this site >>>>> always" etc. I think Bob has raised a good point. >>>>> >>>>> - max >>>>> >>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>> >>>>>> >>>>>> Bob, >>>>>> >>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>> Wen- >>>>>> Chen Wang have already provided a lot of good feedback. I =20 >>>>>> decided >>>>>> to respond to the original message because I would like to go =20 >>>>>> back >>>>>> to the perceived requirement.] >>>>>> >>>>>> It sounds like you want to construct a list of directly trusted =20 >>>>>> EE >>>>>> certificates, but are trying to satisfy this requirement using =20 >>>>>> the >>>>>> application's trust anchor store. There is nothing inherently >>>>>> wrong >>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>> trusting >>>>>> an EE certificate), but you really need a different - and far >>>>>> simpler - mechanism. The trust anchor store is implicitly linked >>>>>> to >>>>>> path discovery and validation, which are not relevant here =20 >>>>>> since a >>>>>> directly trusted certificate cannot be validated. With a =20 >>>>>> directly >>>>>> trusted certificate, there is also no mechanism to validate =20 >>>>>> status >>>>>> information. >>>>>> >>>>>> To further complicate matters, storing the certificate you wish =20 >>>>>> to >>>>>> directly trust in the trust anchor store implies that it is >>>>>> trusted >>>>>> to issue certificates as well. The path validation inputs >>>>>> specified >>>>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>>>> public key algorithm, public key, and parameters if needed). The >>>>>> assumption is that the trust anchor's authority to issue >>>>>> certificates was verified based on an out-of-band trust mechanism >>>>>> (which is out of scope for 5280). This makes sense since a trust >>>>>> anchor might have distributed a v1 certificate (which does not >>>>>> include extensions). >>>>>> >>>>>> As others have noted, direct trust also implies an out-of-band >>>>>> trust >>>>>> mechanism. I received the EE certificate from a trusted source >>>>>> so I >>>>>> can trust the binding between the subject name and the key; =20 >>>>>> issuer >>>>>> name and the signature are irrelevant. If the certificate =20 >>>>>> status >>>>>> matters, I am also depending on an out-of-band mechanism to =20 >>>>>> inform >>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>> local storage provide the basis for security in this system... >>>>>> >>>>>> Trying to combine these two mechanisms using a single certificate >>>>>> store probably requires an additional flag on every entry to >>>>>> differentiate between directly trusted certificates and trust >>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Tim Polk >>>>>> >>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>> >>>>>>> Folks- >>>>>>> >>>>>>> I am hoping someone can give me the answer to this. Does RFC =20 >>>>>>> 5280 >>>>>>> adress the case where an end-entity certificate (not a CA cert) >>>>>>> is >>>>>>> installed in the trust anchor list by the user accepting the >>>>>>> presented cert as authoritative and then the cert is =20 >>>>>>> subsequently >>>>>>> presented (in a later access to the site). There should be no >>>>>>> path >>>>>>> search, since the presented cert is in the trust anchor list. =20 >>>>>>> So, >>>>>>> where is it defined to accept the end-entity cert? >>>>>>> >>>>>>> Thanks ---- Bob >>>>>>> >>>>>>> Bob Bell >>>>>>> Cisco Systems, Inc. >>>>>>> 576 S. Brentwood Ln. >>>>>>> Bountiful, UT 84010 >>>>>>> 801-294-3034 (v) >>>>>>> 801-294-3023 (f) >>>>>>> 801-971-4200 (c) >>>>>>> rtbell@cisco.com >>>>>>> >>>>>> >>>>> >>>> >>> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CN7cde091010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 16:07:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5CN7cvt091009; Thu, 12 Jun 2008 16:07:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CN7Y9U090982 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Thu, 12 Jun 2008 16:07:35 -0700 (MST) (envelope-from pritikin@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,633,1204531200"; d="scan'208";a="112602745" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2008 16:07:33 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5CN7Xev005638; Thu, 12 Jun 2008 16:07:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5CN7XTs001731; Thu, 12 Jun 2008 23:07:33 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 16:07:33 -0700 Received: from [192.168.2.16] ([10.21.113.98]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 16:07:32 -0700 Cc: "Tim Polk" , "Bob Bell (rtbell)" , Message-Id: <56A509F6-C6B8-45B4-B4B8-0BB6B26A97C2@cisco.com> From: max pritikin To: "Santosh Chokhani" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Thu, 12 Jun 2008 18:07:28 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 12 Jun 2008 23:07:33.0022 (UTC) FILETIME=[187703E0:01C8CCE1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10798; t=1213312053; x=1214176053; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20RFC=205280=20Question |Sender:=20; bh=pL6dCr7Hk43dQ+HQ8B0SNt/7N6SF+eXmu36Csx430jI=; b=dR5maqwWXJzD//UiImW5azUsdjo/9Ug1231Lxqugq8iXDW2UvnC6utAvQI zeQSXQwhc9y46fKFlIuW/sT6+b3CuAm9jlLSwRf4Zd5g/sfPxjgSdkYeFt8v c9u9O1P1Ce; Authentication-Results: sj-dkim-2; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think Bob's question touched on an important issue. The inclusion of self-signed or EE certificates into the certificate store. For an example one should experiment with how the various major web browsers handle "trust this certificate" (sometimes called "trust this web page" etc). They all do it differently. - max On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote: > > Max, > > I do not understand from your posting what the specific concern or > issue > you want to bring to the attention of PKIX. > > We have had lot of digressions on this topic. > > Please restate what your concerns are. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 11:11 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > I'm not sure what Bob's goals are, perhaps just to ask the question. > We don't work very closely together. > > This just struck a note with me because I've seen it raised as a > problem in other cases as well. > > - max > > On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > >> >> Max, >> >> I am just responding to inaccuracies in what you are saying. >> >> Can you and Bob tell me why you started this thread and what you are >> seeking from the PKIX community? >> >> I for sure am clueless except for pointing out inaccuracies in your >> assertions and/or conclusions. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 6:51 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> Santosh, you've moved the conversation back to a discussion of item >> (3) in my comments below: out-of-scope population of the trust >> anchors. I think this is orthogonal to a discussion of dealing with >> trust-anchors that exactly match a single certificate being >> validated. >> >> - max >> >> >> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: >> >>> >>> Max, >>> >>> I do not have any problem with successfully verifying signature made >>> by >>> a trust anchor. >>> >>> As I said a day or two back in this chain, if the relying party who >>> installs the certificate as a trust anchor and does not make >>> additional >>> checks of basic constraints, is susceptible to undetected compromise >>> of >>> this end entity certificate spawning an entire PKI hierarchy. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 6:17 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> We're into the realm of discussing _how_ one would modify >>> Certificate >>> Path Validation to support EE certificates as a trust anchor where >>> my >>> intention was only to support the concept as a discussion point. >>> >>> Santosh, it isn't that the constraints/extensions are ever applied >>> to >>> the trust anchor credential itself. It is that they are applied when >>> validating the chain. Take for example Name Constraints or Policy >>> Constraints or other Basic Constraints fields such as >>> pathLenConstraint which are all in the trust anchor certificate and >>> then taken into account when validating a certificate chain. If the >>> trust anchor certificate does not have keyCertSign set then >>> logically >>> no 'chained' certificates would be valid; just like if the >>> pathLenConstraint was '1' but the chain being verified has a path >>> length of something greater. >>> >>> I think this question of EE cert vs CA cert as a trust anchor is >>> about >>> what should happen if the chain being validated consists of only the >>> trust anchor. Independent of any questions concerning key usage, >>> constraints or anything else. >>> >>> - max >>> >>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >>> >>>> >>>> Max, >>>> >>>> The text you cite does not apply to trust anchor. Please see X.509 >>>> and >>>> RFC 5280 path validation text. Nothing needs to be verified from a >>>> trust anchor. >>>> >>>> -----Original Message----- >>>> From: max pritikin [mailto:pritikin@cisco.com] >>>> Sent: Tuesday, June 10, 2008 4:47 PM >>>> To: Santosh Chokhani >>>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> Santosh, >>>> >>>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>>> The cA boolean indicates whether the certified public key may be >>>>> used >>>>> to verify certificate signatures. If the cA boolean is not >>>>> asserted, >>>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>>> asserted. If the basic constraints extension is not present in a >>>>> version 3 certificate, or the extension is present but the cA >>>>> boolean >>>>> is not asserted, then the certified public key MUST NOT be used to >>>>> verify certificate signatures. >>>> >>>> An EE certificate being in the trust store would not cause >>>> confusion >>>> about this. >>>> >>>> - max >>>> >>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>>> >>>>> Max, >>>>> >>>>> I do not agree with your point on item 2. Once a certificate is a >>>>> trust >>>>> anchor, neither X.509 not 5280 have any constraints on it from >>>>> being a >>>>> issuer. >>>>> >>>>> Furthermore, path length constraint if present in the self-signed >>>>> certificate can be ignored by relying parties. >>>>> >>>>> -----Original Message----- >>>>> From: owner-ietf-pkix@mail.imc.org >>>> [mailto:owner-ietf-pkix@mail.imc.org >>>>> ] >>>>> On Behalf Of max pritikin >>>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>>> To: Tim Polk >>>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>>> Subject: Re: RFC 5280 Question >>>>> >>>>> >>>>> >>>>> A few comments on this thread: >>>>> >>>>> 1) Any entry in the trust anchor store would seem to be "directly >>>>> trusted". If so an additional flag isn't needed so much as a >>>>> statement >>>>> about how path validation proceeds if, during path discovery, it >>>>> turns >>>>> out the certificate being validated is already directly trusted. >>>>> >>>>> 2) Inclusion into the trust anchor store doesn't imply that a >>>>> cert >>>>> is >>>>> trusted to issue certificates -- that is directly controlled by >>>>> the >>>>> values within the certificate (chain). >>>>> >>>>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>>>> been the subject of recent BoF work (and more?). It would nice if >>>>> that >>>>> work also addressed this question. >>>>> >>>>> Issues related to this come up on a regular basis. Look at the >>>>> various >>>>> ways browser deal with caching EE certificates to "trust this site >>>>> always" etc. I think Bob has raised a good point. >>>>> >>>>> - max >>>>> >>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>>> >>>>>> >>>>>> Bob, >>>>>> >>>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>>> Wen- >>>>>> Chen Wang have already provided a lot of good feedback. I >>>>>> decided >>>>>> to respond to the original message because I would like to go >>>>>> back >>>>>> to the perceived requirement.] >>>>>> >>>>>> It sounds like you want to construct a list of directly trusted >>>>>> EE >>>>>> certificates, but are trying to satisfy this requirement using >>>>>> the >>>>>> application's trust anchor store. There is nothing inherently >>>>>> wrong >>>>>> with direct trust (and RFC 5280 does not preclude directly >>>>>> trusting >>>>>> an EE certificate), but you really need a different - and far >>>>>> simpler - mechanism. The trust anchor store is implicitly linked >>>>>> to >>>>>> path discovery and validation, which are not relevant here >>>>>> since a >>>>>> directly trusted certificate cannot be validated. With a >>>>>> directly >>>>>> trusted certificate, there is also no mechanism to validate >>>>>> status >>>>>> information. >>>>>> >>>>>> To further complicate matters, storing the certificate you wish >>>>>> to >>>>>> directly trust in the trust anchor store implies that it is >>>>>> trusted >>>>>> to issue certificates as well. The path validation inputs >>>>>> specified >>>>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>>>> public key algorithm, public key, and parameters if needed). The >>>>>> assumption is that the trust anchor's authority to issue >>>>>> certificates was verified based on an out-of-band trust mechanism >>>>>> (which is out of scope for 5280). This makes sense since a trust >>>>>> anchor might have distributed a v1 certificate (which does not >>>>>> include extensions). >>>>>> >>>>>> As others have noted, direct trust also implies an out-of-band >>>>>> trust >>>>>> mechanism. I received the EE certificate from a trusted source >>>>>> so I >>>>>> can trust the binding between the subject name and the key; >>>>>> issuer >>>>>> name and the signature are irrelevant. If the certificate >>>>>> status >>>>>> matters, I am also depending on an out-of-band mechanism to >>>>>> inform >>>>>> me! The out-of-band mechanism(s) in combination with protected >>>>>> local storage provide the basis for security in this system... >>>>>> >>>>>> Trying to combine these two mechanisms using a single certificate >>>>>> store probably requires an additional flag on every entry to >>>>>> differentiate between directly trusted certificates and trust >>>>>> anchors. Two separate stores might be cleaner in the long run. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Tim Polk >>>>>> >>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>>> >>>>>>> Folks- >>>>>>> >>>>>>> I am hoping someone can give me the answer to this. Does RFC >>>>>>> 5280 >>>>>>> adress the case where an end-entity certificate (not a CA cert) >>>>>>> is >>>>>>> installed in the trust anchor list by the user accepting the >>>>>>> presented cert as authoritative and then the cert is >>>>>>> subsequently >>>>>>> presented (in a later access to the site). There should be no >>>>>>> path >>>>>>> search, since the presented cert is in the trust anchor list. >>>>>>> So, >>>>>>> where is it defined to accept the end-entity cert? >>>>>>> >>>>>>> Thanks ---- Bob >>>>>>> >>>>>>> Bob Bell >>>>>>> Cisco Systems, Inc. >>>>>>> 576 S. Brentwood Ln. >>>>>>> Bountiful, UT 84010 >>>>>>> 801-294-3034 (v) >>>>>>> 801-294-3023 (f) >>>>>>> 801-971-4200 (c) >>>>>>> rtbell@cisco.com >>>>>>> >>>>>> >>>>> >>>> >>> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CI1oI8030314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 11:01:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5CI1od0030312; Thu, 12 Jun 2008 11:01:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CI1mBw030284 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Thu, 12 Jun 2008 11:01:49 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,632,1204531200"; d="p7s'?scan'208";a="40894283" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 12 Jun 2008 11:01:47 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5CI1lbA021179; Thu, 12 Jun 2008 11:01:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5CI1llO028246; Thu, 12 Jun 2008 18:01:47 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 11:01:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Thu, 12 Jun 2008 11:01:44 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D8_01C8CC84.14EFAC20" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjMtWQlJr5jW+zJSKKZO5AdcKzRYAAAK5jA References: From: "Bob Bell (rtbell)" To: "Timothy J Miller" , "Santosh Chokhani" Cc: "Max Pritikin (pritikin)" , "Tim Polk" , X-OriginalArrivalTime: 12 Jun 2008 18:01:47.0551 (UTC) FILETIME=[61B64AF0:01C8CCB6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15454; t=1213293707; x=1214157707; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=knZ5EDrJoSiVuNftbkRfdcVz1P1IgAm0Owmuo19jIzM=; b=j7uWmGhwYNiv/Qy5sKqmGjUN9FuVAOBfZnUgGThiQLNLBku6XyiH8QBw1v L19IYAK5fUcuoOVwrkDlwfl/G2itXs/2eeG8FDwlhnYWYEsc5UMXcsRv9rgt AgtVgIsHHw; Authentication-Results: sj-dkim-2; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00D8_01C8CC84.14EFAC20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Timothy - However, these were implementation issues and not theory issues. It also avoided several vulnerabilities wherein the device is presented with a cert that is signed by a "trusted" CA, but that the cert was infact invalid. Case in point was the issuance to an outside of the Microsoft signing certificate. Bob > -----Original Message----- > From: Timothy J Miller [mailto:tmiller@mitre.org] > Sent: Thursday, 12 June, 2008 11:53 > To: Santosh Chokhani > Cc: Max Pritikin (pritikin); Tim Polk; Bob Bell (rtbell); > ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > Cisco's CallManager does interesting things re: certificates > provisioning and trust lists (google Certificate Authority Proxy > Function [CAPF] and Certificate Trust List Provider [CTL > Provider]). > Coincidentally, both these services had fairly significant > vulnerabilities recently. > > Shall I speculate that the question arises from this? :) > > -- Tim > > > On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > > > > Max, > > > > I am just responding to inaccuracies in what you are saying. > > > > Can you and Bob tell me why you started this thread and > what you are > > seeking from the PKIX community? > > > > I for sure am clueless except for pointing out inaccuracies in your > > assertions and/or conclusions. > > > > -----Original Message----- > > From: max pritikin [mailto:pritikin@cisco.com] > > Sent: Tuesday, June 10, 2008 6:51 PM > > To: Santosh Chokhani > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > Subject: Re: RFC 5280 Question > > > > > > Santosh, you've moved the conversation back to a discussion of item > > (3) in my comments below: out-of-scope population of the trust > > anchors. I think this is orthogonal to a discussion of dealing with > > trust-anchors that exactly match a single certificate being > validated. > > > > - max > > > > > > On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > > > >> > >> Max, > >> > >> I do not have any problem with successfully verifying > signature made > >> by a trust anchor. > >> > >> As I said a day or two back in this chain, if the relying > party who > >> installs the certificate as a trust anchor and does not make > >> additional checks of basic constraints, is susceptible to > undetected > >> compromise of this end entity certificate spawning an entire PKI > >> hierarchy. > >> > >> -----Original Message----- > >> From: max pritikin [mailto:pritikin@cisco.com] > >> Sent: Tuesday, June 10, 2008 6:17 PM > >> To: Santosh Chokhani > >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >> Subject: Re: RFC 5280 Question > >> > >> > >> We're into the realm of discussing _how_ one would modify > Certificate > >> Path Validation to support EE certificates as a trust > anchor where my > >> intention was only to support the concept as a discussion point. > >> > >> Santosh, it isn't that the constraints/extensions are ever > applied to > >> the trust anchor credential itself. It is that they are > applied when > >> validating the chain. Take for example Name Constraints or Policy > >> Constraints or other Basic Constraints fields such as > >> pathLenConstraint which are all in the trust anchor > certificate and > >> then taken into account when validating a certificate > chain. If the > >> trust anchor certificate does not have keyCertSign set > then logically > >> no 'chained' certificates would be valid; just like if the > >> pathLenConstraint was '1' but the chain being verified has a path > >> length of something greater. > >> > >> I think this question of EE cert vs CA cert as a trust anchor is > >> about what should happen if the chain being validated consists of > >> only the trust anchor. Independent of any questions concerning key > >> usage, constraints or anything else. > >> > >> - max > >> > >> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > >> > >>> > >>> Max, > >>> > >>> The text you cite does not apply to trust anchor. Please > see X.509 > >>> and RFC 5280 path validation text. Nothing needs to be verified > >>> from a trust anchor. > >>> > >>> -----Original Message----- > >>> From: max pritikin [mailto:pritikin@cisco.com] > >>> Sent: Tuesday, June 10, 2008 4:47 PM > >>> To: Santosh Chokhani > >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >>> Subject: Re: RFC 5280 Question > >>> > >>> > >>> Santosh, > >>> > >>> RFC5280 section 4.2.1.9 (Basic Constraints) says: > >>>> The cA boolean indicates whether the certified public key may be > >>>> used to verify certificate signatures. If the cA boolean is not > >>>> asserted, then the keyCertSign bit in the key usage > extension MUST > >>>> NOT be asserted. If the basic constraints extension is > not present > >>>> in a version 3 certificate, or the extension is present > but the cA > >>>> boolean is not asserted, then the certified public key > MUST NOT be > >>>> used to verify certificate signatures. > >>> > >>> An EE certificate being in the trust store would not > cause confusion > >>> about this. > >>> > >>> - max > >>> > >>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > >>> > >>>> Max, > >>>> > >>>> I do not agree with your point on item 2. Once a > certificate is a > >>>> trust anchor, neither X.509 not 5280 have any constraints on it > >>>> from being a issuer. > >>>> > >>>> Furthermore, path length constraint if present in the > self-signed > >>>> certificate can be ignored by relying parties. > >>>> > >>>> -----Original Message----- > >>>> From: owner-ietf-pkix@mail.imc.org > >>> [mailto:owner-ietf-pkix@mail.imc.org > >>>> ] > >>>> On Behalf Of max pritikin > >>>> Sent: Tuesday, June 10, 2008 2:35 PM > >>>> To: Tim Polk > >>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org > >>>> Subject: Re: RFC 5280 Question > >>>> > >>>> > >>>> > >>>> A few comments on this thread: > >>>> > >>>> 1) Any entry in the trust anchor store would seem to be > "directly > >>>> trusted". If so an additional flag isn't needed so much as a > >>>> statement about how path validation proceeds if, during path > >>>> discovery, it turns out the certificate being validated > is already > >>>> directly trusted. > >>>> > >>>> 2) Inclusion into the trust anchor store doesn't imply > that a cert > >>>> is trusted to issue certificates -- that is directly > controlled by > >>>> the values within the certificate (chain). > >>>> > >>>> 3) The out-of-band mechanism is out of scope for > 5280/3280 but has > >>>> been the subject of recent BoF work (and more?). It > would nice if > >>>> that work also addressed this question. > >>>> > >>>> Issues related to this come up on a regular basis. Look at the > >>>> various ways browser deal with caching EE certificates to "trust > >>>> this site always" etc. I think Bob has raised a good point. > >>>> > >>>> - max > >>>> > >>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > >>>> > >>>>> > >>>>> Bob, > >>>>> > >>>>> [I realize I am late to the party, and that Santosh, Steve, and > >>>>> Wen- > >>>>> Chen Wang have already provided a lot of good feedback. > I decided > >>>>> to respond to the original message because I would like > to go back > >>>>> to the perceived requirement.] > >>>>> > >>>>> It sounds like you want to construct a list of directly > trusted EE > >>>>> certificates, but are trying to satisfy this > requirement using the > >>>>> application's trust anchor store. There is nothing inherently > >>>>> wrong with direct trust (and RFC 5280 does not preclude > directly > >>>>> trusting an EE certificate), but you really need a > different - and > >>>>> far simpler - mechanism. The trust anchor store is implicitly > >>>>> linked to path discovery and validation, which are not relevant > >>>>> here since a directly trusted certificate cannot be validated. > >>>>> With a directly trusted certificate, there is also no > mechanism to > >>>>> validate status information. > >>>>> > >>>>> To further complicate matters, storing the certificate > you wish to > >>>>> directly trust in the trust anchor store implies that it is > >>>>> trusted to issue certificates as well. The path > validation inputs > >>>>> specified in 6.1.1 (d) consider only four aspects of a trust > >>>>> anchor (name, public key algorithm, public key, and > parameters if > >>>>> needed). The assumption is that the trust anchor's > authority to > >>>>> issue certificates was verified based on an out-of-band trust > >>>>> mechanism (which is out of scope for 5280). This makes sense > >>>>> since a trust anchor might have distributed a v1 certificate > >>>>> (which does not include extensions). > >>>>> > >>>>> As others have noted, direct trust also implies an out-of-band > >>>>> trust mechanism. I received the EE certificate from a trusted > >>>>> source so I can trust the binding between the subject > name and the > >>>>> key; issuer > >>>>> name and the signature are irrelevant. If the > certificate status > >>>>> matters, I am also depending on an out-of-band > mechanism to inform > >>>>> me! The out-of-band mechanism(s) in combination with protected > >>>>> local storage provide the basis for security in this system... > >>>>> > >>>>> Trying to combine these two mechanisms using a single > certificate > >>>>> store probably requires an additional flag on every entry to > >>>>> differentiate between directly trusted certificates and trust > >>>>> anchors. Two separate stores might be cleaner in the long run. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Tim Polk > >>>>> > >>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > >>>>> > >>>>>> Folks- > >>>>>> > >>>>>> I am hoping someone can give me the answer to this. > Does RFC 5280 > >>>>>> adress the case where an end-entity certificate (not a > CA cert) > >>>>>> is installed in the trust anchor list by the user > accepting the > >>>>>> presented cert as authoritative and then the cert is > subsequently > >>>>>> presented (in a later access to the site). There should be no > >>>>>> path search, since the presented cert is in the trust anchor > >>>>>> list. So, where is it defined to accept the end-entity cert? > >>>>>> > >>>>>> Thanks ---- Bob > >>>>>> > >>>>>> Bob Bell > >>>>>> Cisco Systems, Inc. > >>>>>> 576 S. Brentwood Ln. > >>>>>> Bountiful, UT 84010 > >>>>>> 801-294-3034 (v) > >>>>>> 801-294-3023 (f) > >>>>>> 801-971-4200 (c) > >>>>>> rtbell@cisco.com > >>>>>> > >>>>> > >>>> > >>> > >> > > > > ------=_NextPart_000_00D8_01C8CC84.14EFAC20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTIxODAxNDNaMCMGCSqGSIb3DQEJBDEWBBSkAin1WJ/X9b1V8g9e BtUy2F0/xTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYBZkTiGciinF2ea4d+Z0FHJ5AwmdIfwbMd9fDqAzeEhIZRuQCq13bTansSAIJc/vxsxB5SG GjqOJiectGLY6XO7iy385rM+bTAr/sXV/CSd5aMvUY2ivtXS5bCCSmJQS1XS/FBG54bumWKTtYka feRkvG3TQ8YXV1OeAD5I3+FG9QAAAAAAAA== ------=_NextPart_000_00D8_01C8CC84.14EFAC20-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CHsFN6026289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 10:54:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5CHsEaW026286; Thu, 12 Jun 2008 10:54:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CHsCLk026242 for ; Thu, 12 Jun 2008 10:54:13 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m5CHsBrY026390 for ; Thu, 12 Jun 2008 13:54:11 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m5CHsBfq026381; Thu, 12 Jun 2008 13:54:11 -0400 Received: from mb711fa48.tmodns.net ([172.31.18.118]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 13:54:03 -0400 Cc: "max pritikin" , "Tim Polk" , "Bob Bell (rtbell)" , Message-Id: From: Timothy J Miller To: Santosh Chokhani In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-6-910284558; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Thu, 12 Jun 2008 12:53:18 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 12 Jun 2008 17:54:05.0748 (UTC) FILETIME=[4E74BF40:01C8CCB5] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-6-910284558 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cisco's CallManager does interesting things re: certificates provisioning and trust lists (google Certificate Authority Proxy Function [CAPF] and Certificate Trust List Provider [CTL Provider]). Coincidentally, both these services had fairly significant vulnerabilities recently. Shall I speculate that the question arises from this? :) -- Tim On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > Max, > > I am just responding to inaccuracies in what you are saying. > > Can you and Bob tell me why you started this thread and what you are > seeking from the PKIX community? > > I for sure am clueless except for pointing out inaccuracies in your > assertions and/or conclusions. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 6:51 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > Santosh, you've moved the conversation back to a discussion of item > (3) in my comments below: out-of-scope population of the trust > anchors. I think this is orthogonal to a discussion of dealing with > trust-anchors that exactly match a single certificate being validated. > > - max > > > On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > >> >> Max, >> >> I do not have any problem with successfully verifying signature made >> by >> a trust anchor. >> >> As I said a day or two back in this chain, if the relying party who >> installs the certificate as a trust anchor and does not make >> additional >> checks of basic constraints, is susceptible to undetected compromise >> of >> this end entity certificate spawning an entire PKI hierarchy. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 6:17 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> We're into the realm of discussing _how_ one would modify Certificate >> Path Validation to support EE certificates as a trust anchor where my >> intention was only to support the concept as a discussion point. >> >> Santosh, it isn't that the constraints/extensions are ever applied to >> the trust anchor credential itself. It is that they are applied when >> validating the chain. Take for example Name Constraints or Policy >> Constraints or other Basic Constraints fields such as >> pathLenConstraint which are all in the trust anchor certificate and >> then taken into account when validating a certificate chain. If the >> trust anchor certificate does not have keyCertSign set then logically >> no 'chained' certificates would be valid; just like if the >> pathLenConstraint was '1' but the chain being verified has a path >> length of something greater. >> >> I think this question of EE cert vs CA cert as a trust anchor is >> about >> what should happen if the chain being validated consists of only the >> trust anchor. Independent of any questions concerning key usage, >> constraints or anything else. >> >> - max >> >> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >> >>> >>> Max, >>> >>> The text you cite does not apply to trust anchor. Please see X.509 >>> and >>> RFC 5280 path validation text. Nothing needs to be verified from a >>> trust anchor. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 4:47 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> Santosh, >>> >>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>> The cA boolean indicates whether the certified public key may be >>>> used >>>> to verify certificate signatures. If the cA boolean is not >>>> asserted, >>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>> asserted. If the basic constraints extension is not present in a >>>> version 3 certificate, or the extension is present but the cA >>>> boolean >>>> is not asserted, then the certified public key MUST NOT be used to >>>> verify certificate signatures. >>> >>> An EE certificate being in the trust store would not cause confusion >>> about this. >>> >>> - max >>> >>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I do not agree with your point on item 2. Once a certificate is a >>>> trust >>>> anchor, neither X.509 not 5280 have any constraints on it from >>>> being a >>>> issuer. >>>> >>>> Furthermore, path length constraint if present in the self-signed >>>> certificate can be ignored by relying parties. >>>> >>>> -----Original Message----- >>>> From: owner-ietf-pkix@mail.imc.org >>> [mailto:owner-ietf-pkix@mail.imc.org >>>> ] >>>> On Behalf Of max pritikin >>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>> To: Tim Polk >>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> >>>> A few comments on this thread: >>>> >>>> 1) Any entry in the trust anchor store would seem to be "directly >>>> trusted". If so an additional flag isn't needed so much as a >>>> statement >>>> about how path validation proceeds if, during path discovery, it >>>> turns >>>> out the certificate being validated is already directly trusted. >>>> >>>> 2) Inclusion into the trust anchor store doesn't imply that a cert >>>> is >>>> trusted to issue certificates -- that is directly controlled by the >>>> values within the certificate (chain). >>>> >>>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>>> been the subject of recent BoF work (and more?). It would nice if >>>> that >>>> work also addressed this question. >>>> >>>> Issues related to this come up on a regular basis. Look at the >>>> various >>>> ways browser deal with caching EE certificates to "trust this site >>>> always" etc. I think Bob has raised a good point. >>>> >>>> - max >>>> >>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>> >>>>> >>>>> Bob, >>>>> >>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>> Wen- >>>>> Chen Wang have already provided a lot of good feedback. I decided >>>>> to respond to the original message because I would like to go back >>>>> to the perceived requirement.] >>>>> >>>>> It sounds like you want to construct a list of directly trusted EE >>>>> certificates, but are trying to satisfy this requirement using the >>>>> application's trust anchor store. There is nothing inherently >>>>> wrong >>>>> with direct trust (and RFC 5280 does not preclude directly >>>>> trusting >>>>> an EE certificate), but you really need a different - and far >>>>> simpler - mechanism. The trust anchor store is implicitly linked >>>>> to >>>>> path discovery and validation, which are not relevant here since a >>>>> directly trusted certificate cannot be validated. With a directly >>>>> trusted certificate, there is also no mechanism to validate status >>>>> information. >>>>> >>>>> To further complicate matters, storing the certificate you wish to >>>>> directly trust in the trust anchor store implies that it is >>>>> trusted >>>>> to issue certificates as well. The path validation inputs >>>>> specified >>>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>>> public key algorithm, public key, and parameters if needed). The >>>>> assumption is that the trust anchor's authority to issue >>>>> certificates was verified based on an out-of-band trust mechanism >>>>> (which is out of scope for 5280). This makes sense since a trust >>>>> anchor might have distributed a v1 certificate (which does not >>>>> include extensions). >>>>> >>>>> As others have noted, direct trust also implies an out-of-band >>>>> trust >>>>> mechanism. I received the EE certificate from a trusted source >>>>> so I >>>>> can trust the binding between the subject name and the key; issuer >>>>> name and the signature are irrelevant. If the certificate status >>>>> matters, I am also depending on an out-of-band mechanism to inform >>>>> me! The out-of-band mechanism(s) in combination with protected >>>>> local storage provide the basis for security in this system... >>>>> >>>>> Trying to combine these two mechanisms using a single certificate >>>>> store probably requires an additional flag on every entry to >>>>> differentiate between directly trusted certificates and trust >>>>> anchors. Two separate stores might be cleaner in the long run. >>>>> >>>>> Thanks, >>>>> >>>>> Tim Polk >>>>> >>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>> >>>>>> Folks- >>>>>> >>>>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>>>> adress the case where an end-entity certificate (not a CA cert) >>>>>> is >>>>>> installed in the trust anchor list by the user accepting the >>>>>> presented cert as authoritative and then the cert is subsequently >>>>>> presented (in a later access to the site). There should be no >>>>>> path >>>>>> search, since the presented cert is in the trust anchor list. So, >>>>>> where is it defined to accept the end-entity cert? >>>>>> >>>>>> Thanks ---- Bob >>>>>> >>>>>> Bob Bell >>>>>> Cisco Systems, Inc. >>>>>> 576 S. Brentwood Ln. >>>>>> Bountiful, UT 84010 >>>>>> 801-294-3034 (v) >>>>>> 801-294-3023 (f) >>>>>> 801-971-4200 (c) >>>>>> rtbell@cisco.com >>>>>> >>>>> >>>> >>> >> > --Apple-Mail-6-910284558 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16 KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS +lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8 umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3 aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6 1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNjEyMTc1MzE4 WjAjBgkqhkiG9w0BCQQxFgQUxcC/OYyCLKoBdIE4c6KhrHhgTggwcgYJKwYBBAGCNxAEMWUwYzBd MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB BQAEgYDaxEECOBXZhddWdHCmBBctYc9G28W6gLReA4iOSg3l1mjyKxRy0yYmtwISqIIYJ09gbYeV WDgR18M9RRtqF3v4rOhUIaBTc8TqZ5jfC/e2ZJE5DtaBhBhUDeG2uZ+ike08ftZbXj0Rm3RDSU7R j/xWOLr0xjl70/WfeUZM3ExiqgAAAAAAAA== --Apple-Mail-6-910284558-- Received: from [220.227.249.164] ([220.227.249.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5CBAsgG041439 for ; Thu, 12 Jun 2008 04:11:01 -0700 (MST) (envelope-from iulian-pm{eki{r@ATECHTAMPA.com) From: "=?ISO-8859-1?Q?Ciolfi?=" To: ietf-pkix-archive@imc.org Subject: =?ISO-8859-1?Q?Playboy party invite?= Date: Thu, 12 Jun 2008 16:41:43 +05-30 Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: Angelina admits to having previous threesome with 2 other celebs. http://family-doctor.kiev.ua/r.html Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5C5HgHP056522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 22:17:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5C5HgYK056521; Wed, 11 Jun 2008 22:17:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5C5HdSX056502 for ; Wed, 11 Jun 2008 22:17:40 -0700 (MST) (envelope-from ynir@checkpoint.com) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8D8E4294002; Thu, 12 Jun 2008 08:17:38 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B4D17294001 for ; Thu, 12 Jun 2008 08:17:37 +0300 (IDT) Received: from [172.31.24.139] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m5C5HajI006487 for ; Thu, 12 Jun 2008 08:17:36 +0300 (IDT) Message-Id: From: Yoav Nir To: ietf-pkix@imc.org In-Reply-To: <20080611234329.8C086136506@bosco.isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5274 on Certificate Managmement Messages over CMS (CMC): Complience Requirements Date: Thu, 12 Jun 2008 08:17:14 +0300 References: <20080611234329.8C086136506@bosco.isi.edu> X-Mailer: Apple Mail (2.924) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, at least the real RFC doesn't have the spelling mistakes. s/Managmement/Management/ s/Complience/Compliance/ On Jun 12, 2008, at 2:43 AM, rfc-editor@rfc-editor.org wrote: > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5274 > > Title: Certificate Managmement Messages over CMS > (CMC): Complience Requirements > Author: J. Schaad, M. Myers > Status: Standards Track > Date: June 2008 > Mailbox: jimsch@nwlink.com, mmyers@fastq.com > Pages: 13 > Characters: 27380 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-pkix-cmc-compl-05.txt > > URL: http://www.rfc-editor.org/rfc/rfc5274.txt > > This document provides a set of compliance statements about the CMC > (Certificate Management over CMS) enrollment protocol. The ASN.1 > structures and the transport mechanisms for the CMC enrollment > protocol are covered in other documents. This document provides the > information needed to make a compliant version of CMC. [STANDARDS > TRACK] > > This document is a product of the Public-Key Infrastructure (X.509) > Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html > . > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. > Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > > > Scanned by Check Point Total Security Gateway. > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhUEs086166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 16:43:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5BNhUMu086165; Wed, 11 Jun 2008 16:43:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhTWx086159 for ; Wed, 11 Jun 2008 16:43:29 -0700 (MST) (envelope-from rfc-editor@rfc-editor.org) Received: by bosco.isi.edu (Postfix, from userid 70) id 8C086136506; Wed, 11 Jun 2008 16:43:29 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5274 on Certificate Managmement Messages over CMS (CMC): Complience Requirements From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org Message-Id: <20080611234329.8C086136506@bosco.isi.edu> Date: Wed, 11 Jun 2008 16:43:29 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A new Request for Comments is now available in online RFC libraries. RFC 5274 Title: Certificate Managmement Messages over CMS (CMC): Complience Requirements Author: J. Schaad, M. Myers Status: Standards Track Date: June 2008 Mailbox: jimsch@nwlink.com, mmyers@fastq.com Pages: 13 Characters: 27380 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-cmc-compl-05.txt URL: http://www.rfc-editor.org/rfc/rfc5274.txt This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. [STANDARDS TRACK] This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhQGB086143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 16:43:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5BNhQX0086142; Wed, 11 Jun 2008 16:43:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhO7t086130 for ; Wed, 11 Jun 2008 16:43:25 -0700 (MST) (envelope-from rfc-editor@rfc-editor.org) Received: by bosco.isi.edu (Postfix, from userid 70) id 55936136501; Wed, 11 Jun 2008 16:43:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5272 on Certificate Management over CMS (CMC) From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org Message-Id: <20080611234324.55936136501@bosco.isi.edu> Date: Wed, 11 Jun 2008 16:43:24 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A new Request for Comments is now available in online RFC libraries. RFC 5272 Title: Certificate Management over CMS (CMC) Author: J. Schaad, M. Myers Status: Standards Track Date: June 2008 Mailbox: jimsch@nwlink.com, mmyers@fastq.com Pages: 83 Characters: 167138 Obsoletes: RFC2797 I-D Tag: draft-ietf-pkix-2797-bis-07.txt URL: http://www.rfc-editor.org/rfc/rfc5272.txt This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and 2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design. CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS TRACK] This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhQso086146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 16:43:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5BNhQ7W086145; Wed, 11 Jun 2008 16:43:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BNhP6o086136 for ; Wed, 11 Jun 2008 16:43:25 -0700 (MST) (envelope-from rfc-editor@rfc-editor.org) Received: by bosco.isi.edu (Postfix, from userid 70) id 8059B136503; Wed, 11 Jun 2008 16:43:25 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5273 on Certificate Management over CMS (CMC): Transport Protocols From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org Message-Id: <20080611234325.8059B136503@bosco.isi.edu> Date: Wed, 11 Jun 2008 16:43:25 -0700 (PDT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A new Request for Comments is now available in online RFC libraries. RFC 5273 Title: Certificate Management over CMS (CMC): Transport Protocols Author: J. Schaad, M. Myers Status: Standards Track Date: June 2008 Mailbox: jimsch@nwlink.com, mmyers@fastq.com Pages: 7 Characters: 14030 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-cmc-trans-08.txt URL: http://www.rfc-editor.org/rfc/rfc5273.txt This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. [STANDARDS TRACK] This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BF5CLl076575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 08:05:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5BF5BwY076572; Wed, 11 Jun 2008 08:05:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BF56mo076551 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Wed, 11 Jun 2008 08:05:07 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,624,1204531200"; d="p7s'?scan'208";a="111848512" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2008 08:04:55 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5BF4tlm016374; Wed, 11 Jun 2008 08:04:55 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5BF4tXa017667; Wed, 11 Jun 2008 15:04:55 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 08:04:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Wed, 11 Jun 2008 08:04:52 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0029_01C8CBA2.3550B000" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLTH5Hg0qmW0KtSNutOGVbidlYtQAHwfDgABowzeA= References: From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , "Max Pritikin (pritikin)" Cc: "Tim Polk" , X-OriginalArrivalTime: 11 Jun 2008 15:04:55.0626 (UTC) FILETIME=[82194AA0:01C8CBD4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14707; t=1213196695; x=1214060695; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=wb2EfUxkd9ZMcT4b/KhVA1HEgAf99SntO/eXZsVu7S0=; b=uOgTsTNEsBrbQE1/prT5fWJUndTX6ygu7rMc3nh/VYnB1py6fpqHDUuAvG vOEneEYdTbcHffXkbe8QJ6vzx8hYjMIJA1l2lohtp+yzsf9Gm4sYnDqIqPxh Iy8D+VT57S15DJ+OEZy5+quV34jEb9W42UVVLf8eY8URJnWE16Ve8=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C8CBA2.3550B000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - I was requesting clarification on the meaning of some of the concepts in RFC5280. I had no other reasons. What I was trying to establish was if there were issues with the way some of my compatriates had interpreted the rfc. Bob > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani > Sent: Tuesday, 10 June, 2008 20:35 > To: Max Pritikin (pritikin) > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > > Max, > > I am just responding to inaccuracies in what you are saying. > > Can you and Bob tell me why you started this thread and what > you are seeking from the PKIX community? > > I for sure am clueless except for pointing out inaccuracies > in your assertions and/or conclusions. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 6:51 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > Santosh, you've moved the conversation back to a discussion of item > (3) in my comments below: out-of-scope population of the trust > anchors. I think this is orthogonal to a discussion of dealing with > trust-anchors that exactly match a single certificate being validated. > > - max > > > On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > > > > > Max, > > > > I do not have any problem with successfully verifying > signature made > > by > > a trust anchor. > > > > As I said a day or two back in this chain, if the relying party who > > installs the certificate as a trust anchor and does not make > > additional > > checks of basic constraints, is susceptible to undetected > compromise > > of > > this end entity certificate spawning an entire PKI hierarchy. > > > > -----Original Message----- > > From: max pritikin [mailto:pritikin@cisco.com] > > Sent: Tuesday, June 10, 2008 6:17 PM > > To: Santosh Chokhani > > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > > Subject: Re: RFC 5280 Question > > > > > > We're into the realm of discussing _how_ one would modify > Certificate > > Path Validation to support EE certificates as a trust > anchor where my > > intention was only to support the concept as a discussion point. > > > > Santosh, it isn't that the constraints/extensions are ever > applied to > > the trust anchor credential itself. It is that they are applied when > > validating the chain. Take for example Name Constraints or Policy > > Constraints or other Basic Constraints fields such as > > pathLenConstraint which are all in the trust anchor certificate and > > then taken into account when validating a certificate chain. If the > > trust anchor certificate does not have keyCertSign set then > logically > > no 'chained' certificates would be valid; just like if the > > pathLenConstraint was '1' but the chain being verified has a path > > length of something greater. > > > > I think this question of EE cert vs CA cert as a trust > anchor is about > > what should happen if the chain being validated consists of only the > > trust anchor. Independent of any questions concerning key usage, > > constraints or anything else. > > > > - max > > > > On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > > > >> > >> Max, > >> > >> The text you cite does not apply to trust anchor. Please see X.509 > >> and > >> RFC 5280 path validation text. Nothing needs to be verified from a > >> trust anchor. > >> > >> -----Original Message----- > >> From: max pritikin [mailto:pritikin@cisco.com] > >> Sent: Tuesday, June 10, 2008 4:47 PM > >> To: Santosh Chokhani > >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > >> Subject: Re: RFC 5280 Question > >> > >> > >> Santosh, > >> > >> RFC5280 section 4.2.1.9 (Basic Constraints) says: > >>> The cA boolean indicates whether the certified public key may be > >>> used > >>> to verify certificate signatures. If the cA boolean is not > >>> asserted, > >>> then the keyCertSign bit in the key usage extension MUST NOT be > >>> asserted. If the basic constraints extension is not present in a > >>> version 3 certificate, or the extension is present but the cA > >>> boolean > >>> is not asserted, then the certified public key MUST NOT > be used to > >>> verify certificate signatures. > >> > >> An EE certificate being in the trust store would not cause > confusion > >> about this. > >> > >> - max > >> > >> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > >> > >>> Max, > >>> > >>> I do not agree with your point on item 2. Once a certificate is a > >>> trust > >>> anchor, neither X.509 not 5280 have any constraints on it from > >>> being a > >>> issuer. > >>> > >>> Furthermore, path length constraint if present in the self-signed > >>> certificate can be ignored by relying parties. > >>> > >>> -----Original Message----- > >>> From: owner-ietf-pkix@mail.imc.org > >> [mailto:owner-ietf-pkix@mail.imc.org > >>> ] > >>> On Behalf Of max pritikin > >>> Sent: Tuesday, June 10, 2008 2:35 PM > >>> To: Tim Polk > >>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org > >>> Subject: Re: RFC 5280 Question > >>> > >>> > >>> > >>> A few comments on this thread: > >>> > >>> 1) Any entry in the trust anchor store would seem to be "directly > >>> trusted". If so an additional flag isn't needed so much as a > >>> statement > >>> about how path validation proceeds if, during path discovery, it > >>> turns > >>> out the certificate being validated is already directly trusted. > >>> > >>> 2) Inclusion into the trust anchor store doesn't imply > that a cert > >>> is > >>> trusted to issue certificates -- that is directly > controlled by the > >>> values within the certificate (chain). > >>> > >>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has > >>> been the subject of recent BoF work (and more?). It would nice if > >>> that > >>> work also addressed this question. > >>> > >>> Issues related to this come up on a regular basis. Look at the > >>> various > >>> ways browser deal with caching EE certificates to "trust this site > >>> always" etc. I think Bob has raised a good point. > >>> > >>> - max > >>> > >>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > >>> > >>>> > >>>> Bob, > >>>> > >>>> [I realize I am late to the party, and that Santosh, Steve, and > >>>> Wen- > >>>> Chen Wang have already provided a lot of good feedback. > I decided > >>>> to respond to the original message because I would like > to go back > >>>> to the perceived requirement.] > >>>> > >>>> It sounds like you want to construct a list of directly > trusted EE > >>>> certificates, but are trying to satisfy this requirement > using the > >>>> application's trust anchor store. There is nothing inherently > >>>> wrong > >>>> with direct trust (and RFC 5280 does not preclude > directly trusting > >>>> an EE certificate), but you really need a different - and far > >>>> simpler - mechanism. The trust anchor store is > implicitly linked > >>>> to > >>>> path discovery and validation, which are not relevant > here since a > >>>> directly trusted certificate cannot be validated. With > a directly > >>>> trusted certificate, there is also no mechanism to > validate status > >>>> information. > >>>> > >>>> To further complicate matters, storing the certificate > you wish to > >>>> directly trust in the trust anchor store implies that it > is trusted > >>>> to issue certificates as well. The path validation inputs > >>>> specified > >>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, > >>>> public key algorithm, public key, and parameters if needed). The > >>>> assumption is that the trust anchor's authority to issue > >>>> certificates was verified based on an out-of-band trust mechanism > >>>> (which is out of scope for 5280). This makes sense since a trust > >>>> anchor might have distributed a v1 certificate (which does not > >>>> include extensions). > >>>> > >>>> As others have noted, direct trust also implies an out-of-band > >>>> trust > >>>> mechanism. I received the EE certificate from a trusted source > >>>> so I > >>>> can trust the binding between the subject name and the > key; issuer > >>>> name and the signature are irrelevant. If the > certificate status > >>>> matters, I am also depending on an out-of-band mechanism > to inform > >>>> me! The out-of-band mechanism(s) in combination with protected > >>>> local storage provide the basis for security in this system... > >>>> > >>>> Trying to combine these two mechanisms using a single certificate > >>>> store probably requires an additional flag on every entry to > >>>> differentiate between directly trusted certificates and trust > >>>> anchors. Two separate stores might be cleaner in the long run. > >>>> > >>>> Thanks, > >>>> > >>>> Tim Polk > >>>> > >>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > >>>> > >>>>> Folks- > >>>>> > >>>>> I am hoping someone can give me the answer to this. > Does RFC 5280 > >>>>> adress the case where an end-entity certificate (not a > CA cert) is > >>>>> installed in the trust anchor list by the user accepting the > >>>>> presented cert as authoritative and then the cert is > subsequently > >>>>> presented (in a later access to the site). There should > be no path > >>>>> search, since the presented cert is in the trust anchor > list. So, > >>>>> where is it defined to accept the end-entity cert? > >>>>> > >>>>> Thanks ---- Bob > >>>>> > >>>>> Bob Bell > >>>>> Cisco Systems, Inc. > >>>>> 576 S. Brentwood Ln. > >>>>> Bountiful, UT 84010 > >>>>> 801-294-3034 (v) > >>>>> 801-294-3023 (f) > >>>>> 801-971-4200 (c) > >>>>> rtbell@cisco.com > >>>>> > >>>> > >>> > >> > > > > ------=_NextPart_000_0029_01C8CBA2.3550B000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTExNTA0NTFaMCMGCSqGSIb3DQEJBDEWBBTyiLTLmxsq2JGWIOMq dmlbOlz/VDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYCN3Zc89eFzl6M7EGRadbYQRkkalzcCxaasadIJaM7cqOTDMCrnlaWNACfr328VUYX5rGEn ntlI3kToEKRXGIZXRvhHNwehiRhBYyuBofDiBz2W8TGaV6ZaidEM31shvajAoehmzxDAlL6XONUQ oeiZKlTCmLq+b3R+g+Vwyk1VAwAAAAAAAA== ------=_NextPart_000_0029_01C8CBA2.3550B000-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5BESvRo070278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 07:28:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5BESv37070276; Wed, 11 Jun 2008 07:28:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5BESo61070238 for ; Wed, 11 Jun 2008 07:28:55 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 11958 invoked from network); 11 Jun 2008 14:18:33 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;11 Jun 2008 14:18:33 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 11 Jun 2008 14:18:32 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Wed, 11 Jun 2008 10:28:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLcMPKSFwZDMdHReWQT29g5vSz9AAXoK3w References: From: "Santosh Chokhani" To: "max pritikin" Cc: "Tim Polk" , "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, I do not understand from your posting what the specific concern or issue you want to bring to the attention of PKIX. We have had lot of digressions on this topic. Please restate what your concerns are. -----Original Message----- From: max pritikin [mailto:pritikin@cisco.com]=20 Sent: Tuesday, June 10, 2008 11:11 PM To: Santosh Chokhani Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org Subject: Re: RFC 5280 Question I'm not sure what Bob's goals are, perhaps just to ask the question. =20 We don't work very closely together. This just struck a note with me because I've seen it raised as a =20 problem in other cases as well. - max On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > Max, > > I am just responding to inaccuracies in what you are saying. > > Can you and Bob tell me why you started this thread and what you are > seeking from the PKIX community? > > I for sure am clueless except for pointing out inaccuracies in your > assertions and/or conclusions. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 6:51 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > Santosh, you've moved the conversation back to a discussion of item > (3) in my comments below: out-of-scope population of the trust > anchors. I think this is orthogonal to a discussion of dealing with > trust-anchors that exactly match a single certificate being validated. > > - max > > > On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > >> >> Max, >> >> I do not have any problem with successfully verifying signature made >> by >> a trust anchor. >> >> As I said a day or two back in this chain, if the relying party who >> installs the certificate as a trust anchor and does not make >> additional >> checks of basic constraints, is susceptible to undetected compromise >> of >> this end entity certificate spawning an entire PKI hierarchy. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 6:17 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> We're into the realm of discussing _how_ one would modify Certificate >> Path Validation to support EE certificates as a trust anchor where my >> intention was only to support the concept as a discussion point. >> >> Santosh, it isn't that the constraints/extensions are ever applied to >> the trust anchor credential itself. It is that they are applied when >> validating the chain. Take for example Name Constraints or Policy >> Constraints or other Basic Constraints fields such as >> pathLenConstraint which are all in the trust anchor certificate and >> then taken into account when validating a certificate chain. If the >> trust anchor certificate does not have keyCertSign set then logically >> no 'chained' certificates would be valid; just like if the >> pathLenConstraint was '1' but the chain being verified has a path >> length of something greater. >> >> I think this question of EE cert vs CA cert as a trust anchor is =20 >> about >> what should happen if the chain being validated consists of only the >> trust anchor. Independent of any questions concerning key usage, >> constraints or anything else. >> >> - max >> >> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >> >>> >>> Max, >>> >>> The text you cite does not apply to trust anchor. Please see X.509 >>> and >>> RFC 5280 path validation text. Nothing needs to be verified from a >>> trust anchor. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 4:47 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> Santosh, >>> >>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>> The cA boolean indicates whether the certified public key may be >>>> used >>>> to verify certificate signatures. If the cA boolean is not >>>> asserted, >>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>> asserted. If the basic constraints extension is not present in a >>>> version 3 certificate, or the extension is present but the cA >>>> boolean >>>> is not asserted, then the certified public key MUST NOT be used to >>>> verify certificate signatures. >>> >>> An EE certificate being in the trust store would not cause confusion >>> about this. >>> >>> - max >>> >>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I do not agree with your point on item 2. Once a certificate is a >>>> trust >>>> anchor, neither X.509 not 5280 have any constraints on it from >>>> being a >>>> issuer. >>>> >>>> Furthermore, path length constraint if present in the self-signed >>>> certificate can be ignored by relying parties. >>>> >>>> -----Original Message----- >>>> From: owner-ietf-pkix@mail.imc.org >>> [mailto:owner-ietf-pkix@mail.imc.org >>>> ] >>>> On Behalf Of max pritikin >>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>> To: Tim Polk >>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> >>>> A few comments on this thread: >>>> >>>> 1) Any entry in the trust anchor store would seem to be "directly >>>> trusted". If so an additional flag isn't needed so much as a >>>> statement >>>> about how path validation proceeds if, during path discovery, it >>>> turns >>>> out the certificate being validated is already directly trusted. >>>> >>>> 2) Inclusion into the trust anchor store doesn't imply that a cert >>>> is >>>> trusted to issue certificates -- that is directly controlled by the >>>> values within the certificate (chain). >>>> >>>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>>> been the subject of recent BoF work (and more?). It would nice if >>>> that >>>> work also addressed this question. >>>> >>>> Issues related to this come up on a regular basis. Look at the >>>> various >>>> ways browser deal with caching EE certificates to "trust this site >>>> always" etc. I think Bob has raised a good point. >>>> >>>> - max >>>> >>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>> >>>>> >>>>> Bob, >>>>> >>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>> Wen- >>>>> Chen Wang have already provided a lot of good feedback. I decided >>>>> to respond to the original message because I would like to go back >>>>> to the perceived requirement.] >>>>> >>>>> It sounds like you want to construct a list of directly trusted EE >>>>> certificates, but are trying to satisfy this requirement using the >>>>> application's trust anchor store. There is nothing inherently >>>>> wrong >>>>> with direct trust (and RFC 5280 does not preclude directly =20 >>>>> trusting >>>>> an EE certificate), but you really need a different - and far >>>>> simpler - mechanism. The trust anchor store is implicitly linked >>>>> to >>>>> path discovery and validation, which are not relevant here since a >>>>> directly trusted certificate cannot be validated. With a directly >>>>> trusted certificate, there is also no mechanism to validate status >>>>> information. >>>>> >>>>> To further complicate matters, storing the certificate you wish to >>>>> directly trust in the trust anchor store implies that it is =20 >>>>> trusted >>>>> to issue certificates as well. The path validation inputs >>>>> specified >>>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>>> public key algorithm, public key, and parameters if needed). The >>>>> assumption is that the trust anchor's authority to issue >>>>> certificates was verified based on an out-of-band trust mechanism >>>>> (which is out of scope for 5280). This makes sense since a trust >>>>> anchor might have distributed a v1 certificate (which does not >>>>> include extensions). >>>>> >>>>> As others have noted, direct trust also implies an out-of-band >>>>> trust >>>>> mechanism. I received the EE certificate from a trusted source >>>>> so I >>>>> can trust the binding between the subject name and the key; issuer >>>>> name and the signature are irrelevant. If the certificate status >>>>> matters, I am also depending on an out-of-band mechanism to inform >>>>> me! The out-of-band mechanism(s) in combination with protected >>>>> local storage provide the basis for security in this system... >>>>> >>>>> Trying to combine these two mechanisms using a single certificate >>>>> store probably requires an additional flag on every entry to >>>>> differentiate between directly trusted certificates and trust >>>>> anchors. Two separate stores might be cleaner in the long run. >>>>> >>>>> Thanks, >>>>> >>>>> Tim Polk >>>>> >>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>> >>>>>> Folks- >>>>>> >>>>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>>>> adress the case where an end-entity certificate (not a CA cert) =20 >>>>>> is >>>>>> installed in the trust anchor list by the user accepting the >>>>>> presented cert as authoritative and then the cert is subsequently >>>>>> presented (in a later access to the site). There should be no =20 >>>>>> path >>>>>> search, since the presented cert is in the trust anchor list. So, >>>>>> where is it defined to accept the end-entity cert? >>>>>> >>>>>> Thanks ---- Bob >>>>>> >>>>>> Bob Bell >>>>>> Cisco Systems, Inc. >>>>>> 576 S. Brentwood Ln. >>>>>> Bountiful, UT 84010 >>>>>> 801-294-3034 (v) >>>>>> 801-294-3023 (f) >>>>>> 801-971-4200 (c) >>>>>> rtbell@cisco.com >>>>>> >>>>> >>>> >>> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5B3VOnK015876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 20:31:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5B3VODl015875; Tue, 10 Jun 2008 20:31:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.nic.cl (mail.nic.cl [200.1.123.8]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5B3VNRr015868 for ; Tue, 10 Jun 2008 20:31:24 -0700 (MST) (envelope-from hsalgado@nic.cl) Received: from mail.nic.cl (mailn [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 214DCCC8367 for ; Tue, 10 Jun 2008 23:31:11 -0400 (CLT) Received: by mail.nic.cl (Postfix, from userid 48) id 16547CC8375; Tue, 10 Jun 2008 23:31:11 -0400 (CLT) Received: from 200.83.213.101 (SquirrelMail authenticated user hsalgado) by webmail.nic.cl with HTTP; Tue, 10 Jun 2008 23:31:11 -0400 (CLT) Message-ID: <39016.200.83.213.101.1213155071.squirrel@webmail.nic.cl> Date: Tue, 10 Jun 2008 23:31:11 -0400 (CLT) Subject: From: hsalgado@nic.cl To: ietf-pkix@vpnc.org User-Agent: SquirrelMail/1.4.8-4.0.1..el5.centos.1 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV using ClamSMTP on Tue Jun 10 23:31:11 2008 -0400 (CLT) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: auth 7ae8b5809ece7989f9c15ba872fe6262 subscribe ietf-pkix hsalgado@nic.cl Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5B3Arsa010932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 20:10:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5B3Ar0T010929; Tue, 10 Jun 2008 20:10:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5B3Ao30010907 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2008 20:10:51 -0700 (MST) (envelope-from pritikin@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,621,1204531200"; d="scan'208";a="55614022" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2008 20:10:50 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5B3AoXn014448; Tue, 10 Jun 2008 20:10:50 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5B3AowV027669; Wed, 11 Jun 2008 03:10:50 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 20:10:49 -0700 Received: from [10.0.1.200] ([10.32.244.67]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 20:10:48 -0700 Cc: "Tim Polk" , "Bob Bell (rtbell)" , Message-Id: From: max pritikin To: "Santosh Chokhani" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 22:10:47 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 11 Jun 2008 03:10:49.0327 (UTC) FILETIME=[BFB6E7F0:01C8CB70] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9467; t=1213153850; x=1214017850; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20RFC=205280=20Question |Sender:=20; bh=MVdFEuO30lLWnj1eHUP8KsguoPSEeMjAOhLlRVAQV1w=; b=SEwZHhLyeri++tX9VY5eCPnXSJhJe1ULwTSD8Phf4LsUhRlEsD/7v0ZDxK fGQN9B40VzYcm460WJH8z3Vtkw1r8DvwOmKIb/C5rGOWZmsaPGPZ4OxXHzjM PlfbRFAma7; Authentication-Results: sj-dkim-3; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm not sure what Bob's goals are, perhaps just to ask the question. We don't work very closely together. This just struck a note with me because I've seen it raised as a problem in other cases as well. - max On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote: > > Max, > > I am just responding to inaccuracies in what you are saying. > > Can you and Bob tell me why you started this thread and what you are > seeking from the PKIX community? > > I for sure am clueless except for pointing out inaccuracies in your > assertions and/or conclusions. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 6:51 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > Santosh, you've moved the conversation back to a discussion of item > (3) in my comments below: out-of-scope population of the trust > anchors. I think this is orthogonal to a discussion of dealing with > trust-anchors that exactly match a single certificate being validated. > > - max > > > On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > >> >> Max, >> >> I do not have any problem with successfully verifying signature made >> by >> a trust anchor. >> >> As I said a day or two back in this chain, if the relying party who >> installs the certificate as a trust anchor and does not make >> additional >> checks of basic constraints, is susceptible to undetected compromise >> of >> this end entity certificate spawning an entire PKI hierarchy. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 6:17 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> We're into the realm of discussing _how_ one would modify Certificate >> Path Validation to support EE certificates as a trust anchor where my >> intention was only to support the concept as a discussion point. >> >> Santosh, it isn't that the constraints/extensions are ever applied to >> the trust anchor credential itself. It is that they are applied when >> validating the chain. Take for example Name Constraints or Policy >> Constraints or other Basic Constraints fields such as >> pathLenConstraint which are all in the trust anchor certificate and >> then taken into account when validating a certificate chain. If the >> trust anchor certificate does not have keyCertSign set then logically >> no 'chained' certificates would be valid; just like if the >> pathLenConstraint was '1' but the chain being verified has a path >> length of something greater. >> >> I think this question of EE cert vs CA cert as a trust anchor is >> about >> what should happen if the chain being validated consists of only the >> trust anchor. Independent of any questions concerning key usage, >> constraints or anything else. >> >> - max >> >> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: >> >>> >>> Max, >>> >>> The text you cite does not apply to trust anchor. Please see X.509 >>> and >>> RFC 5280 path validation text. Nothing needs to be verified from a >>> trust anchor. >>> >>> -----Original Message----- >>> From: max pritikin [mailto:pritikin@cisco.com] >>> Sent: Tuesday, June 10, 2008 4:47 PM >>> To: Santosh Chokhani >>> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> Santosh, >>> >>> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>>> The cA boolean indicates whether the certified public key may be >>>> used >>>> to verify certificate signatures. If the cA boolean is not >>>> asserted, >>>> then the keyCertSign bit in the key usage extension MUST NOT be >>>> asserted. If the basic constraints extension is not present in a >>>> version 3 certificate, or the extension is present but the cA >>>> boolean >>>> is not asserted, then the certified public key MUST NOT be used to >>>> verify certificate signatures. >>> >>> An EE certificate being in the trust store would not cause confusion >>> about this. >>> >>> - max >>> >>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >>> >>>> Max, >>>> >>>> I do not agree with your point on item 2. Once a certificate is a >>>> trust >>>> anchor, neither X.509 not 5280 have any constraints on it from >>>> being a >>>> issuer. >>>> >>>> Furthermore, path length constraint if present in the self-signed >>>> certificate can be ignored by relying parties. >>>> >>>> -----Original Message----- >>>> From: owner-ietf-pkix@mail.imc.org >>> [mailto:owner-ietf-pkix@mail.imc.org >>>> ] >>>> On Behalf Of max pritikin >>>> Sent: Tuesday, June 10, 2008 2:35 PM >>>> To: Tim Polk >>>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>>> Subject: Re: RFC 5280 Question >>>> >>>> >>>> >>>> A few comments on this thread: >>>> >>>> 1) Any entry in the trust anchor store would seem to be "directly >>>> trusted". If so an additional flag isn't needed so much as a >>>> statement >>>> about how path validation proceeds if, during path discovery, it >>>> turns >>>> out the certificate being validated is already directly trusted. >>>> >>>> 2) Inclusion into the trust anchor store doesn't imply that a cert >>>> is >>>> trusted to issue certificates -- that is directly controlled by the >>>> values within the certificate (chain). >>>> >>>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>>> been the subject of recent BoF work (and more?). It would nice if >>>> that >>>> work also addressed this question. >>>> >>>> Issues related to this come up on a regular basis. Look at the >>>> various >>>> ways browser deal with caching EE certificates to "trust this site >>>> always" etc. I think Bob has raised a good point. >>>> >>>> - max >>>> >>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>>> >>>>> >>>>> Bob, >>>>> >>>>> [I realize I am late to the party, and that Santosh, Steve, and >>>>> Wen- >>>>> Chen Wang have already provided a lot of good feedback. I decided >>>>> to respond to the original message because I would like to go back >>>>> to the perceived requirement.] >>>>> >>>>> It sounds like you want to construct a list of directly trusted EE >>>>> certificates, but are trying to satisfy this requirement using the >>>>> application's trust anchor store. There is nothing inherently >>>>> wrong >>>>> with direct trust (and RFC 5280 does not preclude directly >>>>> trusting >>>>> an EE certificate), but you really need a different - and far >>>>> simpler - mechanism. The trust anchor store is implicitly linked >>>>> to >>>>> path discovery and validation, which are not relevant here since a >>>>> directly trusted certificate cannot be validated. With a directly >>>>> trusted certificate, there is also no mechanism to validate status >>>>> information. >>>>> >>>>> To further complicate matters, storing the certificate you wish to >>>>> directly trust in the trust anchor store implies that it is >>>>> trusted >>>>> to issue certificates as well. The path validation inputs >>>>> specified >>>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>>> public key algorithm, public key, and parameters if needed). The >>>>> assumption is that the trust anchor's authority to issue >>>>> certificates was verified based on an out-of-band trust mechanism >>>>> (which is out of scope for 5280). This makes sense since a trust >>>>> anchor might have distributed a v1 certificate (which does not >>>>> include extensions). >>>>> >>>>> As others have noted, direct trust also implies an out-of-band >>>>> trust >>>>> mechanism. I received the EE certificate from a trusted source >>>>> so I >>>>> can trust the binding between the subject name and the key; issuer >>>>> name and the signature are irrelevant. If the certificate status >>>>> matters, I am also depending on an out-of-band mechanism to inform >>>>> me! The out-of-band mechanism(s) in combination with protected >>>>> local storage provide the basis for security in this system... >>>>> >>>>> Trying to combine these two mechanisms using a single certificate >>>>> store probably requires an additional flag on every entry to >>>>> differentiate between directly trusted certificates and trust >>>>> anchors. Two separate stores might be cleaner in the long run. >>>>> >>>>> Thanks, >>>>> >>>>> Tim Polk >>>>> >>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>>> >>>>>> Folks- >>>>>> >>>>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>>>> adress the case where an end-entity certificate (not a CA cert) >>>>>> is >>>>>> installed in the trust anchor list by the user accepting the >>>>>> presented cert as authoritative and then the cert is subsequently >>>>>> presented (in a later access to the site). There should be no >>>>>> path >>>>>> search, since the presented cert is in the trust anchor list. So, >>>>>> where is it defined to accept the end-entity cert? >>>>>> >>>>>> Thanks ---- Bob >>>>>> >>>>>> Bob Bell >>>>>> Cisco Systems, Inc. >>>>>> 576 S. Brentwood Ln. >>>>>> Bountiful, UT 84010 >>>>>> 801-294-3034 (v) >>>>>> 801-294-3023 (f) >>>>>> 801-971-4200 (c) >>>>>> rtbell@cisco.com >>>>>> >>>>> >>>> >>> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5B2ZDJh003982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 19:35:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5B2ZDF5003981; Tue, 10 Jun 2008 19:35:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5B2ZBTK003974 for ; Tue, 10 Jun 2008 19:35:12 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 5511 invoked from network); 11 Jun 2008 02:24:55 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;11 Jun 2008 02:24:55 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 11 Jun 2008 02:24:54 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Tue, 10 Jun 2008 22:35:08 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLTH5Hg0qmW0KtSNutOGVbidlYtQAHwfDg References: From: "Santosh Chokhani" To: "max pritikin" Cc: "Tim Polk" , "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, I am just responding to inaccuracies in what you are saying. Can you and Bob tell me why you started this thread and what you are seeking from the PKIX community? I for sure am clueless except for pointing out inaccuracies in your assertions and/or conclusions. -----Original Message----- From: max pritikin [mailto:pritikin@cisco.com]=20 Sent: Tuesday, June 10, 2008 6:51 PM To: Santosh Chokhani Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org Subject: Re: RFC 5280 Question Santosh, you've moved the conversation back to a discussion of item =20 (3) in my comments below: out-of-scope population of the trust =20 anchors. I think this is orthogonal to a discussion of dealing with =20 trust-anchors that exactly match a single certificate being validated. - max On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > > Max, > > I do not have any problem with successfully verifying signature made =20 > by > a trust anchor. > > As I said a day or two back in this chain, if the relying party who > installs the certificate as a trust anchor and does not make =20 > additional > checks of basic constraints, is susceptible to undetected compromise =20 > of > this end entity certificate spawning an entire PKI hierarchy. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 6:17 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > We're into the realm of discussing _how_ one would modify Certificate > Path Validation to support EE certificates as a trust anchor where my > intention was only to support the concept as a discussion point. > > Santosh, it isn't that the constraints/extensions are ever applied to > the trust anchor credential itself. It is that they are applied when > validating the chain. Take for example Name Constraints or Policy > Constraints or other Basic Constraints fields such as > pathLenConstraint which are all in the trust anchor certificate and > then taken into account when validating a certificate chain. If the > trust anchor certificate does not have keyCertSign set then logically > no 'chained' certificates would be valid; just like if the > pathLenConstraint was '1' but the chain being verified has a path > length of something greater. > > I think this question of EE cert vs CA cert as a trust anchor is about > what should happen if the chain being validated consists of only the > trust anchor. Independent of any questions concerning key usage, > constraints or anything else. > > - max > > On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > >> >> Max, >> >> The text you cite does not apply to trust anchor. Please see X.509 >> and >> RFC 5280 path validation text. Nothing needs to be verified from a >> trust anchor. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 4:47 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> Santosh, >> >> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>> The cA boolean indicates whether the certified public key may be >>> used >>> to verify certificate signatures. If the cA boolean is not >>> asserted, >>> then the keyCertSign bit in the key usage extension MUST NOT be >>> asserted. If the basic constraints extension is not present in a >>> version 3 certificate, or the extension is present but the cA >>> boolean >>> is not asserted, then the certified public key MUST NOT be used to >>> verify certificate signatures. >> >> An EE certificate being in the trust store would not cause confusion >> about this. >> >> - max >> >> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >> >>> Max, >>> >>> I do not agree with your point on item 2. Once a certificate is a >>> trust >>> anchor, neither X.509 not 5280 have any constraints on it from >>> being a >>> issuer. >>> >>> Furthermore, path length constraint if present in the self-signed >>> certificate can be ignored by relying parties. >>> >>> -----Original Message----- >>> From: owner-ietf-pkix@mail.imc.org >> [mailto:owner-ietf-pkix@mail.imc.org >>> ] >>> On Behalf Of max pritikin >>> Sent: Tuesday, June 10, 2008 2:35 PM >>> To: Tim Polk >>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> >>> A few comments on this thread: >>> >>> 1) Any entry in the trust anchor store would seem to be "directly >>> trusted". If so an additional flag isn't needed so much as a >>> statement >>> about how path validation proceeds if, during path discovery, it >>> turns >>> out the certificate being validated is already directly trusted. >>> >>> 2) Inclusion into the trust anchor store doesn't imply that a cert >>> is >>> trusted to issue certificates -- that is directly controlled by the >>> values within the certificate (chain). >>> >>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>> been the subject of recent BoF work (and more?). It would nice if >>> that >>> work also addressed this question. >>> >>> Issues related to this come up on a regular basis. Look at the >>> various >>> ways browser deal with caching EE certificates to "trust this site >>> always" etc. I think Bob has raised a good point. >>> >>> - max >>> >>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>> >>>> >>>> Bob, >>>> >>>> [I realize I am late to the party, and that Santosh, Steve, and =20 >>>> Wen- >>>> Chen Wang have already provided a lot of good feedback. I decided >>>> to respond to the original message because I would like to go back >>>> to the perceived requirement.] >>>> >>>> It sounds like you want to construct a list of directly trusted EE >>>> certificates, but are trying to satisfy this requirement using the >>>> application's trust anchor store. There is nothing inherently =20 >>>> wrong >>>> with direct trust (and RFC 5280 does not preclude directly trusting >>>> an EE certificate), but you really need a different - and far >>>> simpler - mechanism. The trust anchor store is implicitly linked =20 >>>> to >>>> path discovery and validation, which are not relevant here since a >>>> directly trusted certificate cannot be validated. With a directly >>>> trusted certificate, there is also no mechanism to validate status >>>> information. >>>> >>>> To further complicate matters, storing the certificate you wish to >>>> directly trust in the trust anchor store implies that it is trusted >>>> to issue certificates as well. The path validation inputs =20 >>>> specified >>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>> public key algorithm, public key, and parameters if needed). The >>>> assumption is that the trust anchor's authority to issue >>>> certificates was verified based on an out-of-band trust mechanism >>>> (which is out of scope for 5280). This makes sense since a trust >>>> anchor might have distributed a v1 certificate (which does not >>>> include extensions). >>>> >>>> As others have noted, direct trust also implies an out-of-band =20 >>>> trust >>>> mechanism. I received the EE certificate from a trusted source =20 >>>> so I >>>> can trust the binding between the subject name and the key; issuer >>>> name and the signature are irrelevant. If the certificate status >>>> matters, I am also depending on an out-of-band mechanism to inform >>>> me! The out-of-band mechanism(s) in combination with protected >>>> local storage provide the basis for security in this system... >>>> >>>> Trying to combine these two mechanisms using a single certificate >>>> store probably requires an additional flag on every entry to >>>> differentiate between directly trusted certificates and trust >>>> anchors. Two separate stores might be cleaner in the long run. >>>> >>>> Thanks, >>>> >>>> Tim Polk >>>> >>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>> >>>>> Folks- >>>>> >>>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>>> adress the case where an end-entity certificate (not a CA cert) is >>>>> installed in the trust anchor list by the user accepting the >>>>> presented cert as authoritative and then the cert is subsequently >>>>> presented (in a later access to the site). There should be no path >>>>> search, since the presented cert is in the trust anchor list. So, >>>>> where is it defined to accept the end-entity cert? >>>>> >>>>> Thanks ---- Bob >>>>> >>>>> Bob Bell >>>>> Cisco Systems, Inc. >>>>> 576 S. Brentwood Ln. >>>>> Bountiful, UT 84010 >>>>> 801-294-3034 (v) >>>>> 801-294-3023 (f) >>>>> 801-971-4200 (c) >>>>> rtbell@cisco.com >>>>> >>>> >>> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AMpHnd054089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 15:51:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AMpHZQ054088; Tue, 10 Jun 2008 15:51:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AMpECF054071 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2008 15:51:16 -0700 (MST) (envelope-from pritikin@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,620,1204498800"; d="scan'208";a="11329474" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2008 00:51:11 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5AMpBaX018828; Wed, 11 Jun 2008 00:51:11 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5AMpBar025759; Tue, 10 Jun 2008 22:51:11 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 00:51:11 +0200 Received: from [10.0.1.200] ([10.32.244.67]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 00:51:10 +0200 Cc: "Tim Polk" , "Bob Bell (rtbell)" , Message-Id: From: max pritikin To: "Santosh Chokhani" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 17:51:06 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 22:51:10.0604 (UTC) FILETIME=[7A126CC0:01C8CB4C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8403; t=1213138271; x=1214002271; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20RFC=205280=20Question |Sender:=20; bh=lX4wCJffNy60lXZkjotp5JdgHmRuI2+taD/uf9MnBN0=; b=XiWzSlYJjeitHTfcdzNW4njWBBb1OO/IgDVDYOe+trs6UIwpd0U1zD32Qf GYx4WLzaUkWUe8AOZnznOrdNXd4xPJOoaqA1Afu+6tRXPWwuNu0jj0+qN8C1 ZSrH3bxutb; Authentication-Results: ams-dkim-1; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh, you've moved the conversation back to a discussion of item (3) in my comments below: out-of-scope population of the trust anchors. I think this is orthogonal to a discussion of dealing with trust-anchors that exactly match a single certificate being validated. - max On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote: > > Max, > > I do not have any problem with successfully verifying signature made > by > a trust anchor. > > As I said a day or two back in this chain, if the relying party who > installs the certificate as a trust anchor and does not make > additional > checks of basic constraints, is susceptible to undetected compromise > of > this end entity certificate spawning an entire PKI hierarchy. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 6:17 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > We're into the realm of discussing _how_ one would modify Certificate > Path Validation to support EE certificates as a trust anchor where my > intention was only to support the concept as a discussion point. > > Santosh, it isn't that the constraints/extensions are ever applied to > the trust anchor credential itself. It is that they are applied when > validating the chain. Take for example Name Constraints or Policy > Constraints or other Basic Constraints fields such as > pathLenConstraint which are all in the trust anchor certificate and > then taken into account when validating a certificate chain. If the > trust anchor certificate does not have keyCertSign set then logically > no 'chained' certificates would be valid; just like if the > pathLenConstraint was '1' but the chain being verified has a path > length of something greater. > > I think this question of EE cert vs CA cert as a trust anchor is about > what should happen if the chain being validated consists of only the > trust anchor. Independent of any questions concerning key usage, > constraints or anything else. > > - max > > On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > >> >> Max, >> >> The text you cite does not apply to trust anchor. Please see X.509 >> and >> RFC 5280 path validation text. Nothing needs to be verified from a >> trust anchor. >> >> -----Original Message----- >> From: max pritikin [mailto:pritikin@cisco.com] >> Sent: Tuesday, June 10, 2008 4:47 PM >> To: Santosh Chokhani >> Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> Santosh, >> >> RFC5280 section 4.2.1.9 (Basic Constraints) says: >>> The cA boolean indicates whether the certified public key may be >>> used >>> to verify certificate signatures. If the cA boolean is not >>> asserted, >>> then the keyCertSign bit in the key usage extension MUST NOT be >>> asserted. If the basic constraints extension is not present in a >>> version 3 certificate, or the extension is present but the cA >>> boolean >>> is not asserted, then the certified public key MUST NOT be used to >>> verify certificate signatures. >> >> An EE certificate being in the trust store would not cause confusion >> about this. >> >> - max >> >> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: >> >>> Max, >>> >>> I do not agree with your point on item 2. Once a certificate is a >>> trust >>> anchor, neither X.509 not 5280 have any constraints on it from >>> being a >>> issuer. >>> >>> Furthermore, path length constraint if present in the self-signed >>> certificate can be ignored by relying parties. >>> >>> -----Original Message----- >>> From: owner-ietf-pkix@mail.imc.org >> [mailto:owner-ietf-pkix@mail.imc.org >>> ] >>> On Behalf Of max pritikin >>> Sent: Tuesday, June 10, 2008 2:35 PM >>> To: Tim Polk >>> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >>> Subject: Re: RFC 5280 Question >>> >>> >>> >>> A few comments on this thread: >>> >>> 1) Any entry in the trust anchor store would seem to be "directly >>> trusted". If so an additional flag isn't needed so much as a >>> statement >>> about how path validation proceeds if, during path discovery, it >>> turns >>> out the certificate being validated is already directly trusted. >>> >>> 2) Inclusion into the trust anchor store doesn't imply that a cert >>> is >>> trusted to issue certificates -- that is directly controlled by the >>> values within the certificate (chain). >>> >>> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >>> been the subject of recent BoF work (and more?). It would nice if >>> that >>> work also addressed this question. >>> >>> Issues related to this come up on a regular basis. Look at the >>> various >>> ways browser deal with caching EE certificates to "trust this site >>> always" etc. I think Bob has raised a good point. >>> >>> - max >>> >>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >>> >>>> >>>> Bob, >>>> >>>> [I realize I am late to the party, and that Santosh, Steve, and >>>> Wen- >>>> Chen Wang have already provided a lot of good feedback. I decided >>>> to respond to the original message because I would like to go back >>>> to the perceived requirement.] >>>> >>>> It sounds like you want to construct a list of directly trusted EE >>>> certificates, but are trying to satisfy this requirement using the >>>> application's trust anchor store. There is nothing inherently >>>> wrong >>>> with direct trust (and RFC 5280 does not preclude directly trusting >>>> an EE certificate), but you really need a different - and far >>>> simpler - mechanism. The trust anchor store is implicitly linked >>>> to >>>> path discovery and validation, which are not relevant here since a >>>> directly trusted certificate cannot be validated. With a directly >>>> trusted certificate, there is also no mechanism to validate status >>>> information. >>>> >>>> To further complicate matters, storing the certificate you wish to >>>> directly trust in the trust anchor store implies that it is trusted >>>> to issue certificates as well. The path validation inputs >>>> specified >>>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>>> public key algorithm, public key, and parameters if needed). The >>>> assumption is that the trust anchor's authority to issue >>>> certificates was verified based on an out-of-band trust mechanism >>>> (which is out of scope for 5280). This makes sense since a trust >>>> anchor might have distributed a v1 certificate (which does not >>>> include extensions). >>>> >>>> As others have noted, direct trust also implies an out-of-band >>>> trust >>>> mechanism. I received the EE certificate from a trusted source >>>> so I >>>> can trust the binding between the subject name and the key; issuer >>>> name and the signature are irrelevant. If the certificate status >>>> matters, I am also depending on an out-of-band mechanism to inform >>>> me! The out-of-band mechanism(s) in combination with protected >>>> local storage provide the basis for security in this system... >>>> >>>> Trying to combine these two mechanisms using a single certificate >>>> store probably requires an additional flag on every entry to >>>> differentiate between directly trusted certificates and trust >>>> anchors. Two separate stores might be cleaner in the long run. >>>> >>>> Thanks, >>>> >>>> Tim Polk >>>> >>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>>> >>>>> Folks- >>>>> >>>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>>> adress the case where an end-entity certificate (not a CA cert) is >>>>> installed in the trust anchor list by the user accepting the >>>>> presented cert as authoritative and then the cert is subsequently >>>>> presented (in a later access to the site). There should be no path >>>>> search, since the presented cert is in the trust anchor list. So, >>>>> where is it defined to accept the end-entity cert? >>>>> >>>>> Thanks ---- Bob >>>>> >>>>> Bob Bell >>>>> Cisco Systems, Inc. >>>>> 576 S. Brentwood Ln. >>>>> Bountiful, UT 84010 >>>>> 801-294-3034 (v) >>>>> 801-294-3023 (f) >>>>> 801-971-4200 (c) >>>>> rtbell@cisco.com >>>>> >>>> >>> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AMKvOx048011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 15:20:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AMKvpl048010; Tue, 10 Jun 2008 15:20:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5AMKueq048004 for ; Tue, 10 Jun 2008 15:20:56 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 4079 invoked from network); 10 Jun 2008 22:10:41 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 22:10:41 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 22:10:40 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Tue, 10 Jun 2008 18:20:54 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLR6/rbH5JTTHRTEWzJ6bfpPewtwAAC5eA References: From: "Santosh Chokhani" To: "max pritikin" Cc: "Tim Polk" , "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, I do not have any problem with successfully verifying signature made by a trust anchor. As I said a day or two back in this chain, if the relying party who installs the certificate as a trust anchor and does not make additional checks of basic constraints, is susceptible to undetected compromise of this end entity certificate spawning an entire PKI hierarchy. -----Original Message----- From: max pritikin [mailto:pritikin@cisco.com]=20 Sent: Tuesday, June 10, 2008 6:17 PM To: Santosh Chokhani Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org Subject: Re: RFC 5280 Question We're into the realm of discussing _how_ one would modify Certificate =20 Path Validation to support EE certificates as a trust anchor where my =20 intention was only to support the concept as a discussion point. Santosh, it isn't that the constraints/extensions are ever applied to =20 the trust anchor credential itself. It is that they are applied when =20 validating the chain. Take for example Name Constraints or Policy =20 Constraints or other Basic Constraints fields such as =20 pathLenConstraint which are all in the trust anchor certificate and =20 then taken into account when validating a certificate chain. If the =20 trust anchor certificate does not have keyCertSign set then logically =20 no 'chained' certificates would be valid; just like if the =20 pathLenConstraint was '1' but the chain being verified has a path =20 length of something greater. I think this question of EE cert vs CA cert as a trust anchor is about =20 what should happen if the chain being validated consists of only the =20 trust anchor. Independent of any questions concerning key usage, =20 constraints or anything else. - max On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > > Max, > > The text you cite does not apply to trust anchor. Please see X.509 =20 > and > RFC 5280 path validation text. Nothing needs to be verified from a > trust anchor. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 4:47 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > Santosh, > > RFC5280 section 4.2.1.9 (Basic Constraints) says: >> The cA boolean indicates whether the certified public key may be >> used >> to verify certificate signatures. If the cA boolean is not >> asserted, >> then the keyCertSign bit in the key usage extension MUST NOT be >> asserted. If the basic constraints extension is not present in a >> version 3 certificate, or the extension is present but the cA >> boolean >> is not asserted, then the certified public key MUST NOT be used to >> verify certificate signatures. > > An EE certificate being in the trust store would not cause confusion > about this. > > - max > > On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > >> Max, >> >> I do not agree with your point on item 2. Once a certificate is a >> trust >> anchor, neither X.509 not 5280 have any constraints on it from =20 >> being a >> issuer. >> >> Furthermore, path length constraint if present in the self-signed >> certificate can be ignored by relying parties. >> >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org >> ] >> On Behalf Of max pritikin >> Sent: Tuesday, June 10, 2008 2:35 PM >> To: Tim Polk >> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> >> A few comments on this thread: >> >> 1) Any entry in the trust anchor store would seem to be "directly >> trusted". If so an additional flag isn't needed so much as a =20 >> statement >> about how path validation proceeds if, during path discovery, it =20 >> turns >> out the certificate being validated is already directly trusted. >> >> 2) Inclusion into the trust anchor store doesn't imply that a cert =20 >> is >> trusted to issue certificates -- that is directly controlled by the >> values within the certificate (chain). >> >> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >> been the subject of recent BoF work (and more?). It would nice if =20 >> that >> work also addressed this question. >> >> Issues related to this come up on a regular basis. Look at the =20 >> various >> ways browser deal with caching EE certificates to "trust this site >> always" etc. I think Bob has raised a good point. >> >> - max >> >> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >> >>> >>> Bob, >>> >>> [I realize I am late to the party, and that Santosh, Steve, and Wen- >>> Chen Wang have already provided a lot of good feedback. I decided >>> to respond to the original message because I would like to go back >>> to the perceived requirement.] >>> >>> It sounds like you want to construct a list of directly trusted EE >>> certificates, but are trying to satisfy this requirement using the >>> application's trust anchor store. There is nothing inherently wrong >>> with direct trust (and RFC 5280 does not preclude directly trusting >>> an EE certificate), but you really need a different - and far >>> simpler - mechanism. The trust anchor store is implicitly linked to >>> path discovery and validation, which are not relevant here since a >>> directly trusted certificate cannot be validated. With a directly >>> trusted certificate, there is also no mechanism to validate status >>> information. >>> >>> To further complicate matters, storing the certificate you wish to >>> directly trust in the trust anchor store implies that it is trusted >>> to issue certificates as well. The path validation inputs specified >>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>> public key algorithm, public key, and parameters if needed). The >>> assumption is that the trust anchor's authority to issue >>> certificates was verified based on an out-of-band trust mechanism >>> (which is out of scope for 5280). This makes sense since a trust >>> anchor might have distributed a v1 certificate (which does not >>> include extensions). >>> >>> As others have noted, direct trust also implies an out-of-band trust >>> mechanism. I received the EE certificate from a trusted source so I >>> can trust the binding between the subject name and the key; issuer >>> name and the signature are irrelevant. If the certificate status >>> matters, I am also depending on an out-of-band mechanism to inform >>> me! The out-of-band mechanism(s) in combination with protected >>> local storage provide the basis for security in this system... >>> >>> Trying to combine these two mechanisms using a single certificate >>> store probably requires an additional flag on every entry to >>> differentiate between directly trusted certificates and trust >>> anchors. Two separate stores might be cleaner in the long run. >>> >>> Thanks, >>> >>> Tim Polk >>> >>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>> >>>> Folks- >>>> >>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>> adress the case where an end-entity certificate (not a CA cert) is >>>> installed in the trust anchor list by the user accepting the >>>> presented cert as authoritative and then the cert is subsequently >>>> presented (in a later access to the site). There should be no path >>>> search, since the presented cert is in the trust anchor list. So, >>>> where is it defined to accept the end-entity cert? >>>> >>>> Thanks ---- Bob >>>> >>>> Bob Bell >>>> Cisco Systems, Inc. >>>> 576 S. Brentwood Ln. >>>> Bountiful, UT 84010 >>>> 801-294-3034 (v) >>>> 801-294-3023 (f) >>>> 801-971-4200 (c) >>>> rtbell@cisco.com >>>> >>> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AMGqnN047576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 15:16:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AMGqCl047575; Tue, 10 Jun 2008 15:16:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AMGoVB047569 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2008 15:16:51 -0700 (MST) (envelope-from pritikin@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,619,1204531200"; d="scan'208";a="15454120" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 10 Jun 2008 15:16:50 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5AMGocu002580; Tue, 10 Jun 2008 15:16:50 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5AMGotj004157; Tue, 10 Jun 2008 22:16:50 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 15:16:49 -0700 Received: from [10.0.1.200] ([10.32.244.67]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 15:16:49 -0700 Cc: "Tim Polk" , "Bob Bell (rtbell)" , Message-Id: From: max pritikin To: "Santosh Chokhani" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 17:16:48 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 22:16:49.0604 (UTC) FILETIME=[AD9EC840:01C8CB47] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7195; t=1213136210; x=1214000210; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20RFC=205280=20Question |Sender:=20; bh=86qPG0S7yauOyHhYYCl7LkpXGX7y+QTIx62MTU9NHEo=; b=g24Sff8kCzcd393b6yvo+yXMZrsCuN+egwhJzUD0kOxUhELnAmOgFEGOET PxU5/cpxu9JNKuU7ElGSDT16Foe+IAs1y1cMPzwqsmgRTPffccLVUo3fOcub 3Cz8cBAjyN; Authentication-Results: sj-dkim-3; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We're into the realm of discussing _how_ one would modify Certificate Path Validation to support EE certificates as a trust anchor where my intention was only to support the concept as a discussion point. Santosh, it isn't that the constraints/extensions are ever applied to the trust anchor credential itself. It is that they are applied when validating the chain. Take for example Name Constraints or Policy Constraints or other Basic Constraints fields such as pathLenConstraint which are all in the trust anchor certificate and then taken into account when validating a certificate chain. If the trust anchor certificate does not have keyCertSign set then logically no 'chained' certificates would be valid; just like if the pathLenConstraint was '1' but the chain being verified has a path length of something greater. I think this question of EE cert vs CA cert as a trust anchor is about what should happen if the chain being validated consists of only the trust anchor. Independent of any questions concerning key usage, constraints or anything else. - max On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote: > > Max, > > The text you cite does not apply to trust anchor. Please see X.509 > and > RFC 5280 path validation text. Nothing needs to be verified from a > trust anchor. > > -----Original Message----- > From: max pritikin [mailto:pritikin@cisco.com] > Sent: Tuesday, June 10, 2008 4:47 PM > To: Santosh Chokhani > Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > Santosh, > > RFC5280 section 4.2.1.9 (Basic Constraints) says: >> The cA boolean indicates whether the certified public key may be >> used >> to verify certificate signatures. If the cA boolean is not >> asserted, >> then the keyCertSign bit in the key usage extension MUST NOT be >> asserted. If the basic constraints extension is not present in a >> version 3 certificate, or the extension is present but the cA >> boolean >> is not asserted, then the certified public key MUST NOT be used to >> verify certificate signatures. > > An EE certificate being in the trust store would not cause confusion > about this. > > - max > > On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > >> Max, >> >> I do not agree with your point on item 2. Once a certificate is a >> trust >> anchor, neither X.509 not 5280 have any constraints on it from >> being a >> issuer. >> >> Furthermore, path length constraint if present in the self-signed >> certificate can be ignored by relying parties. >> >> -----Original Message----- >> From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org >> ] >> On Behalf Of max pritikin >> Sent: Tuesday, June 10, 2008 2:35 PM >> To: Tim Polk >> Cc: Bob Bell (rtbell); ietf-pkix@imc.org >> Subject: Re: RFC 5280 Question >> >> >> >> A few comments on this thread: >> >> 1) Any entry in the trust anchor store would seem to be "directly >> trusted". If so an additional flag isn't needed so much as a >> statement >> about how path validation proceeds if, during path discovery, it >> turns >> out the certificate being validated is already directly trusted. >> >> 2) Inclusion into the trust anchor store doesn't imply that a cert >> is >> trusted to issue certificates -- that is directly controlled by the >> values within the certificate (chain). >> >> 3) The out-of-band mechanism is out of scope for 5280/3280 but has >> been the subject of recent BoF work (and more?). It would nice if >> that >> work also addressed this question. >> >> Issues related to this come up on a regular basis. Look at the >> various >> ways browser deal with caching EE certificates to "trust this site >> always" etc. I think Bob has raised a good point. >> >> - max >> >> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: >> >>> >>> Bob, >>> >>> [I realize I am late to the party, and that Santosh, Steve, and Wen- >>> Chen Wang have already provided a lot of good feedback. I decided >>> to respond to the original message because I would like to go back >>> to the perceived requirement.] >>> >>> It sounds like you want to construct a list of directly trusted EE >>> certificates, but are trying to satisfy this requirement using the >>> application's trust anchor store. There is nothing inherently wrong >>> with direct trust (and RFC 5280 does not preclude directly trusting >>> an EE certificate), but you really need a different - and far >>> simpler - mechanism. The trust anchor store is implicitly linked to >>> path discovery and validation, which are not relevant here since a >>> directly trusted certificate cannot be validated. With a directly >>> trusted certificate, there is also no mechanism to validate status >>> information. >>> >>> To further complicate matters, storing the certificate you wish to >>> directly trust in the trust anchor store implies that it is trusted >>> to issue certificates as well. The path validation inputs specified >>> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >>> public key algorithm, public key, and parameters if needed). The >>> assumption is that the trust anchor's authority to issue >>> certificates was verified based on an out-of-band trust mechanism >>> (which is out of scope for 5280). This makes sense since a trust >>> anchor might have distributed a v1 certificate (which does not >>> include extensions). >>> >>> As others have noted, direct trust also implies an out-of-band trust >>> mechanism. I received the EE certificate from a trusted source so I >>> can trust the binding between the subject name and the key; issuer >>> name and the signature are irrelevant. If the certificate status >>> matters, I am also depending on an out-of-band mechanism to inform >>> me! The out-of-band mechanism(s) in combination with protected >>> local storage provide the basis for security in this system... >>> >>> Trying to combine these two mechanisms using a single certificate >>> store probably requires an additional flag on every entry to >>> differentiate between directly trusted certificates and trust >>> anchors. Two separate stores might be cleaner in the long run. >>> >>> Thanks, >>> >>> Tim Polk >>> >>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >>> >>>> Folks- >>>> >>>> I am hoping someone can give me the answer to this. Does RFC 5280 >>>> adress the case where an end-entity certificate (not a CA cert) is >>>> installed in the trust anchor list by the user accepting the >>>> presented cert as authoritative and then the cert is subsequently >>>> presented (in a later access to the site). There should be no path >>>> search, since the presented cert is in the trust anchor list. So, >>>> where is it defined to accept the end-entity cert? >>>> >>>> Thanks ---- Bob >>>> >>>> Bob Bell >>>> Cisco Systems, Inc. >>>> 576 S. Brentwood Ln. >>>> Bountiful, UT 84010 >>>> 801-294-3034 (v) >>>> 801-294-3023 (f) >>>> 801-971-4200 (c) >>>> rtbell@cisco.com >>>> >>> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5ALaa5V038120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 14:36:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5ALaaSP038119; Tue, 10 Jun 2008 14:36:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5ALaY6Z038104 for ; Tue, 10 Jun 2008 14:36:35 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 3716 invoked from network); 10 Jun 2008 21:26:19 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 21:26:19 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 21:26:19 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Tue, 10 Jun 2008 17:36:33 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLOxZ2JF3RnRVqRGKPdcJq9azznAABsV0g References: From: "Santosh Chokhani" To: "max pritikin" Cc: "Tim Polk" , "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, The text you cite does not apply to trust anchor. Please see X.509 and RFC 5280 path validation text. Nothing needs to be verified from a trust anchor. -----Original Message----- From: max pritikin [mailto:pritikin@cisco.com]=20 Sent: Tuesday, June 10, 2008 4:47 PM To: Santosh Chokhani Cc: Tim Polk; Bob Bell (rtbell); ietf-pkix@imc.org Subject: Re: RFC 5280 Question Santosh, RFC5280 section 4.2.1.9 (Basic Constraints) says: > The cA boolean indicates whether the certified public key may be =20 > used > to verify certificate signatures. If the cA boolean is not =20 > asserted, > then the keyCertSign bit in the key usage extension MUST NOT be > asserted. If the basic constraints extension is not present in a > version 3 certificate, or the extension is present but the cA =20 > boolean > is not asserted, then the certified public key MUST NOT be used to > verify certificate signatures. An EE certificate being in the trust store would not cause confusion =20 about this. - max On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > Max, > > I do not agree with your point on item 2. Once a certificate is a =20 > trust > anchor, neither X.509 not 5280 have any constraints on it from being a > issuer. > > Furthermore, path length constraint if present in the self-signed > certificate can be ignored by relying parties. > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org=20 > ] > On Behalf Of max pritikin > Sent: Tuesday, June 10, 2008 2:35 PM > To: Tim Polk > Cc: Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > > A few comments on this thread: > > 1) Any entry in the trust anchor store would seem to be "directly > trusted". If so an additional flag isn't needed so much as a statement > about how path validation proceeds if, during path discovery, it turns > out the certificate being validated is already directly trusted. > > 2) Inclusion into the trust anchor store doesn't imply that a cert is > trusted to issue certificates -- that is directly controlled by the > values within the certificate (chain). > > 3) The out-of-band mechanism is out of scope for 5280/3280 but has > been the subject of recent BoF work (and more?). It would nice if that > work also addressed this question. > > Issues related to this come up on a regular basis. Look at the various > ways browser deal with caching EE certificates to "trust this site > always" etc. I think Bob has raised a good point. > > - max > > On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > >> >> Bob, >> >> [I realize I am late to the party, and that Santosh, Steve, and Wen- >> Chen Wang have already provided a lot of good feedback. I decided >> to respond to the original message because I would like to go back >> to the perceived requirement.] >> >> It sounds like you want to construct a list of directly trusted EE >> certificates, but are trying to satisfy this requirement using the >> application's trust anchor store. There is nothing inherently wrong >> with direct trust (and RFC 5280 does not preclude directly trusting >> an EE certificate), but you really need a different - and far >> simpler - mechanism. The trust anchor store is implicitly linked to >> path discovery and validation, which are not relevant here since a >> directly trusted certificate cannot be validated. With a directly >> trusted certificate, there is also no mechanism to validate status >> information. >> >> To further complicate matters, storing the certificate you wish to >> directly trust in the trust anchor store implies that it is trusted >> to issue certificates as well. The path validation inputs specified >> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >> public key algorithm, public key, and parameters if needed). The >> assumption is that the trust anchor's authority to issue >> certificates was verified based on an out-of-band trust mechanism >> (which is out of scope for 5280). This makes sense since a trust >> anchor might have distributed a v1 certificate (which does not >> include extensions). >> >> As others have noted, direct trust also implies an out-of-band trust >> mechanism. I received the EE certificate from a trusted source so I >> can trust the binding between the subject name and the key; issuer >> name and the signature are irrelevant. If the certificate status >> matters, I am also depending on an out-of-band mechanism to inform >> me! The out-of-band mechanism(s) in combination with protected >> local storage provide the basis for security in this system... >> >> Trying to combine these two mechanisms using a single certificate >> store probably requires an additional flag on every entry to >> differentiate between directly trusted certificates and trust >> anchors. Two separate stores might be cleaner in the long run. >> >> Thanks, >> >> Tim Polk >> >> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >> >>> Folks- >>> >>> I am hoping someone can give me the answer to this. Does RFC 5280 >>> adress the case where an end-entity certificate (not a CA cert) is >>> installed in the trust anchor list by the user accepting the >>> presented cert as authoritative and then the cert is subsequently >>> presented (in a later access to the site). There should be no path >>> search, since the presented cert is in the trust anchor list. So, >>> where is it defined to accept the end-entity cert? >>> >>> Thanks ---- Bob >>> >>> Bob Bell >>> Cisco Systems, Inc. >>> 576 S. Brentwood Ln. >>> Bountiful, UT 84010 >>> 801-294-3034 (v) >>> 801-294-3023 (f) >>> 801-971-4200 (c) >>> rtbell@cisco.com >>> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AKkgxo028097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 13:46:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AKkgPt028096; Tue, 10 Jun 2008 13:46:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AKke9J028079 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2008 13:46:41 -0700 (MST) (envelope-from pritikin@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,619,1204531200"; d="scan'208";a="78242301" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2008 13:46:40 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5AKkeZI031964; Tue, 10 Jun 2008 13:46:40 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5AKkeRh029295; Tue, 10 Jun 2008 20:46:40 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 13:46:39 -0700 Received: from [10.0.1.200] ([10.32.244.67]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 13:46:39 -0700 Cc: "Tim Polk" , "Bob Bell (rtbell)" , Message-Id: From: max pritikin To: "Santosh Chokhani" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 15:46:38 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 20:46:39.0539 (UTC) FILETIME=[14F86030:01C8CB3B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5429; t=1213130800; x=1213994800; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20RFC=205280=20Question |Sender:=20; bh=LfOXYd/w3JtKcrbizn6bXjOydJ8AkfnuROKEelxi5FA=; b=YhWyiPpHYD51tfCbi+Oq1F8PyQdlFme6eDTPEIvX3SUqyiKESlX7tD+SsA wvMz3E9p511diSydTEFmlt8t9qfJ2MaqSFUmLJlEqRRqG5lsAaUmjk3qiCvs Yx7lyKaPbw; Authentication-Results: sj-dkim-3; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh, RFC5280 section 4.2.1.9 (Basic Constraints) says: > The cA boolean indicates whether the certified public key may be > used > to verify certificate signatures. If the cA boolean is not > asserted, > then the keyCertSign bit in the key usage extension MUST NOT be > asserted. If the basic constraints extension is not present in a > version 3 certificate, or the extension is present but the cA > boolean > is not asserted, then the certified public key MUST NOT be used to > verify certificate signatures. An EE certificate being in the trust store would not cause confusion about this. - max On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote: > Max, > > I do not agree with your point on item 2. Once a certificate is a > trust > anchor, neither X.509 not 5280 have any constraints on it from being a > issuer. > > Furthermore, path length constraint if present in the self-signed > certificate can be ignored by relying parties. > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org > ] > On Behalf Of max pritikin > Sent: Tuesday, June 10, 2008 2:35 PM > To: Tim Polk > Cc: Bob Bell (rtbell); ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > > > A few comments on this thread: > > 1) Any entry in the trust anchor store would seem to be "directly > trusted". If so an additional flag isn't needed so much as a statement > about how path validation proceeds if, during path discovery, it turns > out the certificate being validated is already directly trusted. > > 2) Inclusion into the trust anchor store doesn't imply that a cert is > trusted to issue certificates -- that is directly controlled by the > values within the certificate (chain). > > 3) The out-of-band mechanism is out of scope for 5280/3280 but has > been the subject of recent BoF work (and more?). It would nice if that > work also addressed this question. > > Issues related to this come up on a regular basis. Look at the various > ways browser deal with caching EE certificates to "trust this site > always" etc. I think Bob has raised a good point. > > - max > > On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > >> >> Bob, >> >> [I realize I am late to the party, and that Santosh, Steve, and Wen- >> Chen Wang have already provided a lot of good feedback. I decided >> to respond to the original message because I would like to go back >> to the perceived requirement.] >> >> It sounds like you want to construct a list of directly trusted EE >> certificates, but are trying to satisfy this requirement using the >> application's trust anchor store. There is nothing inherently wrong >> with direct trust (and RFC 5280 does not preclude directly trusting >> an EE certificate), but you really need a different - and far >> simpler - mechanism. The trust anchor store is implicitly linked to >> path discovery and validation, which are not relevant here since a >> directly trusted certificate cannot be validated. With a directly >> trusted certificate, there is also no mechanism to validate status >> information. >> >> To further complicate matters, storing the certificate you wish to >> directly trust in the trust anchor store implies that it is trusted >> to issue certificates as well. The path validation inputs specified >> in 6.1.1 (d) consider only four aspects of a trust anchor (name, >> public key algorithm, public key, and parameters if needed). The >> assumption is that the trust anchor's authority to issue >> certificates was verified based on an out-of-band trust mechanism >> (which is out of scope for 5280). This makes sense since a trust >> anchor might have distributed a v1 certificate (which does not >> include extensions). >> >> As others have noted, direct trust also implies an out-of-band trust >> mechanism. I received the EE certificate from a trusted source so I >> can trust the binding between the subject name and the key; issuer >> name and the signature are irrelevant. If the certificate status >> matters, I am also depending on an out-of-band mechanism to inform >> me! The out-of-band mechanism(s) in combination with protected >> local storage provide the basis for security in this system... >> >> Trying to combine these two mechanisms using a single certificate >> store probably requires an additional flag on every entry to >> differentiate between directly trusted certificates and trust >> anchors. Two separate stores might be cleaner in the long run. >> >> Thanks, >> >> Tim Polk >> >> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: >> >>> Folks- >>> >>> I am hoping someone can give me the answer to this. Does RFC 5280 >>> adress the case where an end-entity certificate (not a CA cert) is >>> installed in the trust anchor list by the user accepting the >>> presented cert as authoritative and then the cert is subsequently >>> presented (in a later access to the site). There should be no path >>> search, since the presented cert is in the trust anchor list. So, >>> where is it defined to accept the end-entity cert? >>> >>> Thanks ---- Bob >>> >>> Bob Bell >>> Cisco Systems, Inc. >>> 576 S. Brentwood Ln. >>> Bountiful, UT 84010 >>> 801-294-3034 (v) >>> 801-294-3023 (f) >>> 801-971-4200 (c) >>> rtbell@cisco.com >>> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AJnHQU016536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 12:49:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AJnHnc016535; Tue, 10 Jun 2008 12:49:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ssc.lt (mail.ssc.lt [195.43.64.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AJnEeg016518 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jun 2008 12:49:15 -0700 (MST) (envelope-from md@e-net.lt) Received: from localhost ([127.0.0.1] helo=mail.ssc.lt) by mail.ssc.lt with esmtp (Exim 4.50) id 1K69pK-0008Ry-Hg; Tue, 10 Jun 2008 22:48:18 +0300 Received: from 213.226.190.190 (SquirrelMail authenticated user md@e-net.lt) by mail.ssc.lt with HTTP; Tue, 10 Jun 2008 22:48:18 +0300 (EEST) Message-ID: <27400.213.226.190.190.1213127298.squirrel@mail.ssc.lt> In-Reply-To: References: Date: Tue, 10 Jun 2008 22:48:18 +0300 (EEST) Subject: RE: RFC 5280 Question From: "Moudrick M. Dadashov" To: "Santosh Chokhani" Cc: "Bob Bell" , "Stephen Kent" , "Tom Gindin" , ietf-pkix@imc.org Reply-To: md@e-net.lt User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, can you please cc me a copy? Thanks. M.D. cell: +370-699-26662 On Tue, June 10, 2008 16:26, Santosh Chokhani wrote: > > Bob, > > Why do not you send me the cert as a zip file (do not post it to the > list) and I will tell you. > > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 11:04 PM > To: Santosh Chokhani; Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Santosh - > > So, my cert is in fact a self-signed cert (self-issued type A). Is that > correct? > > Bob > >> -----Original Message----- >> From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >> Sent: Monday, 09 June, 2008 21:01 >> To: Bob Bell (rtbell); Stephen Kent >> Cc: Tom Gindin; ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> Bob, >> >> A self-signed certificate is a self-issued certificate whose >> signature can be verified by using the subject public key in >> the certificate itself. >> >> From what you described before, it was an end entity >> certificate which you explicitly trusted. Thus, it need not >> be a self-issued certificate. >> >> If the CA issued itself an end entity certificate, it would >> be Type D as you noted. >> >> -----Original Message----- >> From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] >> Sent: Monday, June 09, 2008 10:44 PM >> To: Santosh Chokhani; Stephen Kent >> Cc: Tom Gindin; ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> Santosh - >> >> Ok. I guess I have never heard of a difference between >> self-signed and self-issued. In the case of self-signed, the >> issuer and subject is the same and there is no chain to go up >> to verify a higher authority (unless you speak of some form >> of the CRL list source or the OCSP source, in which case, >> unless you have a pre-existent trust anchor for that, there >> is no way to verify the signature of the CRL/OCSP response). >> Since I had not heard of a self-issued cert, I went to google >> and looked. I came across this url for a message thread >> discussing the various types of self-issued certificates. >> >> http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html >> >> As I read the various definitions and discussion points, it >> seems to me that my End-Entity certificate is a type D >> self-issued certificate as opposed to a self-signed >> certificate as I understood it. Does this email thread >> represent a correct opinion??? >> >> Bob >> >> > -----Original Message----- >> > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >> > Sent: Monday, 09 June, 2008 20:28 >> > To: Bob Bell (rtbell); Stephen Kent >> > Cc: Tom Gindin; ietf-pkix@imc.org >> > Subject: RE: RFC 5280 Question >> > >> > Bob, >> > >> > I hate to drag precision into this. >> > >> > Having the issuer and subject name the same does not mean >> that there >> > is no higher authority. This can be a self-issued certificate and >> > need not be self-signed. >> > >> > When a self-issued certificate is not self-signed, there can and >> > should and needs to be a trust anchor or chain of certificates >> > emanating from a trust anchor that verifies the self-issued >> > certificate. >> > >> > Security or lack thereof for self-issued certificate is >> another matter >> > outside the scope of this thread. >> > >> > -----Original Message----- >> > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] >> > Sent: Monday, June 09, 2008 9:00 PM >> > To: Santosh Chokhani; Stephen Kent >> > Cc: Tom Gindin; ietf-pkix@imc.org >> > Subject: RE: RFC 5280 Question >> > >> > Santosh - >> > >> > That is my understanding as well. If the issuer name and >> the subject >> > name are the same, then the only real thing that it >> indicates is that >> > there is no higher authority vouching for the association >> between the >> > name and private key. Hence, if you do not trust the cert as it >> > stands, there is no where else to go to get any other confirmation. >> > >> > Bob >> > >> > > -----Original Message----- >> > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >> > > Sent: Monday, 09 June, 2008 18:57 >> > > To: Bob Bell (rtbell); Stephen Kent >> > > Cc: Tom Gindin; ietf-pkix@imc.org >> > > Subject: RE: RFC 5280 Question >> > > >> > > In any certificate whose public key is used, the subject DN >> > represents >> > > the holder of the companion private. This is true for >> self-signed >> > > certificates and other trust anchor formats also. >> > > >> > > -----Original Message----- >> > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] >> > > Sent: Monday, June 09, 2008 8:11 PM >> > > To: Stephen Kent >> > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani >> > > Subject: RE: RFC 5280 Question >> > > >> > > Steve - >> > > >> > > Ok, but a selfsigned certificate (such as that from IIS) is a >> > > end-entity cert in that it does not have the CA bit set in basic >> > > constraints, but still has both the issuer and the subject >> > the same. I >> > > guess I am at a loss to figure out what to call it. >> > > >> > > Bob >> > > >> > > > -----Original Message----- >> > > > From: Stephen Kent [mailto:kent@bbn.com] >> > > > Sent: Monday, 09 June, 2008 18:02 >> > > > To: Bob Bell (rtbell) >> > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani >> > > > Subject: RE: RFC 5280 Question >> > > > >> > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: >> > > > >Tom - >> > > > > >> > > > >Actually, in our case, the cert is self-signed so the >> > > issuer and the >> > > > >subject are the same. >> > > > > >> > > > >Bob >> > > > >> > > > Bob, >> > > > >> > > > An EE is not an issuer, so there seems to be a >> > > contradiction between >> > > > what you describe and 5280, 3280, ... >> > > > >> > > > >> > > > Steve >> > > > >> > > >> > >> > > Received: from host-89-228-109-212.olsztyn.mm.pl (host-89-228-109-212.olsztyn.mm.pl [89.228.109.212]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AJP2Ee012054 for ; Tue, 10 Jun 2008 12:25:09 -0700 (MST) (envelope-from Meghan-naartedg@BYTHEBOOKPR.COM) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_owdHzUVQQNFhl1svOoSLLK)" Message-id: From: Meghan To: ietf-pkix-archive@imc.org Subject: Re: Settle for nothing less than this Date: Tue, 10 Jun 2008 21:25:09 +0200 X-Mailer: Apple Mail (2.924) --Boundary_(ID_owdHzUVQQNFhl1svOoSLLK) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT Show the girl next door what you are made of http://www.sealadat.com/ --Boundary_(ID_owdHzUVQQNFhl1svOoSLLK) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT Show the girl next door what you are made of --Boundary_(ID_owdHzUVQQNFhl1svOoSLLK)-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AJ7HMd007978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 12:07:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AJ7Hsi007977; Tue, 10 Jun 2008 12:07:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5AJ7E1V007970 for ; Tue, 10 Jun 2008 12:07:15 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 2517 invoked from network); 10 Jun 2008 18:56:59 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 18:56:59 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 18:56:58 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Tue, 10 Jun 2008 15:07:12 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLK2Y+MLoyzThUQ1CKUG5yZuLDwQAAYdNA References: From: "Santosh Chokhani" To: "max pritikin" , "Tim Polk" Cc: "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Max, I do not agree with your point on item 2. Once a certificate is a trust anchor, neither X.509 not 5280 have any constraints on it from being a issuer. Furthermore, path length constraint if present in the self-signed certificate can be ignored by relying parties. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of max pritikin Sent: Tuesday, June 10, 2008 2:35 PM To: Tim Polk Cc: Bob Bell (rtbell); ietf-pkix@imc.org Subject: Re: RFC 5280 Question A few comments on this thread: 1) Any entry in the trust anchor store would seem to be "directly =20 trusted". If so an additional flag isn't needed so much as a statement =20 about how path validation proceeds if, during path discovery, it turns =20 out the certificate being validated is already directly trusted. 2) Inclusion into the trust anchor store doesn't imply that a cert is =20 trusted to issue certificates -- that is directly controlled by the =20 values within the certificate (chain). 3) The out-of-band mechanism is out of scope for 5280/3280 but has =20 been the subject of recent BoF work (and more?). It would nice if that =20 work also addressed this question. Issues related to this come up on a regular basis. Look at the various =20 ways browser deal with caching EE certificates to "trust this site =20 always" etc. I think Bob has raised a good point. - max On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > > Bob, > > [I realize I am late to the party, and that Santosh, Steve, and Wen-=20 > Chen Wang have already provided a lot of good feedback. I decided =20 > to respond to the original message because I would like to go back =20 > to the perceived requirement.] > > It sounds like you want to construct a list of directly trusted EE =20 > certificates, but are trying to satisfy this requirement using the =20 > application's trust anchor store. There is nothing inherently wrong =20 > with direct trust (and RFC 5280 does not preclude directly trusting =20 > an EE certificate), but you really need a different - and far =20 > simpler - mechanism. The trust anchor store is implicitly linked to =20 > path discovery and validation, which are not relevant here since a =20 > directly trusted certificate cannot be validated. With a directly =20 > trusted certificate, there is also no mechanism to validate status =20 > information. > > To further complicate matters, storing the certificate you wish to =20 > directly trust in the trust anchor store implies that it is trusted =20 > to issue certificates as well. The path validation inputs specified =20 > in 6.1.1 (d) consider only four aspects of a trust anchor (name, =20 > public key algorithm, public key, and parameters if needed). The =20 > assumption is that the trust anchor's authority to issue =20 > certificates was verified based on an out-of-band trust mechanism =20 > (which is out of scope for 5280). This makes sense since a trust =20 > anchor might have distributed a v1 certificate (which does not =20 > include extensions). > > As others have noted, direct trust also implies an out-of-band trust =20 > mechanism. I received the EE certificate from a trusted source so I =20 > can trust the binding between the subject name and the key; issuer =20 > name and the signature are irrelevant. If the certificate status =20 > matters, I am also depending on an out-of-band mechanism to inform =20 > me! The out-of-band mechanism(s) in combination with protected =20 > local storage provide the basis for security in this system... > > Trying to combine these two mechanisms using a single certificate =20 > store probably requires an additional flag on every entry to =20 > differentiate between directly trusted certificates and trust =20 > anchors. Two separate stores might be cleaner in the long run. > > Thanks, > > Tim Polk > > On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > >> Folks- >> >> I am hoping someone can give me the answer to this. Does RFC 5280 =20 >> adress the case where an end-entity certificate (not a CA cert) is =20 >> installed in the trust anchor list by the user accepting the =20 >> presented cert as authoritative and then the cert is subsequently =20 >> presented (in a later access to the site). There should be no path =20 >> search, since the presented cert is in the trust anchor list. So, =20 >> where is it defined to accept the end-entity cert? >> >> Thanks ---- Bob >> >> Bob Bell >> Cisco Systems, Inc. >> 576 S. Brentwood Ln. >> Bountiful, UT 84010 >> 801-294-3034 (v) >> 801-294-3023 (f) >> 801-971-4200 (c) >> rtbell@cisco.com >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AIZReU002334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 11:35:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AIZRuo002333; Tue, 10 Jun 2008 11:35:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AIZPGC002317 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2008 11:35:26 -0700 (MST) (envelope-from pritikin@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,618,1204531200"; d="scan'208";a="40137513" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2008 11:35:12 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id m5AIZCJC027617; Tue, 10 Jun 2008 11:35:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5AIZC2I028599; Tue, 10 Jun 2008 18:35:12 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 11:35:12 -0700 Received: from [10.0.1.200] ([10.32.244.67]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 11:35:11 -0700 Cc: Bob Bell (rtbell) , Message-Id: From: max pritikin To: Tim Polk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 13:35:10 -0500 References: X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 18:35:11.0633 (UTC) FILETIME=[B7697010:01C8CB28] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4108; t=1213122912; x=1213986912; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20max=20pritikin=20 |Subject:=20Re=3A=20RFC=205280=20Question |Sender:=20; bh=MHZISWEiCpaSCbA8DJPCSqzvhtFyrLawBcGea/gUMfo=; b=Jbrmk2kGXYtYlprXB3VXvSq1ee75djfwNFdX63p78YgtzzyNR7/I+JPpuV GJJovN5zB1YeXZjyz58/P2eSafzSekxxbrIrGIVR/yPLP1qrWVd2OOfnWRcd PkH4hzWl0P; Authentication-Results: sj-dkim-8; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A few comments on this thread: 1) Any entry in the trust anchor store would seem to be "directly trusted". If so an additional flag isn't needed so much as a statement about how path validation proceeds if, during path discovery, it turns out the certificate being validated is already directly trusted. 2) Inclusion into the trust anchor store doesn't imply that a cert is trusted to issue certificates -- that is directly controlled by the values within the certificate (chain). 3) The out-of-band mechanism is out of scope for 5280/3280 but has been the subject of recent BoF work (and more?). It would nice if that work also addressed this question. Issues related to this come up on a regular basis. Look at the various ways browser deal with caching EE certificates to "trust this site always" etc. I think Bob has raised a good point. - max On Jun 10, 2008, at 12:27 PM, Tim Polk wrote: > > Bob, > > [I realize I am late to the party, and that Santosh, Steve, and Wen- > Chen Wang have already provided a lot of good feedback. I decided > to respond to the original message because I would like to go back > to the perceived requirement.] > > It sounds like you want to construct a list of directly trusted EE > certificates, but are trying to satisfy this requirement using the > application's trust anchor store. There is nothing inherently wrong > with direct trust (and RFC 5280 does not preclude directly trusting > an EE certificate), but you really need a different - and far > simpler - mechanism. The trust anchor store is implicitly linked to > path discovery and validation, which are not relevant here since a > directly trusted certificate cannot be validated. With a directly > trusted certificate, there is also no mechanism to validate status > information. > > To further complicate matters, storing the certificate you wish to > directly trust in the trust anchor store implies that it is trusted > to issue certificates as well. The path validation inputs specified > in 6.1.1 (d) consider only four aspects of a trust anchor (name, > public key algorithm, public key, and parameters if needed). The > assumption is that the trust anchor's authority to issue > certificates was verified based on an out-of-band trust mechanism > (which is out of scope for 5280). This makes sense since a trust > anchor might have distributed a v1 certificate (which does not > include extensions). > > As others have noted, direct trust also implies an out-of-band trust > mechanism. I received the EE certificate from a trusted source so I > can trust the binding between the subject name and the key; issuer > name and the signature are irrelevant. If the certificate status > matters, I am also depending on an out-of-band mechanism to inform > me! The out-of-band mechanism(s) in combination with protected > local storage provide the basis for security in this system... > > Trying to combine these two mechanisms using a single certificate > store probably requires an additional flag on every entry to > differentiate between directly trusted certificates and trust > anchors. Two separate stores might be cleaner in the long run. > > Thanks, > > Tim Polk > > On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > >> Folks- >> >> I am hoping someone can give me the answer to this. Does RFC 5280 >> adress the case where an end-entity certificate (not a CA cert) is >> installed in the trust anchor list by the user accepting the >> presented cert as authoritative and then the cert is subsequently >> presented (in a later access to the site). There should be no path >> search, since the presented cert is in the trust anchor list. So, >> where is it defined to accept the end-entity cert? >> >> Thanks ---- Bob >> >> Bob Bell >> Cisco Systems, Inc. >> 576 S. Brentwood Ln. >> Bountiful, UT 84010 >> 801-294-3034 (v) >> 801-294-3023 (f) >> 801-971-4200 (c) >> rtbell@cisco.com >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AHbnV2089396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 10:37:49 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AHbn2V089395; Tue, 10 Jun 2008 10:37:49 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AHbl0n089388 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2008 10:37:48 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,618,1204531200"; d="p7s'?scan'208";a="55423491" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2008 10:37:47 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5AHblg5005175; Tue, 10 Jun 2008 10:37:47 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5AHblts027257; Tue, 10 Jun 2008 17:37:47 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 10:37:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Tue, 10 Jun 2008 10:37:44 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0020_01C8CAEE.65D4C810" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjLH5o/QJYmHcoTTI+9xl3zcjOBuAAALHkA References: From: "Bob Bell (rtbell)" To: "Tim Polk" Cc: X-OriginalArrivalTime: 10 Jun 2008 17:37:46.0990 (UTC) FILETIME=[B23EA0E0:01C8CB20] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8591; t=1213119467; x=1213983467; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=2HLDEKsu9O296AXaZlh+39bRaE286WR8LDAdQPBSw/s=; b=ndnrLHF02tnFEzM/xF5rYgVeGzqCIYrll6dBHDYi6Z5Fzq0Sik/3M+ip47 c0XzskMBj9gaV8bIQXKOqc0r1rdtWl5pkGeTF9lvkqz7mmDNWHfG/ViwwK0N CPek1iToFP; Authentication-Results: sj-dkim-4; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C8CAEE.65D4C810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tim - I agree with your comments. The way we are using these certs is that if they do not have the CA bit set in basic constraints, then they cannot be used as a CA (i.e. they cannot vouch for additional certificates). According to everything I have read, if the CA bit is false, then it is an EE cert by definition. Two cert stores would be conceptually easier, but the constraints of openSSL make that a lot harder. I know that I am probably boring the world to death with these issues, I am simply trying to validate what is going one. Bob > -----Original Message----- > From: Tim Polk [mailto:tim.polk@nist.gov] > Sent: Tuesday, 10 June, 2008 11:28 > To: Bob Bell (rtbell) > Cc: ietf-pkix@imc.org > Subject: Re: RFC 5280 Question > > Bob, > > [I realize I am late to the party, and that Santosh, Steve, > and Wen- Chen Wang have already provided a lot of good > feedback. I decided to respond to the original message > because I would like to go back to the perceived requirement.] > > It sounds like you want to construct a list of directly > trusted EE certificates, but are trying to satisfy this > requirement using the application's trust anchor store. > There is nothing inherently wrong with direct trust (and RFC > 5280 does not preclude directly trusting an EE certificate), > but you really need a different - and far simpler > - mechanism. The trust anchor store is implicitly linked to > path discovery and validation, which are not relevant here > since a directly trusted certificate cannot be validated. > With a directly trusted certificate, there is also no > mechanism to validate status information. > > To further complicate matters, storing the certificate you > wish to directly trust in the trust anchor store implies that > it is trusted to issue certificates as well. The path > validation inputs specified in 6.1.1 (d) consider only four > aspects of a trust anchor (name, public key algorithm, public > key, and parameters if needed). The assumption is that the > trust anchor's authority to issue certificates was verified > based on an out-of-band trust mechanism (which is out of > scope for 5280). This makes sense since a trust anchor might > have distributed a v1 certificate (which does not include extensions). > > As others have noted, direct trust also implies an > out-of-band trust mechanism. I received the EE certificate > from a trusted source so I can trust the binding between the > subject name and the key; issuer > name and the signature are irrelevant. If the certificate status > matters, I am also depending on an out-of-band mechanism to > inform me! The out-of-band mechanism(s) in combination with > protected local storage provide the basis for security in > this system... > > Trying to combine these two mechanisms using a single > certificate store probably requires an additional flag on > every entry to differentiate between directly trusted > certificates and trust anchors. Two separate stores might be > cleaner in the long run. > > Thanks, > > Tim Polk > > On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > > > Folks- > > > > I am hoping someone can give me the answer to this. Does RFC 5280 > > adress the case where an end-entity certificate (not a CA cert) is > > installed in the trust anchor list by the user accepting > the presented > > cert as authoritative and then the cert is subsequently > presented (in > > a later access to the site). There should be no path > search, since the > > presented cert is in the trust anchor list. So, where is it > defined to > > accept the end-entity cert? > > > > Thanks ---- Bob > > > > Bob Bell > > Cisco Systems, Inc. > > 576 S. Brentwood Ln. > > Bountiful, UT 84010 > > 801-294-3034 (v) > > 801-294-3023 (f) > > 801-971-4200 (c) > > rtbell@cisco.com > > > > ------=_NextPart_000_0020_01C8CAEE.65D4C810 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTAxNzM3NDNaMCMGCSqGSIb3DQEJBDEWBBQ20DnsBkcgikU/MNpg dQlsEfqPFDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYCaky6DcZIa3/+YD8pzEFNwFtxaX+1ye4nzfkGi83FBCGE8YTW72mqhX4VTLoU87/Kj2qwY WbQ0pvsmNodgungngZVXEt75Kxcr7I2DrCLIU0IEyeD/mQ0pTEUeNsLAnQXpWAFVejSseEOYgNn1 1CTuBJPjiESaV5HPpXkCKMZreAAAAAAAAA== ------=_NextPart_000_0020_01C8CAEE.65D4C810-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AHTsrs087570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 10:29:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AHTsJv087568; Tue, 10 Jun 2008 10:29:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AHTpWK087544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jun 2008 10:29:53 -0700 (MST) (envelope-from tim.polk@nist.gov) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5AHRghf025464; Tue, 10 Jun 2008 13:27:42 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Content-Transfer-Encoding: 7bit From: Tim Polk Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 13:27:44 -0400 To: Bob Bell (rtbell) X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, [I realize I am late to the party, and that Santosh, Steve, and Wen- Chen Wang have already provided a lot of good feedback. I decided to respond to the original message because I would like to go back to the perceived requirement.] It sounds like you want to construct a list of directly trusted EE certificates, but are trying to satisfy this requirement using the application's trust anchor store. There is nothing inherently wrong with direct trust (and RFC 5280 does not preclude directly trusting an EE certificate), but you really need a different - and far simpler - mechanism. The trust anchor store is implicitly linked to path discovery and validation, which are not relevant here since a directly trusted certificate cannot be validated. With a directly trusted certificate, there is also no mechanism to validate status information. To further complicate matters, storing the certificate you wish to directly trust in the trust anchor store implies that it is trusted to issue certificates as well. The path validation inputs specified in 6.1.1 (d) consider only four aspects of a trust anchor (name, public key algorithm, public key, and parameters if needed). The assumption is that the trust anchor's authority to issue certificates was verified based on an out-of-band trust mechanism (which is out of scope for 5280). This makes sense since a trust anchor might have distributed a v1 certificate (which does not include extensions). As others have noted, direct trust also implies an out-of-band trust mechanism. I received the EE certificate from a trusted source so I can trust the binding between the subject name and the key; issuer name and the signature are irrelevant. If the certificate status matters, I am also depending on an out-of-band mechanism to inform me! The out-of-band mechanism(s) in combination with protected local storage provide the basis for security in this system... Trying to combine these two mechanisms using a single certificate store probably requires an additional flag on every entry to differentiate between directly trusted certificates and trust anchors. Two separate stores might be cleaner in the long run. Thanks, Tim Polk On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote: > Folks- > > I am hoping someone can give me the answer to this. Does RFC 5280 > adress the case where an end-entity certificate (not a CA cert) is > installed in the trust anchor list by the user accepting the > presented cert as authoritative and then the cert is subsequently > presented (in a later access to the site). There should be no path > search, since the presented cert is in the trust anchor list. So, > where is it defined to accept the end-entity cert? > > Thanks ---- Bob > > Bob Bell > Cisco Systems, Inc. > 576 S. Brentwood Ln. > Bountiful, UT 84010 > 801-294-3034 (v) > 801-294-3023 (f) > 801-971-4200 (c) > rtbell@cisco.com > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5ADQHkB034611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 06:26:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5ADQHkU034610; Tue, 10 Jun 2008 06:26:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5ADQFfm034603 for ; Tue, 10 Jun 2008 06:26:16 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 31777 invoked from network); 10 Jun 2008 13:16:01 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 13:16:01 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 13:15:59 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Tue, 10 Jun 2008 09:26:12 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeAAAGjVwAACjncgAACm82AAAOYWIAAAO5nQABW9MLA= References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , "Stephen Kent" Cc: "Tom Gindin" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, Why do not you send me the cert as a zip file (do not post it to the list) and I will tell you. -----Original Message----- From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 11:04 PM To: Santosh Chokhani; Stephen Kent Cc: Tom Gindin; ietf-pkix@imc.org Subject: RE: RFC 5280 Question Santosh -=20 So, my cert is in fact a self-signed cert (self-issued type A). Is that correct? Bob=20 > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 > Sent: Monday, 09 June, 2008 21:01 > To: Bob Bell (rtbell); Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question >=20 > Bob, >=20 > A self-signed certificate is a self-issued certificate whose=20 > signature can be verified by using the subject public key in=20 > the certificate itself. >=20 > From what you described before, it was an end entity=20 > certificate which you explicitly trusted. Thus, it need not=20 > be a self-issued certificate. >=20 > If the CA issued itself an end entity certificate, it would=20 > be Type D as you noted. >=20 > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 10:44 PM > To: Santosh Chokhani; Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question >=20 > Santosh - >=20 > Ok. I guess I have never heard of a difference between=20 > self-signed and self-issued. In the case of self-signed, the=20 > issuer and subject is the same and there is no chain to go up=20 > to verify a higher authority (unless you speak of some form=20 > of the CRL list source or the OCSP source, in which case,=20 > unless you have a pre-existent trust anchor for that, there=20 > is no way to verify the signature of the CRL/OCSP response).=20 > Since I had not heard of a self-issued cert, I went to google=20 > and looked. I came across this url for a message thread=20 > discussing the various types of self-issued certificates. >=20 > http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html >=20 > As I read the various definitions and discussion points, it=20 > seems to me that my End-Entity certificate is a type D=20 > self-issued certificate as opposed to a self-signed=20 > certificate as I understood it. Does this email thread=20 > represent a correct opinion??? >=20 > Bob >=20 > > -----Original Message----- > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > > Sent: Monday, 09 June, 2008 20:28 > > To: Bob Bell (rtbell); Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > >=20 > > Bob, > >=20 > > I hate to drag precision into this. > >=20 > > Having the issuer and subject name the same does not mean=20 > that there=20 > > is no higher authority. This can be a self-issued certificate and=20 > > need not be self-signed. > >=20 > > When a self-issued certificate is not self-signed, there can and=20 > > should and needs to be a trust anchor or chain of certificates=20 > > emanating from a trust anchor that verifies the self-issued=20 > > certificate. > >=20 > > Security or lack thereof for self-issued certificate is=20 > another matter=20 > > outside the scope of this thread. > >=20 > > -----Original Message----- > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > > Sent: Monday, June 09, 2008 9:00 PM > > To: Santosh Chokhani; Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > >=20 > > Santosh - > >=20 > > That is my understanding as well. If the issuer name and=20 > the subject=20 > > name are the same, then the only real thing that it=20 > indicates is that=20 > > there is no higher authority vouching for the association=20 > between the=20 > > name and private key. Hence, if you do not trust the cert as it=20 > > stands, there is no where else to go to get any other confirmation. > >=20 > > Bob > >=20 > > > -----Original Message----- > > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > > > Sent: Monday, 09 June, 2008 18:57 > > > To: Bob Bell (rtbell); Stephen Kent > > > Cc: Tom Gindin; ietf-pkix@imc.org > > > Subject: RE: RFC 5280 Question > > >=20 > > > In any certificate whose public key is used, the subject DN > > represents > > > the holder of the companion private. This is true for=20 > self-signed=20 > > > certificates and other trust anchor formats also. > > >=20 > > > -----Original Message----- > > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > > > Sent: Monday, June 09, 2008 8:11 PM > > > To: Stephen Kent > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > > Subject: RE: RFC 5280 Question > > >=20 > > > Steve - > > >=20 > > > Ok, but a selfsigned certificate (such as that from IIS) is a=20 > > > end-entity cert in that it does not have the CA bit set in basic=20 > > > constraints, but still has both the issuer and the subject > > the same. I > > > guess I am at a loss to figure out what to call it. > > >=20 > > > Bob > > >=20 > > > > -----Original Message----- > > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sent: Monday, 09 June, 2008 18:02 > > > > To: Bob Bell (rtbell) > > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > > > Subject: RE: RFC 5280 Question > > > >=20 > > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > > > > >Tom - > > > > > > > > > >Actually, in our case, the cert is self-signed so the > > > issuer and the > > > > >subject are the same. > > > > > > > > > >Bob > > > >=20 > > > > Bob, > > > >=20 > > > > An EE is not an issuer, so there seems to be a > > > contradiction between > > > > what you describe and 5280, 3280, ... > > > >=20 > > > >=20 > > > > Steve > > > >=20 > > >=20 > >=20 >=20 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AAa23d090146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 03:36:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5AAa2V1090145; Tue, 10 Jun 2008 03:36:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scan2.cht.com.tw (scan2.cht.com.tw [202.39.168.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5AAa0vO090126 for ; Tue, 10 Jun 2008 03:36:01 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from scan2.cht.com.tw (unknown [127.0.0.1]) by scan2.cht.com.tw (Symantec Mail Security) with ESMTP id 3703B1544B5; Tue, 10 Jun 2008 18:35:59 +0800 (CST) X-AuditID: 0aa00267-a819dba000000b57-af-484e590e4f67 Received: from wcwang (unknown [10.144.133.6]) by scan2.cht.com.tw (Symantec Mail Security) with SMTP id E62721544AB; Tue, 10 Jun 2008 18:35:58 +0800 (CST) Message-ID: <00c901c8cae5$c57e00f0$0685900a@wcwang> From: "Wen-Cheng Wang" To: "Bob Bell \(rtbell\)" Cc: References: Subject: Re: RFC 5280 Question Date: Tue, 10 Jun 2008 18:35:53 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, Since it is a certificate which you decide to directly trust, it does not matter whether it is self-signed, self-issued, or issued by any other entity. It even does not matter whether it is an EE certificate or a CA certificate. You do not even need to check the signature of the certificate. This directly trusted certificate can be viewed simply as a container to convey the public key and subject DN (as well as other useful information of the subject) to your applications. Since you directly trust the binding between the public key and certificate subject (which I guess it will be a device in your case), you can use the certificate as if it has passed a full certificate path validation. However, if you directly trust a certificate in that fashion, the validation of the certificate is outside of the scope of the validation algorithm of RFC 5280 (or RFC 3280). That means you have to have an out-of-band mechanism to verify and track the trustworthiness of the certificate, otherwise your applications will be fragile under man-in-the-middle attacks. Another issue you have to take into consideration is that it will be hard for the sys admin to correctly verify and track the trustworthiness of certificates if their amount becomes large. Wen-Cheng Wang ----- Original Message ----- From: "Bob Bell (rtbell)" To: "Santosh Chokhani" ; "Stephen Kent" Cc: "Tom Gindin" ; Sent: Tuesday, June 10, 2008 11:03 AM Subject: RE: RFC 5280 Question > Santosh - > > So, my cert is in fact a self-signed cert (self-issued type A). Is that > correct? > > Bob > >> -----Original Message----- >> From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >> Sent: Monday, 09 June, 2008 21:01 >> To: Bob Bell (rtbell); Stephen Kent >> Cc: Tom Gindin; ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> Bob, >> >> A self-signed certificate is a self-issued certificate whose >> signature can be verified by using the subject public key in >> the certificate itself. >> >> From what you described before, it was an end entity >> certificate which you explicitly trusted. Thus, it need not >> be a self-issued certificate. >> >> If the CA issued itself an end entity certificate, it would >> be Type D as you noted. >> >> -----Original Message----- >> From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] >> Sent: Monday, June 09, 2008 10:44 PM >> To: Santosh Chokhani; Stephen Kent >> Cc: Tom Gindin; ietf-pkix@imc.org >> Subject: RE: RFC 5280 Question >> >> Santosh - >> >> Ok. I guess I have never heard of a difference between >> self-signed and self-issued. In the case of self-signed, the >> issuer and subject is the same and there is no chain to go up >> to verify a higher authority (unless you speak of some form >> of the CRL list source or the OCSP source, in which case, >> unless you have a pre-existent trust anchor for that, there >> is no way to verify the signature of the CRL/OCSP response). >> Since I had not heard of a self-issued cert, I went to google >> and looked. I came across this url for a message thread >> discussing the various types of self-issued certificates. >> >> http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html >> >> As I read the various definitions and discussion points, it >> seems to me that my End-Entity certificate is a type D >> self-issued certificate as opposed to a self-signed >> certificate as I understood it. Does this email thread >> represent a correct opinion??? >> >> Bob >> >> > -----Original Message----- >> > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >> > Sent: Monday, 09 June, 2008 20:28 >> > To: Bob Bell (rtbell); Stephen Kent >> > Cc: Tom Gindin; ietf-pkix@imc.org >> > Subject: RE: RFC 5280 Question >> > >> > Bob, >> > >> > I hate to drag precision into this. >> > >> > Having the issuer and subject name the same does not mean >> that there >> > is no higher authority. This can be a self-issued certificate and >> > need not be self-signed. >> > >> > When a self-issued certificate is not self-signed, there can and >> > should and needs to be a trust anchor or chain of certificates >> > emanating from a trust anchor that verifies the self-issued >> > certificate. >> > >> > Security or lack thereof for self-issued certificate is >> another matter >> > outside the scope of this thread. >> > >> > -----Original Message----- >> > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] >> > Sent: Monday, June 09, 2008 9:00 PM >> > To: Santosh Chokhani; Stephen Kent >> > Cc: Tom Gindin; ietf-pkix@imc.org >> > Subject: RE: RFC 5280 Question >> > >> > Santosh - >> > >> > That is my understanding as well. If the issuer name and >> the subject >> > name are the same, then the only real thing that it >> indicates is that >> > there is no higher authority vouching for the association >> between the >> > name and private key. Hence, if you do not trust the cert as it >> > stands, there is no where else to go to get any other confirmation. >> > >> > Bob >> > >> > > -----Original Message----- >> > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >> > > Sent: Monday, 09 June, 2008 18:57 >> > > To: Bob Bell (rtbell); Stephen Kent >> > > Cc: Tom Gindin; ietf-pkix@imc.org >> > > Subject: RE: RFC 5280 Question >> > > >> > > In any certificate whose public key is used, the subject DN >> > represents >> > > the holder of the companion private. This is true for >> self-signed >> > > certificates and other trust anchor formats also. >> > > >> > > -----Original Message----- >> > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] >> > > Sent: Monday, June 09, 2008 8:11 PM >> > > To: Stephen Kent >> > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani >> > > Subject: RE: RFC 5280 Question >> > > >> > > Steve - >> > > >> > > Ok, but a selfsigned certificate (such as that from IIS) is a >> > > end-entity cert in that it does not have the CA bit set in basic >> > > constraints, but still has both the issuer and the subject >> > the same. I >> > > guess I am at a loss to figure out what to call it. >> > > >> > > Bob >> > > >> > > > -----Original Message----- >> > > > From: Stephen Kent [mailto:kent@bbn.com] >> > > > Sent: Monday, 09 June, 2008 18:02 >> > > > To: Bob Bell (rtbell) >> > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani >> > > > Subject: RE: RFC 5280 Question >> > > > >> > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: >> > > > >Tom - >> > > > > >> > > > >Actually, in our case, the cert is self-signed so the >> > > issuer and the >> > > > >subject are the same. >> > > > > >> > > > >Bob >> > > > >> > > > Bob, >> > > > >> > > > An EE is not an issuer, so there seems to be a >> > > contradiction between >> > > > what you describe and 5280, 3280, ... >> > > > >> > > > >> > > > Steve >> > > > >> > > >> > >> > Received: from [204.116.138.121] ([204.116.138.121]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A765Dk033753 for ; Tue, 10 Jun 2008 00:06:08 -0700 (MST) (envelope-from Evans-crophyte@SAMSFOODS.COM) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ltqBoBEUAJTzl0khLjNHYK)" Message-id: <8A115B42-E561-3426-1909-10D548D697D1@SAMSFOODS.COM> From: Evans To: ietf-pkix-archive@imc.org Subject: Carmen Electra drops top in mall Date: Tue, 10 Jun 2008 03:06:12 -0400 X-Mailer: Apple Mail (2.924) --Boundary_(ID_ltqBoBEUAJTzl0khLjNHYK) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT She will be the envy of her office when she tells them of your manhood http://www.grallates.com/ --Boundary_(ID_ltqBoBEUAJTzl0khLjNHYK) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT She will be the envy of her office when she tells them of your manhood --Boundary_(ID_ltqBoBEUAJTzl0khLjNHYK)-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A37d95080290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 20:07:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A37dW0080288; Mon, 9 Jun 2008 20:07:39 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A37a13080268 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 20:07:36 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,615,1204531200"; d="p7s'?scan'208";a="111015961" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2008 20:07:35 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5A37Zak011984; Mon, 9 Jun 2008 20:07:35 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5A37Zpl022180; Tue, 10 Jun 2008 03:07:35 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 20:07:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 20:03:40 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_018D_01C8CA74.4B0A9160" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeAAAGjVwAACjncgAACm82AAAOYWIAAAO5nQ References: From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , "Stephen Kent" Cc: "Tom Gindin" , X-OriginalArrivalTime: 10 Jun 2008 03:07:35.0719 (UTC) FILETIME=[21E6EB70:01C8CAA7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10001; t=1213067255; x=1213931255; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=maWwlvrni7WCC3UgxSzBb3UyW8H3gvy3yz7UconnEFo=; b=cBmDXtMnbNpv1jffqPQt+M8maOMUF5zCejn9Ie+jVg3OmSBDIAeMUjzech TvQn82cRAYYZqhLK9HO4mlZmnlXQlU1yyoZUgyAEH90gN5w5SqoULWB99kfX rhTyOhMkEDiqyQfyFf+10gUJnBdsBdLk3l7MZPem9brhoiOrlI/6w=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_018D_01C8CA74.4B0A9160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - So, my cert is in fact a self-signed cert (self-issued type A). Is that correct? Bob > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > Sent: Monday, 09 June, 2008 21:01 > To: Bob Bell (rtbell); Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Bob, > > A self-signed certificate is a self-issued certificate whose > signature can be verified by using the subject public key in > the certificate itself. > > From what you described before, it was an end entity > certificate which you explicitly trusted. Thus, it need not > be a self-issued certificate. > > If the CA issued itself an end entity certificate, it would > be Type D as you noted. > > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 10:44 PM > To: Santosh Chokhani; Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Santosh - > > Ok. I guess I have never heard of a difference between > self-signed and self-issued. In the case of self-signed, the > issuer and subject is the same and there is no chain to go up > to verify a higher authority (unless you speak of some form > of the CRL list source or the OCSP source, in which case, > unless you have a pre-existent trust anchor for that, there > is no way to verify the signature of the CRL/OCSP response). > Since I had not heard of a self-issued cert, I went to google > and looked. I came across this url for a message thread > discussing the various types of self-issued certificates. > > http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html > > As I read the various definitions and discussion points, it > seems to me that my End-Entity certificate is a type D > self-issued certificate as opposed to a self-signed > certificate as I understood it. Does this email thread > represent a correct opinion??? > > Bob > > > -----Original Message----- > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > > Sent: Monday, 09 June, 2008 20:28 > > To: Bob Bell (rtbell); Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > > > > Bob, > > > > I hate to drag precision into this. > > > > Having the issuer and subject name the same does not mean > that there > > is no higher authority. This can be a self-issued certificate and > > need not be self-signed. > > > > When a self-issued certificate is not self-signed, there can and > > should and needs to be a trust anchor or chain of certificates > > emanating from a trust anchor that verifies the self-issued > > certificate. > > > > Security or lack thereof for self-issued certificate is > another matter > > outside the scope of this thread. > > > > -----Original Message----- > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > > Sent: Monday, June 09, 2008 9:00 PM > > To: Santosh Chokhani; Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > > > > Santosh - > > > > That is my understanding as well. If the issuer name and > the subject > > name are the same, then the only real thing that it > indicates is that > > there is no higher authority vouching for the association > between the > > name and private key. Hence, if you do not trust the cert as it > > stands, there is no where else to go to get any other confirmation. > > > > Bob > > > > > -----Original Message----- > > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > > > Sent: Monday, 09 June, 2008 18:57 > > > To: Bob Bell (rtbell); Stephen Kent > > > Cc: Tom Gindin; ietf-pkix@imc.org > > > Subject: RE: RFC 5280 Question > > > > > > In any certificate whose public key is used, the subject DN > > represents > > > the holder of the companion private. This is true for > self-signed > > > certificates and other trust anchor formats also. > > > > > > -----Original Message----- > > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > > > Sent: Monday, June 09, 2008 8:11 PM > > > To: Stephen Kent > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > > Subject: RE: RFC 5280 Question > > > > > > Steve - > > > > > > Ok, but a selfsigned certificate (such as that from IIS) is a > > > end-entity cert in that it does not have the CA bit set in basic > > > constraints, but still has both the issuer and the subject > > the same. I > > > guess I am at a loss to figure out what to call it. > > > > > > Bob > > > > > > > -----Original Message----- > > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sent: Monday, 09 June, 2008 18:02 > > > > To: Bob Bell (rtbell) > > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > > > Subject: RE: RFC 5280 Question > > > > > > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > > > > >Tom - > > > > > > > > > >Actually, in our case, the cert is self-signed so the > > > issuer and the > > > > >subject are the same. > > > > > > > > > >Bob > > > > > > > > Bob, > > > > > > > > An EE is not an issuer, so there seems to be a > > > contradiction between > > > > what you describe and 5280, 3280, ... > > > > > > > > > > > > Steve > > > > > > > > > > ------=_NextPart_000_018D_01C8CA74.4B0A9160 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTAwMzAzNDBaMCMGCSqGSIb3DQEJBDEWBBRjEi9f8PANJhZytCqg Q24IqFjM3jBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYAitptNQiZpi4K+v2zfj/2oDj3qi2Cbb4V9p2repawlwcU7sLXVH6474S11WPKA0E5JTO09 QC1kZAgGdFYxv42wG2Bev2nXjNmbTKwkYT+4+KOllmABnVA/Arr2eweZiziY/SD6TycPknngVL/f X7qkSgDkL6zD4OD8gstjEnviRgAAAAAAAA== ------=_NextPart_000_018D_01C8CA74.4B0A9160-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A30sZS078774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 20:00:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A30s2s078773; Mon, 9 Jun 2008 20:00:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5A30p2h078752 for ; Mon, 9 Jun 2008 20:00:52 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 25920 invoked from network); 10 Jun 2008 02:50:37 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 02:50:37 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 02:50:37 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 23:00:50 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeAAAGjVwAACjncgAACm82AAAOYWIA== References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , "Stephen Kent" Cc: "Tom Gindin" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, A self-signed certificate is a self-issued certificate whose signature can be verified by using the subject public key in the certificate itself. >From what you described before, it was an end entity certificate which you explicitly trusted. Thus, it need not be a self-issued certificate. If the CA issued itself an end entity certificate, it would be Type D as you noted. -----Original Message----- From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 10:44 PM To: Santosh Chokhani; Stephen Kent Cc: Tom Gindin; ietf-pkix@imc.org Subject: RE: RFC 5280 Question Santosh - Ok. I guess I have never heard of a difference between self-signed and self-issued. In the case of self-signed, the issuer and subject is the same and there is no chain to go up to verify a higher authority (unless you speak of some form of the CRL list source or the OCSP source, in which case, unless you have a pre-existent trust anchor for that, there is no way to verify the signature of the CRL/OCSP response). Since I had not heard of a self-issued cert, I went to google and looked. I came across this url for a message thread discussing the various types of self-issued certificates. http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html As I read the various definitions and discussion points, it seems to me that my End-Entity certificate is a type D self-issued certificate as opposed to a self-signed certificate as I understood it. Does this email thread represent a correct opinion??? Bob > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 > Sent: Monday, 09 June, 2008 20:28 > To: Bob Bell (rtbell); Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question >=20 > Bob, >=20 > I hate to drag precision into this. >=20 > Having the issuer and subject name the same does not mean=20 > that there is no higher authority. This can be a self-issued=20 > certificate and need not be self-signed. >=20 > When a self-issued certificate is not self-signed, there can=20 > and should and needs to be a trust anchor or chain of=20 > certificates emanating from a trust anchor that verifies the=20 > self-issued certificate. >=20 > Security or lack thereof for self-issued certificate is=20 > another matter outside the scope of this thread. >=20 > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 9:00 PM > To: Santosh Chokhani; Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question >=20 > Santosh -=20 >=20 > That is my understanding as well. If the issuer name and the=20 > subject name are the same, then the only real thing that it=20 > indicates is that there is no higher authority vouching for=20 > the association between the name and private key. Hence, if=20 > you do not trust the cert as it stands, there is no where=20 > else to go to get any other confirmation. >=20 > Bob=20 >=20 > > -----Original Message----- > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > > Sent: Monday, 09 June, 2008 18:57 > > To: Bob Bell (rtbell); Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > >=20 > > In any certificate whose public key is used, the subject DN=20 > represents=20 > > the holder of the companion private. This is true for self-signed=20 > > certificates and other trust anchor formats also. > >=20 > > -----Original Message----- > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > > Sent: Monday, June 09, 2008 8:11 PM > > To: Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > Subject: RE: RFC 5280 Question > >=20 > > Steve - > >=20 > > Ok, but a selfsigned certificate (such as that from IIS) is a=20 > > end-entity cert in that it does not have the CA bit set in basic=20 > > constraints, but still has both the issuer and the subject=20 > the same. I=20 > > guess I am at a loss to figure out what to call it. > >=20 > > Bob > >=20 > > > -----Original Message----- > > > From: Stephen Kent [mailto:kent@bbn.com] > > > Sent: Monday, 09 June, 2008 18:02 > > > To: Bob Bell (rtbell) > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > > Subject: RE: RFC 5280 Question > > >=20 > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > > > >Tom - > > > > > > > >Actually, in our case, the cert is self-signed so the > > issuer and the > > > >subject are the same. > > > > > > > >Bob > > >=20 > > > Bob, > > >=20 > > > An EE is not an issuer, so there seems to be a > > contradiction between > > > what you describe and 5280, 3280, ... > > >=20 > > >=20 > > > Steve > > >=20 > >=20 >=20 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A2iOW5074573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 19:44:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A2iOMv074572; Mon, 9 Jun 2008 19:44:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A2iNBa074556 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 19:44:23 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,615,1204531200"; d="p7s'?scan'208";a="55127054" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Jun 2008 19:44:10 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5A2iAsp021602; Mon, 9 Jun 2008 19:44:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5A2iArF029238; Tue, 10 Jun 2008 02:44:10 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 19:44:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 19:44:07 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0172_01C8CA71.8FC44920" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeAAAGjVwAACjncgAACm82A= References: From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , "Stephen Kent" Cc: "Tom Gindin" , X-OriginalArrivalTime: 10 Jun 2008 02:44:10.0674 (UTC) FILETIME=[DC6E1120:01C8CAA3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8720; t=1213065850; x=1213929850; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=D/7N812G86HATRMYKbgPGSbdgOlgeJIgZ+wq1Nazs2A=; b=aGJKh8JiQF4s9J0+WnK+LARB8jTBpDTDqXmwPz8/NuguRdwO3c4PiHGV5/ d4toL4vmqVOFafnGynraut67YI2U3j9crmtK0PD+5eB6EDr1DeKWFxSF/nQR +LAU8JhSSba/ewlBx9YVGM2pTveUQZmwtWCs2bO0jPi3w51CU/jhI=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0172_01C8CA71.8FC44920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - Ok. I guess I have never heard of a difference between self-signed and self-issued. In the case of self-signed, the issuer and subject is the same and there is no chain to go up to verify a higher authority (unless you speak of some form of the CRL list source or the OCSP source, in which case, unless you have a pre-existent trust anchor for that, there is no way to verify the signature of the CRL/OCSP response). Since I had not heard of a self-issued cert, I went to google and looked. I came across this url for a message thread discussing the various types of self-issued certificates. http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html As I read the various definitions and discussion points, it seems to me that my End-Entity certificate is a type D self-issued certificate as opposed to a self-signed certificate as I understood it. Does this email thread represent a correct opinion??? Bob > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > Sent: Monday, 09 June, 2008 20:28 > To: Bob Bell (rtbell); Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Bob, > > I hate to drag precision into this. > > Having the issuer and subject name the same does not mean > that there is no higher authority. This can be a self-issued > certificate and need not be self-signed. > > When a self-issued certificate is not self-signed, there can > and should and needs to be a trust anchor or chain of > certificates emanating from a trust anchor that verifies the > self-issued certificate. > > Security or lack thereof for self-issued certificate is > another matter outside the scope of this thread. > > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 9:00 PM > To: Santosh Chokhani; Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Santosh - > > That is my understanding as well. If the issuer name and the > subject name are the same, then the only real thing that it > indicates is that there is no higher authority vouching for > the association between the name and private key. Hence, if > you do not trust the cert as it stands, there is no where > else to go to get any other confirmation. > > Bob > > > -----Original Message----- > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > > Sent: Monday, 09 June, 2008 18:57 > > To: Bob Bell (rtbell); Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: RE: RFC 5280 Question > > > > In any certificate whose public key is used, the subject DN > represents > > the holder of the companion private. This is true for self-signed > > certificates and other trust anchor formats also. > > > > -----Original Message----- > > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > > Sent: Monday, June 09, 2008 8:11 PM > > To: Stephen Kent > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > Subject: RE: RFC 5280 Question > > > > Steve - > > > > Ok, but a selfsigned certificate (such as that from IIS) is a > > end-entity cert in that it does not have the CA bit set in basic > > constraints, but still has both the issuer and the subject > the same. I > > guess I am at a loss to figure out what to call it. > > > > Bob > > > > > -----Original Message----- > > > From: Stephen Kent [mailto:kent@bbn.com] > > > Sent: Monday, 09 June, 2008 18:02 > > > To: Bob Bell (rtbell) > > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > > Subject: RE: RFC 5280 Question > > > > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > > > >Tom - > > > > > > > >Actually, in our case, the cert is self-signed so the > > issuer and the > > > >subject are the same. > > > > > > > >Bob > > > > > > Bob, > > > > > > An EE is not an issuer, so there seems to be a > > contradiction between > > > what you describe and 5280, 3280, ... > > > > > > > > > Steve > > > > > > ------=_NextPart_000_0172_01C8CA71.8FC44920 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTAwMjQ0MDdaMCMGCSqGSIb3DQEJBDEWBBSLiBGsoBVU6FVpD65w VGrusSF/EjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYA8arFJlEQEpFh4ldi0X6gQEQN/eBXHaGyK6VJdMHc30f+bkhzDJkzwGDWEciE8BXnAoQVO T8jNesuc/gWHXfO+LubpN9Agoq3HtTHouhIwLgSRo261A98ZGPiYbdgD6Z3SP61iCPdBut6784mG CECZXq0AJ8GYhCr9Hv05Q8YN+QAAAAAAAA== ------=_NextPart_000_0172_01C8CA71.8FC44920-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A2Rwlo070298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 19:27:58 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A2RwIi070297; Mon, 9 Jun 2008 19:27:58 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5A2RuW3070282 for ; Mon, 9 Jun 2008 19:27:57 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 25722 invoked from network); 10 Jun 2008 02:17:42 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 02:17:42 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 02:17:42 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 22:27:55 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeAAAGjVwAACjncg References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , "Stephen Kent" Cc: "Tom Gindin" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob, I hate to drag precision into this. Having the issuer and subject name the same does not mean that there is no higher authority. This can be a self-issued certificate and need not be self-signed. When a self-issued certificate is not self-signed, there can and should and needs to be a trust anchor or chain of certificates emanating from a trust anchor that verifies the self-issued certificate. Security or lack thereof for self-issued certificate is another matter outside the scope of this thread. -----Original Message----- From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 9:00 PM To: Santosh Chokhani; Stephen Kent Cc: Tom Gindin; ietf-pkix@imc.org Subject: RE: RFC 5280 Question Santosh -=20 That is my understanding as well. If the issuer name and the subject name are the same, then the only real thing that it indicates is that there is no higher authority vouching for the association between the name and private key. Hence, if you do not trust the cert as it stands, there is no where else to go to get any other confirmation. Bob=20 > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 > Sent: Monday, 09 June, 2008 18:57 > To: Bob Bell (rtbell); Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question >=20 > In any certificate whose public key is used, the subject DN=20 > represents the holder of the companion private. This is true=20 > for self-signed certificates and other trust anchor formats also. >=20 > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 8:11 PM > To: Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > Subject: RE: RFC 5280 Question >=20 > Steve - >=20 > Ok, but a selfsigned certificate (such as that from IIS) is a=20 > end-entity cert in that it does not have the CA bit set in=20 > basic constraints, but still has both the issuer and the=20 > subject the same. I guess I am at a loss to figure out what=20 > to call it. >=20 > Bob=20 >=20 > > -----Original Message----- > > From: Stephen Kent [mailto:kent@bbn.com] > > Sent: Monday, 09 June, 2008 18:02 > > To: Bob Bell (rtbell) > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > Subject: RE: RFC 5280 Question > >=20 > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > > >Tom - > > > > > >Actually, in our case, the cert is self-signed so the=20 > issuer and the=20 > > >subject are the same. > > > > > >Bob > >=20 > > Bob, > >=20 > > An EE is not an issuer, so there seems to be a=20 > contradiction between=20 > > what you describe and 5280, 3280, ... > >=20 > >=20 > > Steve > >=20 >=20 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A10T1u050505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 18:00:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A10T4C050504; Mon, 9 Jun 2008 18:00:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A10RfT050488 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 18:00:28 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,615,1204531200"; d="p7s'?scan'208";a="110973072" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2008 18:00:27 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5A10Qgb027077; Mon, 9 Jun 2008 18:00:26 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5A10Qnh008568; Tue, 10 Jun 2008 01:00:26 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 18:00:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 18:00:23 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_015C_01C8CA63.1247FD60" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeAAAGjVwA== References: From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , "Stephen Kent" Cc: "Tom Gindin" , X-OriginalArrivalTime: 10 Jun 2008 01:00:26.0781 (UTC) FILETIME=[5EB35CD0:01C8CA95] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6599; t=1213059626; x=1213923626; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=scO/61m2IILOyNGogUtx7eEoMxPjsnWuSsqpwn1HrFw=; b=mB3EognUDPQ98OOnr78w6ejSGVP7BJR5Q0/R5i1xDzy44ext9rCFPPXfbL fkigw59+HcIHnPk6K+lPvPYkcF3T9DmiUiQuazK+OfyRd+YktWflqxmja50P TfjEU+XctY; Authentication-Results: sj-dkim-4; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_015C_01C8CA63.1247FD60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - That is my understanding as well. If the issuer name and the subject name are the same, then the only real thing that it indicates is that there is no higher authority vouching for the association between the name and private key. Hence, if you do not trust the cert as it stands, there is no where else to go to get any other confirmation. Bob > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > Sent: Monday, 09 June, 2008 18:57 > To: Bob Bell (rtbell); Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > In any certificate whose public key is used, the subject DN > represents the holder of the companion private. This is true > for self-signed certificates and other trust anchor formats also. > > -----Original Message----- > From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] > Sent: Monday, June 09, 2008 8:11 PM > To: Stephen Kent > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > Subject: RE: RFC 5280 Question > > Steve - > > Ok, but a selfsigned certificate (such as that from IIS) is a > end-entity cert in that it does not have the CA bit set in > basic constraints, but still has both the issuer and the > subject the same. I guess I am at a loss to figure out what > to call it. > > Bob > > > -----Original Message----- > > From: Stephen Kent [mailto:kent@bbn.com] > > Sent: Monday, 09 June, 2008 18:02 > > To: Bob Bell (rtbell) > > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > > Subject: RE: RFC 5280 Question > > > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > > >Tom - > > > > > >Actually, in our case, the cert is self-signed so the > issuer and the > > >subject are the same. > > > > > >Bob > > > > Bob, > > > > An EE is not an issuer, so there seems to be a > contradiction between > > what you describe and 5280, 3280, ... > > > > > > Steve > > > ------=_NextPart_000_015C_01C8CA63.1247FD60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTAwMTAwMjNaMCMGCSqGSIb3DQEJBDEWBBRtu+7+wHQ6S/mbtyT3 Aom9RfeEcjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYADociCJd5RcOXqFmOzlcdSUFersz4kiY1Is7ZkSC5MPFl5oGgB9Fv7uoqYEEMO7G6K1tzj uJrex+nIwClgBZsviLnC65DeEArxnvQGPVHq/gmgRi0duHEv9f2dMTuwh8q9TGBAERpqHHw18XIY RehLCJp3MGPFPabQGHMlnjGSigAAAAAAAA== ------=_NextPart_000_015C_01C8CA63.1247FD60-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A0vKW4050062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 17:57:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A0vKWn050061; Mon, 9 Jun 2008 17:57:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m5A0vJAx050052 for ; Mon, 9 Jun 2008 17:57:19 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 25100 invoked from network); 10 Jun 2008 00:47:05 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jun 2008 00:47:05 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Jun 2008 00:47:05 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 20:57:17 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxAAAFQSeA= References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , "Stephen Kent" Cc: "Tom Gindin" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In any certificate whose public key is used, the subject DN represents the holder of the companion private. This is true for self-signed certificates and other trust anchor formats also. -----Original Message----- From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 8:11 PM To: Stephen Kent Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani Subject: RE: RFC 5280 Question Steve - Ok, but a selfsigned certificate (such as that from IIS) is a end-entity cert in that it does not have the CA bit set in basic constraints, but still has both the issuer and the subject the same. I guess I am at a loss to figure out what to call it. Bob=20 > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com]=20 > Sent: Monday, 09 June, 2008 18:02 > To: Bob Bell (rtbell) > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > Subject: RE: RFC 5280 Question >=20 > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > >Tom - > > > >Actually, in our case, the cert is self-signed so the issuer and the=20 > >subject are the same. > > > >Bob >=20 > Bob, >=20 > An EE is not an issuer, so there seems to be a contradiction=20 > between what you describe and 5280, 3280, ... >=20 >=20 > Steve >=20 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A0BCdN039601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 17:11:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A0BBLT039599; Mon, 9 Jun 2008 17:11:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A0B9T9039583 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 17:11:10 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,614,1204531200"; d="p7s'?scan'208";a="31319227" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 09 Jun 2008 17:11:08 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5A0B8KW029824; Mon, 9 Jun 2008 17:11:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5A0B80M018761; Tue, 10 Jun 2008 00:11:08 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 17:11:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 17:11:05 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0152_01C8CA5C.2F236570" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKjUmEhPn1d1sUTNOonjyqpfqWEAAAPQxA References: From: "Bob Bell (rtbell)" To: "Stephen Kent" Cc: "Tom Gindin" , , "Santosh Chokhani" X-OriginalArrivalTime: 10 Jun 2008 00:11:08.0715 (UTC) FILETIME=[7B8E4FB0:01C8CA8E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5469; t=1213056669; x=1213920669; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=cW/T0SlrIVIv3eDuJ8nd4V5yqEWZvupKzMXKpek2Bf4=; b=ELcK+Sv/XgSymOVuuDcO8+LChAdu6xImcD8oWgTVcCbf7n3xghQ+C+Udc0 KZaxvyTc8/v1X1nFMwpXlrlA5b0wWmgnnn0F74X8dkkgpfc4aut6cJogeLQA Ung+C4myBq3YxvGeQMJTgVT3YodaMz+H72H6UgqADIQ52mdqBjuWo=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0152_01C8CA5C.2F236570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Steve - Ok, but a selfsigned certificate (such as that from IIS) is a end-entity cert in that it does not have the CA bit set in basic constraints, but still has both the issuer and the subject the same. I guess I am at a loss to figure out what to call it. Bob > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Monday, 09 June, 2008 18:02 > To: Bob Bell (rtbell) > Cc: Tom Gindin; ietf-pkix@imc.org; Santosh Chokhani > Subject: RE: RFC 5280 Question > > At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: > >Tom - > > > >Actually, in our case, the cert is self-signed so the issuer and the > >subject are the same. > > > >Bob > > Bob, > > An EE is not an issuer, so there seems to be a contradiction > between what you describe and 5280, 3280, ... > > > Steve > ------=_NextPart_000_0152_01C8CA5C.2F236570 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MTAwMDExMDVaMCMGCSqGSIb3DQEJBDEWBBRlmA/MYWfslIBUEC47 U0QbJmqzPzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYBcJ5t3wxBKBv7rpRE0BuPDRVYH5FD6smhr5wpS51SKLMbkHnBxOxaAAFA19q2l3fL8lNHE vrR8ybC++JYpftR+qVnmEwtqIT7HyH5asYElxDWf9/cklKhHwB1ZVisNY+LSzIUQ+XTh2UZ7oJt8 GKXz1RK89pt3c8lLG3HAXQrZsQAAAAAAAA== ------=_NextPart_000_0152_01C8CA5C.2F236570-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A02DF0037421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 17:02:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5A02DO9037420; Mon, 9 Jun 2008 17:02:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5A02Ca4037411 for ; Mon, 9 Jun 2008 17:02:13 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.28.172.170]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1K5rJT-0003an-4E; Mon, 09 Jun 2008 20:02:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 9 Jun 2008 20:02:19 -0400 To: "Bob Bell (rtbell)" From: Stephen Kent Subject: RE: RFC 5280 Question Cc: "Tom Gindin" , , "Santosh Chokhani" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 4:24 PM -0700 6/9/08, Bob Bell (rtbell) wrote: >Tom - > >Actually, in our case, the cert is self-signed so the issuer and the subject >are the same. > >Bob Bob, An EE is not an issuer, so there seems to be a contradiction between what you describe and 5280, 3280, ... Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59NvE1B036109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 16:57:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59NvEOx036108; Mon, 9 Jun 2008 16:57:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m59NvDdt036093 for ; Mon, 9 Jun 2008 16:57:13 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 24752 invoked from network); 9 Jun 2008 23:46:58 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;09 Jun 2008 23:46:58 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 9 Jun 2008 23:46:58 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 19:57:10 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKhPrpQbIEMXPvS1iaKmqpo/XJpgAAs4FQAAEiLIA= References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , "Tom Gindin" Cc: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Issuer name topic is a digression. You can probably find some e-mail exchange on PKIX on it. A Trust Anchor always has a subject name, otherwise name chaining will not work. I recall editor of 5280 (Dave Cooper) agreeing to that fact on this mail thread. -----Original Message----- From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 7:24 PM To: Tom Gindin Cc: ietf-pkix@imc.org; Santosh Chokhani Subject: RE: RFC 5280 Question Tom -=20 Actually, in our case, the cert is self-signed so the issuer and the subject are the same. Bob=20 > -----Original Message----- > From: Tom Gindin [mailto:tgindin@us.ibm.com]=20 > Sent: Monday, 09 June, 2008 17:03 > To: Bob Bell (rtbell) > Cc: ietf-pkix@imc.org; Santosh Chokhani > Subject: RE: RFC 5280 Question >=20 > Bob: >=20 > It looks to me as if RFC 5280 section 6 presumes that=20 > a trust anchor represents an issuer, rather than permitting=20 > EE's. If you consider the fields in 6.1.1, they include an=20 > issuer name but no subject name. One of the conditions which=20 > basic path validation is expected to verify is "certificate 1=20 > is issued by the trust anchor". When the EE certificate is=20 > directly trusted, this condition will never be true, since no=20 > certificate exists which was issued by the trust anchor. > While no certificate which contains keyUsage with=20 > keyCertSign not set can be used as an intermediate CA=20 > certificate (see 6.1.4-n), section > 6.1.4 doesn't execute against the trust anchor so=20 > verification isn't expected to reject the use of a directly=20 > trusted certificate as a CA=20 > certificate. Section 6 isn't designed to handle a directly=20 > trusted EE certificate. I think that you could tweak this by=20 > defining a trust anchor using the CA's certificate, with a=20 > name constraint which permits your EE's DN and no other using=20 > initial-permitted-subtrees, although you'd be trusting the CA=20 > to reserve that DN for the entity you want. That way you'd=20 > get revocation check as well. Alternatively, you could write=20 > your own algorithm for directly trusting EE certificates. >=20 > Tom Gindin >=20 >=20 >=20 >=20 >=20 > "Bob Bell (rtbell)" > Sent by: owner-ietf-pkix@mail.imc.org > 06/09/2008 03:32 PM >=20 > To > "Santosh Chokhani" , cc >=20 > Subject > RE: RFC 5280 Question >=20 >=20 >=20 >=20 >=20 >=20 > Santosh, et al - > =20 > I appreciate your response. I agree that there is a potential=20 > to have a problem if the acceptance/provisioning of trusted=20 > certs is not done securely. However, in this case, we are=20 > being very careful with that issue. > =20 > As to the "spawning a bogus hierarchy", if the cert in the=20 > trust list does not have the CA bit set in the usage, then it=20 > cannot be used to sign other certs, and thus cannot create=20 > this false hierarchy. Is that correct? > =20 > Bob >=20 > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > Sent: Monday, 09 June, 2008 11:42 > To: Bob Bell (rtbell); ietf-pkix@imc.org > Subject: RE: RFC 5280 Question >=20 > Bob, > =20 > Neither X.509 nor 5280 explicitly address this. > =20 > But, one can safely assume that the standards imply that if a=20 > trusted certificate public key is required, there is no need=20 > for path development and validation. > =20 > That said, trusting an end certificate could invite security=20 > trouble depending on how this trusted certificate is handled. > =20 > As mentioned below ?trust anchor list? could be problematic. =20 > X.509 and 5280 do not require any checks on trust anchors and=20 > hence this end certificate could spawn a bogus hierarchy and=20 > the PK enabled applications could legitimately accept that hierarchy. >=20 > From: owner-ietf-pkix@mail.imc.org=20 > [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Bob Bell (rtbell) > Sent: Monday, June 09, 2008 12:29 PM > To: ietf-pkix@imc.org > Subject: RFC 5280 Question > =20 > Folks- > =20 > I am hoping someone can give me the answer to this. Does RFC=20 > 5280 adress the case where an end-entity certificate (not a=20 > CA cert) is installed in the trust anchor list by the user=20 > accepting the presented cert as authoritative and then the=20 > cert is subsequently presented (in a later access to the=20 > site). There should be no path search, since the presented=20 > cert is in the trust anchor list. So, where is it defined to=20 > accept the end-entity cert? > =20 > Thanks ---- Bob > =20 > Bob Bell > Cisco Systems, Inc. > 576 S. Brentwood Ln. > Bountiful, UT 84010 > 801-294-3034 (v) > 801-294-3023 (f) > 801-971-4200 (c) > rtbell@cisco.com > =20 >=20 >=20 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59NOL81030048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 16:24:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59NOLeq030047; Mon, 9 Jun 2008 16:24:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59NOJBS030033 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 16:24:19 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,614,1204531200"; d="p7s'?scan'208";a="110938271" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2008 16:24:13 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m59NODGM012877; Mon, 9 Jun 2008 16:24:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m59NODK9011473; Mon, 9 Jun 2008 23:24:13 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 16:24:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 16:24:10 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0141_01C8CA55.A13B0610" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKhPrpQbIEMXPvS1iaKmqpo/XJpgAAs4FQ References: From: "Bob Bell (rtbell)" To: "Tom Gindin" Cc: , "Santosh Chokhani" X-OriginalArrivalTime: 09 Jun 2008 23:24:13.0553 (UTC) FILETIME=[ED96AE10:01C8CA87] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8884; t=1213053853; x=1213917853; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=8m7jSHdHCoQ1a2JpZWo78/BARgQAPwjZj+BKjQBNp3Q=; b=Qh+J/NdweLlYuZ4W9+qY0JY8sTqlbXe46OJP8lL0OIu1y14A/55jD0jBUF UcvNf+iOeJjd7+N3kjBskY0Haau2HLdjlUtaUcN77M/7WQg4G+BA7WaskXQR Ah0Erdpdld; Authentication-Results: sj-dkim-3; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0141_01C8CA55.A13B0610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom - Actually, in our case, the cert is self-signed so the issuer and the subject are the same. Bob > -----Original Message----- > From: Tom Gindin [mailto:tgindin@us.ibm.com] > Sent: Monday, 09 June, 2008 17:03 > To: Bob Bell (rtbell) > Cc: ietf-pkix@imc.org; Santosh Chokhani > Subject: RE: RFC 5280 Question > > Bob: > > It looks to me as if RFC 5280 section 6 presumes that > a trust anchor represents an issuer, rather than permitting > EE's. If you consider the fields in 6.1.1, they include an > issuer name but no subject name. One of the conditions which > basic path validation is expected to verify is "certificate 1 > is issued by the trust anchor". When the EE certificate is > directly trusted, this condition will never be true, since no > certificate exists which was issued by the trust anchor. > While no certificate which contains keyUsage with > keyCertSign not set can be used as an intermediate CA > certificate (see 6.1.4-n), section > 6.1.4 doesn't execute against the trust anchor so > verification isn't expected to reject the use of a directly > trusted certificate as a CA > certificate. Section 6 isn't designed to handle a directly > trusted EE certificate. I think that you could tweak this by > defining a trust anchor using the CA's certificate, with a > name constraint which permits your EE's DN and no other using > initial-permitted-subtrees, although you'd be trusting the CA > to reserve that DN for the entity you want. That way you'd > get revocation check as well. Alternatively, you could write > your own algorithm for directly trusting EE certificates. > > Tom Gindin > > > > > > "Bob Bell (rtbell)" > Sent by: owner-ietf-pkix@mail.imc.org > 06/09/2008 03:32 PM > > To > "Santosh Chokhani" , cc > > Subject > RE: RFC 5280 Question > > > > > > > Santosh, et al - > > I appreciate your response. I agree that there is a potential > to have a problem if the acceptance/provisioning of trusted > certs is not done securely. However, in this case, we are > being very careful with that issue. > > As to the "spawning a bogus hierarchy", if the cert in the > trust list does not have the CA bit set in the usage, then it > cannot be used to sign other certs, and thus cannot create > this false hierarchy. Is that correct? > > Bob > > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > Sent: Monday, 09 June, 2008 11:42 > To: Bob Bell (rtbell); ietf-pkix@imc.org > Subject: RE: RFC 5280 Question > > Bob, > > Neither X.509 nor 5280 explicitly address this. > > But, one can safely assume that the standards imply that if a > trusted certificate public key is required, there is no need > for path development and validation. > > That said, trusting an end certificate could invite security > trouble depending on how this trusted certificate is handled. > > As mentioned below ?trust anchor list? could be problematic. > X.509 and 5280 do not require any checks on trust anchors and > hence this end certificate could spawn a bogus hierarchy and > the PK enabled applications could legitimately accept that hierarchy. > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Bob Bell (rtbell) > Sent: Monday, June 09, 2008 12:29 PM > To: ietf-pkix@imc.org > Subject: RFC 5280 Question > > Folks- > > I am hoping someone can give me the answer to this. Does RFC > 5280 adress the case where an end-entity certificate (not a > CA cert) is installed in the trust anchor list by the user > accepting the presented cert as authoritative and then the > cert is subsequently presented (in a later access to the > site). There should be no path search, since the presented > cert is in the trust anchor list. So, where is it defined to > accept the end-entity cert? > > Thanks ---- Bob > > Bob Bell > Cisco Systems, Inc. > 576 S. Brentwood Ln. > Bountiful, UT 84010 > 801-294-3034 (v) > 801-294-3023 (f) > 801-971-4200 (c) > rtbell@cisco.com > > > ------=_NextPart_000_0141_01C8CA55.A13B0610 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MDkyMzI0MTBaMCMGCSqGSIb3DQEJBDEWBBTOX2aXJIs0KDGOy1yJ uIZuyH9lxjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYB5+kWH0OkSqws7JzDu/8xyqv/jtv2AveukG+KqyMO4ym8gzRVHH9HTCUbnp/NpFKgUL+YX LlLEuz948jrkg58Q6xvoTSTsracfEy/tUxplPCsRfY6+w2qpqxuOs7/vvwKLTLMLoAkjoZUlnaqV NR3U7CpkNli7QP9TpGZzXSTclQAAAAAAAA== ------=_NextPart_000_0141_01C8CA55.A13B0610-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59N3411023747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 16:03:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59N34iu023742; Mon, 9 Jun 2008 16:03:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59N31j8023678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Jun 2008 16:03:03 -0700 (MST) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m59N2w3I020828 for ; Mon, 9 Jun 2008 19:02:58 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m59N2wQV194008 for ; Mon, 9 Jun 2008 19:02:58 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m59N2wla010435 for ; Mon, 9 Jun 2008 19:02:58 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m59N2wiU010432; Mon, 9 Jun 2008 19:02:58 -0400 In-Reply-To: To: "Bob Bell (rtbell)" Cc: ietf-pkix@imc.org, "Santosh Chokhani" MIME-Version: 1.0 Subject: RE: RFC 5280 Question X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Tom Gindin Message-ID: Date: Mon, 9 Jun 2008 19:02:56 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 7.0.2FP2 IGS702FP2HF8|March 12, 2008) at 06/09/2008 19:02:58, Serialize complete at 06/09/2008 19:02:58 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bob: It looks to me as if RFC 5280 section 6 presumes that a trust=20 anchor represents an issuer, rather than permitting EE's. If you consider = the fields in 6.1.1, they include an issuer name but no subject name. One = of the conditions which basic path validation is expected to verify is=20 "certificate 1 is issued by the trust anchor". When the EE certificate is = directly trusted, this condition will never be true, since no certificate=20 exists which was issued by the trust anchor. While no certificate which contains keyUsage with keyCertSign not=20 set can be used as an intermediate CA certificate (see 6.1.4-n), section=20 6.1.4 doesn't execute against the trust anchor so verification isn't=20 expected to reject the use of a directly trusted certificate as a CA=20 certificate. Section 6 isn't designed to handle a directly=20 trusted EE certificate. I think that you could tweak this by defining a=20 trust anchor using the CA's certificate, with a name constraint which=20 permits your EE's DN and no other using initial-permitted-subtrees,=20 although you'd be trusting the CA to reserve that DN for the entity you=20 want. That way you'd get revocation check as well. Alternatively, you=20 could write your own algorithm for directly trusting EE certificates. Tom Gindin "Bob Bell (rtbell)" =20 Sent by: owner-ietf-pkix@mail.imc.org 06/09/2008 03:32 PM To "Santosh Chokhani" , cc Subject RE: RFC 5280 Question Santosh, et al - =20 I appreciate your response. I agree that there is a potential to have a=20 problem if the acceptance/provisioning of trusted certs is not done=20 securely. However, in this case, we are being very careful with that=20 issue. =20 As to the "spawning a bogus hierarchy", if the cert in the trust list does = not have the CA bit set in the usage, then it cannot be used to sign other = certs, and thus cannot create this false hierarchy. Is that correct? =20 Bob From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 Sent: Monday, 09 June, 2008 11:42 To: Bob Bell (rtbell); ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, =20 Neither X.509 nor 5280 explicitly address this. =20 But, one can safely assume that the standards imply that if a trusted=20 certificate public key is required, there is no need for path development=20 and validation. =20 That said, trusting an end certificate could invite security trouble=20 depending on how this trusted certificate is handled. =20 As mentioned below ?trust anchor list? could be problematic. X.509 and=20 5280 do not require any checks on trust anchors and hence this end=20 certificate could spawn a bogus hierarchy and the PK enabled applications=20 could legitimately accept that hierarchy. From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]=20 On Behalf Of Bob Bell (rtbell) Sent: Monday, June 09, 2008 12:29 PM To: ietf-pkix@imc.org Subject: RFC 5280 Question =20 Folks- =20 I am hoping someone can give me the answer to this. Does RFC 5280 adress=20 the case where an end-entity certificate (not a CA cert) is installed in=20 the trust anchor list by the user accepting the presented cert as=20 authoritative and then the cert is subsequently presented (in a later=20 access to the site). There should be no path search, since the presented=20 cert is in the trust anchor list. So, where is it defined to accept the=20 end-entity cert? =20 Thanks ---- Bob =20 Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com =20 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59M7sOq007842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 15:07:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59M7saE007841; Mon, 9 Jun 2008 15:07:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59M7p34007824 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 15:07:52 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,614,1204531200"; d="p7s'?scan'208,217";a="110909665" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2008 15:07:51 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m59M7pKu004712; Mon, 9 Jun 2008 15:07:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m59M7pht006219; Mon, 9 Jun 2008 22:07:51 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 15:07:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 15:07:47 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0102_01C8CA4A.F5962E70" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKTfmB38lAmillT8i4ZQGXFbXMEwACJDbAAAQiEgAAAkE+MAAAlFhwAAKQXRA= References: From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , X-OriginalArrivalTime: 09 Jun 2008 22:07:51.0351 (UTC) FILETIME=[42622470:01C8CA7D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=28685; t=1213049271; x=1213913271; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=C6ofhElB0VXfNFek41/2H8vp+EPRW9q+cUPzToCPawk=; b=iVUm784M1w7Nqwn3Hb9DU3ZRTSKHA2dL4qZ9YqVIpU4uPz+bW5QbFaH999 dNH+BQskK6XYWKwO59C5EpZJytoCOnxvIYLaHHwcrcaUIVGCage+vDX+bPbD 9lyggj1H4h8u7dNbvTKU/GGBMBAZ1K0LnVwYZIlKtUaKQ6pD4AG+k=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0102_01C8CA4A.F5962E70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0103_01C8CA4A.F5962E70" ------=_NextPart_001_0103_01C8CA4A.F5962E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh - Thanks for your replys. First comment, we do enforce the checking of the CA bit in our application. That application is the only one that would use this cert as it is specific to the application and would have no meaning elsewhere. Also it requires a Systems Administrator approval to install the cert, and end user cannot do it. Secondly, revocation is simply having the SysAdmin remove it from the trust store. Since they are the sole arbiters of whether a cert is valid for this purpose, and because the certs in question are typically self-signed anyway, this is the mechanism we evolved to handle deapproval of a device. These are device certs rather than user certs also. Bob _____ From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] Sent: Monday, 09 June, 2008 14:52 To: Bob Bell (rtbell); ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, Let me add, that in situations where all the applications on the client platform that installs the user certificate as a trusted certificate, if the basic constraints check is made, most of my concerns are neutralized. The only concern is that any revocation or compromise of that user certificate requires some out of band means to delete the trust anchor. _____ From: Santosh Chokhani Sent: Monday, June 09, 2008 4:38 PM To: 'Bob Bell (rtbell)'; ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, My primary concern in terms of being very careful is that subscriber keys are not as well protected as CA and undetected compromise becomes a problem. So, it is not a matter of trusting the subscriber; subscriber could be very trustworthy, but the environment is not likely to be as protected as the CA. On the issue of basic constraints (a.k.a. cA bit), while many of the client may make that check, there is no requirement in X.509 and 5280 to make that check on a trust anchor. _____ From: Bob Bell (rtbell) [mailto:rtbell@cisco.com] Sent: Monday, June 09, 2008 3:32 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: RFC 5280 Question Santosh, et al - I appreciate your response. I agree that there is a potential to have a problem if the acceptance/provisioning of trusted certs is not done securely. However, in this case, we are being very careful with that issue. As to the "spawning a bogus hierarchy", if the cert in the trust list does not have the CA bit set in the usage, then it cannot be used to sign other certs, and thus cannot create this false hierarchy. Is that correct? Bob _____ From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] Sent: Monday, 09 June, 2008 11:42 To: Bob Bell (rtbell); ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, Neither X.509 nor 5280 explicitly address this. But, one can safely assume that the standards imply that if a trusted certificate public key is required, there is no need for path development and validation. That said, trusting an end certificate could invite security trouble depending on how this trusted certificate is handled. As mentioned below "trust anchor list" could be problematic. X.509 and 5280 do not require any checks on trust anchors and hence this end certificate could spawn a bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy. _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Bob Bell (rtbell) Sent: Monday, June 09, 2008 12:29 PM To: ietf-pkix@imc.org Subject: RFC 5280 Question Folks- I am hoping someone can give me the answer to this. Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented cert as authoritative and then the cert is subsequently presented (in a later access to the site). There should be no path search, since the presented cert is in the trust anchor list. So, where is it defined to accept the end-entity cert? Thanks ---- Bob Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com ------=_NextPart_001_0103_01C8CA4A.F5962E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Santosh -
 
Thanks for your replys. First comment, we do = enforce the=20 checking of the CA bit in our application. That application is the only = one that=20 would use this cert as it is specific to the application and would have = no=20 meaning elsewhere. Also it requires a Systems Administrator approval to = install=20 the cert, and end user cannot do it. Secondly, revocation is simply = having the=20 SysAdmin remove it from the trust store. Since they are the sole = arbiters of=20 whether a cert is valid for this purpose, and because the certs in = question are=20 typically self-signed anyway, this is the mechanism we evolved to handle = deapproval of a device. These are device certs rather than user certs=20 also.
 
Bob

From: Santosh Chokhani=20 [mailto:SChokhani@cygnacom.com]
Sent: Monday, 09 June, 2008 = 14:52
To: Bob Bell (rtbell); = ietf-pkix@imc.org
Subject:=20 RE: RFC 5280 Question

Bob,

 

Let me add, = that in=20 situations where all the applications on the client platform that = installs the=20 user certificate as a trusted certificate, if the basic constraints = check is=20 made, most of my concerns are = neutralized.

 

The only = concern is=20 that any revocation or compromise of that user certificate requires = some out=20 of band means to delete the trust anchor.

From:=20 Santosh Chokhani =
Sent: Monday, June 09, 2008 = 4:38=20 PM
To: 'Bob Bell = (rtbell)';=20 ietf-pkix@imc.org
Subject:=20 RE: RFC 5280 Question

 

Bob,

 

My primary = concern in=20 terms of being very careful is that subscriber keys are not as well = protected=20 as CA and undetected compromise becomes a problem.  So, it is not = a=20 matter of trusting the subscriber; subscriber could be very = trustworthy, but=20 the environment is not likely to be as protected as the=20 CA.

 

On the = issue of basic=20 constraints (a.k.a. cA bit), while many of the client may make that = check,=20 there is no requirement in X.509 and 5280 to make that check on a = trust=20 anchor.

 

From: Bob=20 Bell (rtbell) [mailto:rtbell@cisco.com]
Sent: Monday, June 09, 2008 = 3:32=20 PM
To: = Santosh Chokhani; = ietf-pkix@imc.org
Subject: RE: RFC 5280=20 Question

 

Santosh, et = al=20 -

 

I = appreciate your=20 response. I agree that there is a potential to have a problem if the=20 acceptance/provisioning of trusted certs is not done securely. = However, in=20 this case, we are being very careful with that=20 issue.

 

As to the = "spawning a=20 bogus hierarchy", if the cert in the trust list does not have the CA = bit set=20 in the usage, then it cannot be used to sign other certs, and thus = cannot=20 create this false hierarchy. Is that = correct?

 

Bob

 

From:=20 Santosh Chokhani=20 [mailto:SChokhani@cygnacom.com]
Sent: Monday, 09 June, 2008=20 11:42
To: Bob = Bell=20 (rtbell); ietf-pkix@imc.org
Subject: RE: RFC 5280=20 Question

Bob,

 

Neither = X.509 nor=20 5280 explicitly address this.

 

But, one = can safely=20 assume that the standards imply that if a trusted certificate public = key is=20 required, there is no need for path development and=20 validation.

 

That = said, trusting=20 an end certificate could invite security trouble depending on how = this=20 trusted certificate is handled.

 

As = mentioned below=20 “trust anchor list” could be problematic.  X.509 = and 5280 do not=20 require any checks on trust anchors and hence this end certificate = could=20 spawn a bogus hierarchy and the PK enabled applications could = legitimately=20 accept that hierarchy.

From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Bob Bell=20 (rtbell)
Sent: = Monday, June=20 09, 2008 12:29 PM
To:=20 ietf-pkix@imc.org
Subject:=20 RFC 5280 Question

 

Folks-

 

I am hoping someone = can give me=20 the answer to this. Does RFC 5280 adress the case where an = end-entity=20 certificate (not a CA cert) is installed in the trust anchor list by = the=20 user accepting the presented cert as authoritative and then the cert = is=20 subsequently presented (in a later access to the site). There should = be no=20 path search, since the presented cert is in the trust anchor list. = So, where=20 is it defined to accept the end-entity=20 cert?

 

Thanks ----=20 Bob

 

Bob=20 Bell

Cisco Systems,=20 Inc.

576 S.=20 Brentwood = Ln.

Bountiful,=20 UT 84010

801-294-3034=20 (v)

801-294-3023=20 (f)

801-971-4200=20 (c)

rtbell@cisco.com

 

------=_NextPart_001_0103_01C8CA4A.F5962E70-- ------=_NextPart_000_0102_01C8CA4A.F5962E70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MDkyMjA3NDdaMCMGCSqGSIb3DQEJBDEWBBQEv+UOs3Q+8HggaIbo qrCE59HW4zBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYAEah7HmEO2QfbNxQFs7gScJobyv2NmiIE4RNzDw+HrgjyXxaNFNr12fG67mZgOVX0OsCbB pSRv+0B+VOyMKYCqfMvlzU1mcoT+Xqbrdq63X5bNGSIkSxCf82M821qY4FSr5AVAsYGVRzC4bs0A Gpma2qmzAXyGSYrjrxjNVUpRPQAAAAAAAA== ------=_NextPart_000_0102_01C8CA4A.F5962E70-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59Kq9HH088985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 13:52:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59Kq9Nd088984; Mon, 9 Jun 2008 13:52:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m59Kq8o3088978 for ; Mon, 9 Jun 2008 13:52:08 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 23386 invoked from network); 9 Jun 2008 20:41:54 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;09 Jun 2008 20:41:54 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 9 Jun 2008 20:41:53 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA72.AD924D4C" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 16:52:06 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKTfmB38lAmillT8i4ZQGXFbXMEwACJDbAAAQiEgAAAkE+MAAAlFhw References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA72.AD924D4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, =20 Let me add, that in situations where all the applications on the client platform that installs the user certificate as a trusted certificate, if the basic constraints check is made, most of my concerns are neutralized. =20 The only concern is that any revocation or compromise of that user certificate requires some out of band means to delete the trust anchor. ________________________________ From: Santosh Chokhani=20 Sent: Monday, June 09, 2008 4:38 PM To: 'Bob Bell (rtbell)'; ietf-pkix@imc.org Subject: RE: RFC 5280 Question =20 Bob, =20 My primary concern in terms of being very careful is that subscriber keys are not as well protected as CA and undetected compromise becomes a problem. So, it is not a matter of trusting the subscriber; subscriber could be very trustworthy, but the environment is not likely to be as protected as the CA. =20 On the issue of basic constraints (a.k.a. cA bit), while many of the client may make that check, there is no requirement in X.509 and 5280 to make that check on a trust anchor. =20 ________________________________ From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 3:32 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: RFC 5280 Question =20 Santosh, et al - =20 I appreciate your response. I agree that there is a potential to have a problem if the acceptance/provisioning of trusted certs is not done securely. However, in this case, we are being very careful with that issue. =20 As to the "spawning a bogus hierarchy", if the cert in the trust list does not have the CA bit set in the usage, then it cannot be used to sign other certs, and thus cannot create this false hierarchy. Is that correct? =20 Bob =20 =09 ________________________________ From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 Sent: Monday, 09 June, 2008 11:42 To: Bob Bell (rtbell); ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, =20 Neither X.509 nor 5280 explicitly address this. =20 But, one can safely assume that the standards imply that if a trusted certificate public key is required, there is no need for path development and validation. =20 That said, trusting an end certificate could invite security trouble depending on how this trusted certificate is handled. =20 As mentioned below "trust anchor list" could be problematic. X.509 and 5280 do not require any checks on trust anchors and hence this end certificate could spawn a bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy. =09 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Bob Bell (rtbell) Sent: Monday, June 09, 2008 12:29 PM To: ietf-pkix@imc.org Subject: RFC 5280 Question =20 Folks- =20 I am hoping someone can give me the answer to this. Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented cert as authoritative and then the cert is subsequently presented (in a later access to the site). There should be no path search, since the presented cert is in the trust anchor list. So, where is it defined to accept the end-entity cert? =20 Thanks ---- Bob =20 Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com =20 ------_=_NextPart_001_01C8CA72.AD924D4C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

Let me add, that in situations = where all the applications on the client platform that installs the user = certificate as a trusted certificate, if the basic constraints check is made, most of my concerns are neutralized.

 

The only concern is that any = revocation or compromise of that user certificate requires some out of band means to = delete the trust anchor.

From: = Santosh Chokhani
Sent: Monday, June 09, = 2008 4:38 PM
To: 'Bob Bell (rtbell)'; ietf-pkix@imc.org
Subject: RE: RFC 5280 = Question

 

Bob,

 

My primary concern in terms of = being very careful is that subscriber keys are not as well protected as CA and = undetected compromise becomes a problem.  So, it is not a matter of trusting the = subscriber; subscriber could be very trustworthy, but the environment is not likely = to be as protected as the CA.

 

On the issue of basic constraints = (a.k.a. cA bit), while many of the client may make that check, there is no = requirement in X.509 and 5280 to make that check on a trust = anchor.

 

From: Bob = Bell (rtbell) [mailto:rtbell@cisco.com]
Sent: Monday, June 09, = 2008 3:32 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: RFC 5280 = Question

 

Santosh, et al = -

 

I appreciate your response. I agree = that there is a potential to have a problem if the acceptance/provisioning of trusted certs is not done securely. However, in this case, we are being = very careful with that issue.

 

As to the "spawning a bogus hierarchy", if the cert in the trust list does not have the CA bit = set in the usage, then it cannot be used to sign other certs, and thus cannot = create this false hierarchy. Is that correct?

 

Bob

 

From: Santosh Chokhani = [mailto:SChokhani@cygnacom.com]
Sent: Monday, 09 June, = 2008 11:42
To: Bob Bell (rtbell); ietf-pkix@imc.org
Subject: RE: RFC 5280 = Question

Bob,

 

Neither X.509 nor 5280 explicitly = address this.

 

But, one can safely assume that the standards imply that if a trusted certificate public key is required, = there is no need for path development and = validation.

 

That said, trusting an end = certificate could invite security trouble depending on how this trusted certificate = is handled.

 

As mentioned below “trust = anchor list” could be problematic.  X.509 and 5280 do not require = any checks on trust anchors and hence this end certificate could spawn a = bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Bob Bell (rtbell)
Sent: Monday, June 09, = 2008 12:29 PM
To: ietf-pkix@imc.org
Subject: RFC 5280 = Question

 

Folks-

 

I am hoping someone can give me the answer to this. = Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented = cert as authoritative and then the cert is subsequently presented (in a later = access to the site). There should be no path search, since the presented cert is = in the trust anchor list. So, where is it defined to accept the end-entity = cert?

 

Thanks ---- Bob

 

Bob Bell

Cisco Systems, Inc.

576 S. = Brentwood Ln.

Bountiful, UT 84010

801-294-3034 (v)

801-294-3023 (f)

801-971-4200 (c)

rtbell@cisco.com

 

------_=_NextPart_001_01C8CA72.AD924D4C-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59KcNwH086448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 13:38:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59KcN8S086447; Mon, 9 Jun 2008 13:38:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m59KcLMX086439 for ; Mon, 9 Jun 2008 13:38:22 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 23239 invoked from network); 9 Jun 2008 20:28:08 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;09 Jun 2008 20:28:08 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 9 Jun 2008 20:28:07 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA70.C14CA875" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 16:38:20 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKTfmB38lAmillT8i4ZQGXFbXMEwACJDbAAAQiEgAAAkE+MA== References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA70.C14CA875 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, =20 My primary concern in terms of being very careful is that subscriber keys are not as well protected as CA and undetected compromise becomes a problem. So, it is not a matter of trusting the subscriber; subscriber could be very trustworthy, but the environment is not likely to be as protected as the CA. =20 On the issue of basic constraints (a.k.a. cA bit), while many of the client may make that check, there is no requirement in X.509 and 5280 to make that check on a trust anchor. =20 _____ =20 From: Bob Bell (rtbell) [mailto:rtbell@cisco.com]=20 Sent: Monday, June 09, 2008 3:32 PM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: RFC 5280 Question =20 Santosh, et al - =20 I appreciate your response. I agree that there is a potential to have a problem if the acceptance/provisioning of trusted certs is not done securely. However, in this case, we are being very careful with that issue. =20 As to the "spawning a bogus hierarchy", if the cert in the trust list does not have the CA bit set in the usage, then it cannot be used to sign other certs, and thus cannot create this false hierarchy. Is that correct? =20 Bob =20 _____ =20 From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 Sent: Monday, 09 June, 2008 11:42 To: Bob Bell (rtbell); ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, =20 Neither X.509 nor 5280 explicitly address this. =20 But, one can safely assume that the standards imply that if a trusted certificate public key is required, there is no need for path development and validation. =20 That said, trusting an end certificate could invite security trouble depending on how this trusted certificate is handled. =20 As mentioned below "trust anchor list" could be problematic. X.509 and 5280 do not require any checks on trust anchors and hence this end certificate could spawn a bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy. _____ =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Bob Bell (rtbell) Sent: Monday, June 09, 2008 12:29 PM To: ietf-pkix@imc.org Subject: RFC 5280 Question =20 Folks- =20 I am hoping someone can give me the answer to this. Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented cert as authoritative and then the cert is subsequently presented (in a later access to the site). There should be no path search, since the presented cert is in the trust anchor list. So, where is it defined to accept the end-entity cert? =20 Thanks ---- Bob =20 Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com =20 ------_=_NextPart_001_01C8CA70.C14CA875 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

My primary concern in terms of = being very careful is that subscriber keys are not as well protected as CA and = undetected compromise becomes a problem.  So, it is not a matter of trusting = the subscriber; subscriber could be very trustworthy, but the environment is not likely = to be as protected as the CA.

 

On the issue of basic constraints = (a.k.a. cA bit), while many of the client may make that check, there is no = requirement in X.509 and 5280 to make that check on a trust = anchor.

 

From: Bob = Bell (rtbell) [mailto:rtbell@cisco.com]
Sent: Monday, June 09, = 2008 3:32 PM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: RFC 5280 = Question

 

Santosh, et al = -

 

I appreciate your response. I agree = that there is a potential to have a problem if the acceptance/provisioning of trusted certs is not done securely. However, in this case, we are being = very careful with that issue.

 

As to the "spawning a bogus hierarchy", if the cert in the trust list does not have the CA bit = set in the usage, then it cannot be used to sign other certs, and thus cannot = create this false hierarchy. Is that correct?

 

Bob

 

From: Santosh Chokhani = [mailto:SChokhani@cygnacom.com]
Sent: Monday, 09 June, = 2008 11:42
To: Bob Bell (rtbell); ietf-pkix@imc.org
Subject: RE: RFC 5280 = Question

Bob,

 

Neither X.509 nor 5280 explicitly = address this.

 

But, one can safely assume that the standards imply that if a trusted certificate public key is required, = there is no need for path development and = validation.

 

That said, trusting an end = certificate could invite security trouble depending on how this trusted certificate = is handled.

 

As mentioned below “trust = anchor list” could be problematic.  X.509 and 5280 do not require = any checks on trust anchors and hence this end certificate could spawn a = bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Bob Bell (rtbell)
Sent: Monday, June 09, = 2008 12:29 PM
To: ietf-pkix@imc.org
Subject: RFC 5280 = Question

 

Folks-

 

I am hoping someone can give me the answer to this. = Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented = cert as authoritative and then the cert is subsequently presented (in a later = access to the site). There should be no path search, since the presented cert is = in the trust anchor list. So, where is it defined to accept the end-entity = cert?

 

Thanks ---- Bob

 

Bob Bell

Cisco Systems, Inc.

576 S. = Brentwood Ln.

Bountiful, UT 84010

801-294-3034 (v)

801-294-3023 (f)

801-971-4200 (c)

rtbell@cisco.com

 

------_=_NextPart_001_01C8CA70.C14CA875-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59JWPD0073626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 12:32:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59JWPFf073625; Mon, 9 Jun 2008 12:32:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59JWOf5073611 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 12:32:24 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,613,1204531200"; d="p7s'?scan'208,217";a="110842563" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2008 12:32:11 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m59JWB8r009792; Mon, 9 Jun 2008 12:32:11 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m59JWBil004898; Mon, 9 Jun 2008 19:32:11 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 12:32:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 12:32:08 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B6_01C8CA35.36D6BFA0" Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKTfmB38lAmillT8i4ZQGXFbXMEwACJDbAAAQiEgA= References: From: "Bob Bell (rtbell)" To: "Santosh Chokhani" , X-OriginalArrivalTime: 09 Jun 2008 19:32:11.0522 (UTC) FILETIME=[83695620:01C8CA67] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18093; t=1213039931; x=1213903931; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RE=3A=20RFC=205280=20Question |Sender:=20; bh=FRKmjLOTUX9EgeJxkW1ETWL+IZFvXqAXEHSzeCHMXqo=; b=uQO8lhBLIdlrISQhWcb4vXjzwNkRHwx98Q8ef7Rj0qR7uUvUf1S0VeIHfE ossEmXw2qdEAymVd4M5hJbRWECFkoJeJW/wFDcf7ThivYbd0R7cP3DnlbV6h LFPXWGYNOX4plOo58t4MlYdHJdOFtHE59D+mbQekI6MqZZBy4WwtI=; Authentication-Results: sj-dkim-1; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00B6_01C8CA35.36D6BFA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00B7_01C8CA35.36D6BFA0" ------=_NextPart_001_00B7_01C8CA35.36D6BFA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Santosh, et al - I appreciate your response. I agree that there is a potential to have a problem if the acceptance/provisioning of trusted certs is not done securely. However, in this case, we are being very careful with that issue. As to the "spawning a bogus hierarchy", if the cert in the trust list does not have the CA bit set in the usage, then it cannot be used to sign other certs, and thus cannot create this false hierarchy. Is that correct? Bob _____ From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] Sent: Monday, 09 June, 2008 11:42 To: Bob Bell (rtbell); ietf-pkix@imc.org Subject: RE: RFC 5280 Question Bob, Neither X.509 nor 5280 explicitly address this. But, one can safely assume that the standards imply that if a trusted certificate public key is required, there is no need for path development and validation. That said, trusting an end certificate could invite security trouble depending on how this trusted certificate is handled. As mentioned below "trust anchor list" could be problematic. X.509 and 5280 do not require any checks on trust anchors and hence this end certificate could spawn a bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy. _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Bob Bell (rtbell) Sent: Monday, June 09, 2008 12:29 PM To: ietf-pkix@imc.org Subject: RFC 5280 Question Folks- I am hoping someone can give me the answer to this. Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented cert as authoritative and then the cert is subsequently presented (in a later access to the site). There should be no path search, since the presented cert is in the trust anchor list. So, where is it defined to accept the end-entity cert? Thanks ---- Bob Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com ------=_NextPart_001_00B7_01C8CA35.36D6BFA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Santosh, et al -
 
I appreciate your response. I agree that there = is a=20 potential to have a problem if the acceptance/provisioning of trusted = certs is=20 not done securely. However, in this case, we are being very careful with = that=20 issue.
 
As to the "spawning a bogus hierarchy", if the = cert in the=20 trust list does not have the CA bit set in the usage, then it cannot be = used to=20 sign other certs, and thus cannot create this false hierarchy. Is that=20 correct?
 
Bob

From: Santosh Chokhani=20 [mailto:SChokhani@cygnacom.com]
Sent: Monday, 09 June, 2008 = 11:42
To: Bob Bell (rtbell); = ietf-pkix@imc.org
Subject:=20 RE: RFC 5280 Question

Bob,

 

Neither = X.509 nor=20 5280 explicitly address this.

 

But, one = can safely=20 assume that the standards imply that if a trusted certificate public = key is=20 required, there is no need for path development and=20 validation.

 

That said, = trusting=20 an end certificate could invite security trouble depending on how this = trusted=20 certificate is handled.

 

As = mentioned below=20 “trust anchor list” could be problematic.  X.509 and = 5280 do not require=20 any checks on trust anchors and hence this end certificate could spawn = a bogus=20 hierarchy and the PK enabled applications could legitimately accept = that=20 hierarchy.

From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Bob Bell=20 (rtbell)
Sent: = Monday, June=20 09, 2008 12:29 PM
To:=20 ietf-pkix@imc.org
Subject:=20 RFC 5280 Question

 

Folks-

 

I am hoping someone can = give me=20 the answer to this. Does RFC 5280 adress the case where an end-entity=20 certificate (not a CA cert) is installed in the trust anchor list by = the user=20 accepting the presented cert as authoritative and then the cert is=20 subsequently presented (in a later access to the site). There should = be no=20 path search, since the presented cert is in the trust anchor list. So, = where=20 is it defined to accept the end-entity=20 cert?

 

Thanks ----=20 Bob

 

Bob=20 Bell

Cisco Systems,=20 Inc.

576 S.=20 Brentwood Ln.

Bountiful,=20 UT 84010

801-294-3034=20 (v)

801-294-3023=20 (f)

801-971-4200=20 (c)

rtbell@cisco.com

 

= ------=_NextPart_001_00B7_01C8CA35.36D6BFA0-- ------=_NextPart_000_00B6_01C8CA35.36D6BFA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MDkxOTMyMDhaMCMGCSqGSIb3DQEJBDEWBBS7faxlPD0FLsQ2MKFn jCVEDoY8OTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYAId6ZMTW5W6vPjRaD+FjJxCaJCmSqm1NjJNITo72/taZh16+XsrNCrOR7lU7Om4/Wu9UHg arZ/i5OxVyEDz8HK1PyNAhHE10DcyI96C/FAT1Zdh31RPaKwW1i/vPcmwjcF6ZItUcFt/ex1/FGK xMRKtgZ/QMV28k4TJOtQQmCtDgAAAAAAAA== ------=_NextPart_000_00B6_01C8CA35.36D6BFA0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59HgOfs048778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 10:42:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59HgNXC048777; Mon, 9 Jun 2008 10:42:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m59HgMip048759 for ; Mon, 9 Jun 2008 10:42:22 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 21702 invoked from network); 9 Jun 2008 17:32:08 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;09 Jun 2008 17:32:08 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 9 Jun 2008 17:32:06 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA58.2A730FE7" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RFC 5280 Question Date: Mon, 9 Jun 2008 13:42:19 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKTfmB38lAmillT8i4ZQGXFbXMEwACJDbA References: From: "Santosh Chokhani" To: "Bob Bell (rtbell)" , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA58.2A730FE7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, =20 Neither X.509 nor 5280 explicitly address this. =20 But, one can safely assume that the standards imply that if a trusted certificate public key is required, there is no need for path development and validation. =20 That said, trusting an end certificate could invite security trouble depending on how this trusted certificate is handled. =20 As mentioned below "trust anchor list" could be problematic. X.509 and 5280 do not require any checks on trust anchors and hence this end certificate could spawn a bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy. _____ =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Bob Bell (rtbell) Sent: Monday, June 09, 2008 12:29 PM To: ietf-pkix@imc.org Subject: RFC 5280 Question =20 Folks- =20 I am hoping someone can give me the answer to this. Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented cert as authoritative and then the cert is subsequently presented (in a later access to the site). There should be no path search, since the presented cert is in the trust anchor list. So, where is it defined to accept the end-entity cert? =20 Thanks ---- Bob =20 Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com =20 ------_=_NextPart_001_01C8CA58.2A730FE7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

Neither X.509 nor 5280 explicitly = address this.

 

But, one can safely assume that the standards imply that if a trusted certificate public key is required, = there is no need for path development and = validation.

 

That said, trusting an end = certificate could invite security trouble depending on how this trusted certificate = is handled.

 

As mentioned below “trust = anchor list” could be problematic.  X.509 and 5280 do not require = any checks on trust anchors and hence this end certificate could spawn a = bogus hierarchy and the PK enabled applications could legitimately accept that hierarchy.

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Bob Bell (rtbell)
Sent: Monday, June 09, = 2008 12:29 PM
To: ietf-pkix@imc.org
Subject: RFC 5280 = Question

 

Folks-

 

I am hoping someone can give me the answer to this. = Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented = cert as authoritative and then the cert is subsequently presented (in a later = access to the site). There should be no path search, since the presented cert is = in the trust anchor list. So, where is it defined to accept the end-entity = cert?

 

Thanks ---- Bob

 

Bob Bell

Cisco Systems, Inc.

576 S. = Brentwood Ln.

Bountiful, UT 84010

801-294-3034 (v)

801-294-3023 (f)

801-971-4200 (c)

rtbell@cisco.com

 

------_=_NextPart_001_01C8CA58.2A730FE7-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59GThdq033264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 09:29:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m59GThvt033263; Mon, 9 Jun 2008 09:29:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59GTgGo033247 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 9 Jun 2008 09:29:42 -0700 (MST) (envelope-from rtbell@cisco.com) X-IronPort-AV: E=Sophos;i="4.27,613,1204531200"; d="p7s'?scan'208,217";a="39705136" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Jun 2008 09:29:39 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m59GTdMY018051 for ; Mon, 9 Jun 2008 09:29:39 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m59GTd6J007628 for ; Mon, 9 Jun 2008 16:29:39 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 09:29:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RFC 5280 Question Date: Mon, 9 Jun 2008 09:29:22 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0056_01C8CA1B.AF05A690" Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5280 Question Thread-Index: AcjKTfmB38lAmillT8i4ZQGXFbXMEw== From: "Bob Bell (rtbell)" To: X-OriginalArrivalTime: 09 Jun 2008 16:29:26.0268 (UTC) FILETIME=[FB9C5BC0:01C8CA4D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7493; t=1213028979; x=1213892979; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rtbell@cisco.com; z=From:=20=22Bob=20Bell=20(rtbell)=22=20 |Subject:=20RFC=205280=20Question |Sender:=20; bh=lSTTNSd2mSQOINEUa3f6edRDqLsT+VzuMd9085vqgNw=; b=WE6NGyCePC4Yy6t807w5PmyxSPWnPLlWu8KZZRRe8XRyvsJGp8j0QFNy1s H6p5z/241yUaGYcUQaN8mZChY1cbZd/6s9RQNZDhNk2EG9MK8THZdXJ2Y1ba +zDubsi68M; Authentication-Results: sj-dkim-3; header.From=rtbell@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0056_01C8CA1B.AF05A690 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0057_01C8CA1B.AF05A690" ------=_NextPart_001_0057_01C8CA1B.AF05A690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks- I am hoping someone can give me the answer to this. Does RFC 5280 adress the case where an end-entity certificate (not a CA cert) is installed in the trust anchor list by the user accepting the presented cert as authoritative and then the cert is subsequently presented (in a later access to the site). There should be no path search, since the presented cert is in the trust anchor list. So, where is it defined to accept the end-entity cert? Thanks ---- Bob Bob Bell Cisco Systems, Inc. 576 S. Brentwood Ln. Bountiful, UT 84010 801-294-3034 (v) 801-294-3023 (f) 801-971-4200 (c) rtbell@cisco.com ------=_NextPart_001_0057_01C8CA1B.AF05A690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks-
 
I am = hoping someone=20 can give me the answer to this. Does RFC 5280 adress the case where an=20 end-entity certificate (not a CA cert) is installed in the trust anchor = list by=20 the user accepting the presented cert as authoritative and then the cert = is=20 subsequently presented (in a later access to the site). There should be = no path=20 search, since the presented cert is in the trust anchor list. So, where = is it=20 defined to accept the end-entity cert?
 
Thanks = ----=20 Bob
 
Bob Bell
Cisco Systems, = Inc.
576 S. Brentwood = Ln.
Bountiful, UT = 84010
801-294-3034 = (v)
801-294-3023 = (f)
801-971-4200 = (c)
rtbell@cisco.com
 
------=_NextPart_001_0057_01C8CA1B.AF05A690-- ------=_NextPart_000_0056_01C8CA1B.AF05A690 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAnEw ggHaoAMCAQICEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMxNzE1MzczNFoXDTA5MDMxNzE1Mzcz NFowXTENMAsGA1UEBBMEQmVsbDESMBAGA1UEKhMJUm9iZXJ0IFQuMRcwFQYDVQQDEw5Sb2JlcnQg VC4gQmVsbDEfMB0GCSqGSIb3DQEJARYQcnRiZWxsQGNpc2NvLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAyL4qRD0FLK8//KPHlhkbzWYwz0CvX3oOVjw3/xWTbWUebBArkC7La9qki6Np qx6RDU6Ms4gggB57hXuLp+IV2jTyywtoMs9/DkECG2izb9iRS1Ptbj0a4Toov8oMp1kFW8PnNl9Q GDXYMKgGkBSoHXvxHKFQ5EEg2+gccy0VDhkCAwEAAaMtMCswGwYDVR0RBBQwEoEQcnRiZWxsQGNp c2NvLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFC7Y2uPW9baWJlIkYBzUC2a 1jG4+HL6WZMWW4isCZBRdEjAlVYV1aNnru+cb9BWhOQG2I/XqxzZaQLfn+PjF3nPBM968NP099wa xsWHCXvid3lFaVWsVZnC+S14Wi3SpQhTtdbfgP8Z7iqGxqSy9Y2rGvv+rgs38kzKNC/jR9hVMIID LTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp bEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrC FG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqY x7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOB gQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qar igd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggL4 MIIC9AIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQSKJF hf04xybc3SKL48l3gTAJBgUrDgMCGgUAoIIB2DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODA2MDkxNjI5MjJaMCMGCSqGSIb3DQEJBDEWBBRFBsF6iPhkj1wj9bvM HlHeInflJDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEEiiRYX9OMcm3N0ii+PJd4EwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEiiRYX9OMcm3N0ii+PJd4EwDQYJKoZIhvcNAQEB BQAEgYAWSkhwhUboKVHR7p26LmBteH3bxcLMU9lJISmrO0pwxRO5RyuQX6KzQBMYwjr0WovWazeq Rg2jh/1LKjOeZah5y2YJUDDixp4ZRtRBc7opqjb3XheCy7HKGnpw1A7v9PJf97M8ackLx6XEpm/W x5mMTHIRL26Phy16Ira4RZFHdgAAAAAAAA== ------=_NextPart_000_0056_01C8CA1B.AF05A690-- Received: from adsl-85-217-26-8.kotinet.com (adsl-85-217-26-39.kotinet.com [85.217.26.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59Flok4024740 for ; Mon, 9 Jun 2008 08:47:57 -0700 (MST) (envelope-from Judon-3741@24stores.com) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_fxlTrOXOIMTai5svYoMLBA)" Message-id: From: Macarayo To: ietf-pkix-archive@imc.org Subject: Hot girl for sale Date: Mon, 9 Jun 2008 18:48:04 +0300 X-Mailer: Apple Mail (2.924) --Boundary_(ID_fxlTrOXOIMTai5svYoMLBA) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT Your chick will be screaming in pleasure every night http://www.mizatew.com/ --Boundary_(ID_fxlTrOXOIMTai5svYoMLBA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT Your chick will be screaming in pleasure every night --Boundary_(ID_fxlTrOXOIMTai5svYoMLBA)-- Received: from sza111-15.npgo.pl (sza111-15.npgo.pl [194.54.84.46]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m58LT7aZ072272 for ; Sun, 8 Jun 2008 14:29:53 -0700 (MST) (envelope-from atukinan_1977@809aps.org) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_pkhRpVTVCUHfj1oxCfNSMT)" Message-id: From: BULL To: ietf-pkix-archive@imc.org Subject: Huge increase in size available NOW! Date: Sun, 8 Jun 2008 23:29:46 +0200 X-Mailer: Apple Mail (2.924) --Boundary_(ID_pkhRpVTVCUHfj1oxCfNSMT) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT Boost your confidence, with a larger organ - you can now with enhancement pills http://www.queantre.com/ --Boundary_(ID_pkhRpVTVCUHfj1oxCfNSMT) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT Boost your confidence, with a larger organ - you can now with enhancement pills --Boundary_(ID_pkhRpVTVCUHfj1oxCfNSMT)-- Received: from burbon ([79.173.98.229]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m589q7GS013634 for ; Sun, 8 Jun 2008 02:52:08 -0700 (MST) (envelope-from ietf-pjlvakzec@got.net) Date: Sun, 8 Jun 2008 02:52:07 -0700 (MST) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20080608044711.5993.qmail@burbon> To: Subject: Dear ietf-pkix-archive@imc.org June 81% 0FF From: VIAGRA ® Official Site MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Click Here!

©2007 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
Received: from [189.101.226.208] ([189.101.226.208]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m57IudUs024584 for ; Sat, 7 Jun 2008 11:56:42 -0700 (MST) (envelope-from oelliger1960@GCC-USA.COM) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_zhaDaHLTIAYug5fqFaCSDU)" Message-id: From: Cole To: ietf-pkix-archive@imc.org Subject: Stop feeling inadequate now Date: Sat, 7 Jun 2008 15:56:44 -0300 X-Mailer: Apple Mail (2.924) --Boundary_(ID_zhaDaHLTIAYug5fqFaCSDU) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT You will not believe the speed of the growth you will experience http://www.braatern.com/ --Boundary_(ID_zhaDaHLTIAYug5fqFaCSDU) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT You will not believe the speed of the growth you will experience --Boundary_(ID_zhaDaHLTIAYug5fqFaCSDU)-- Received: from nv-67-232-157-94.dhcp.embarqhsd.net (nv-67-232-157-94.dhcp.embarqhsd.net [67.232.157.94]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m568fdch014203 for ; Fri, 6 Jun 2008 01:41:44 -0700 (MST) (envelope-from iilokuat1990@LH-CO.COM) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_wqvUdTTYHPEol3dnYqNEFP)" Message-id: From: Glass To: ietf-pkix-archive@imc.org Subject: 10 ways to get her into your bed Date: Fri, 6 Jun 2008 01:41:44 -0700 X-Mailer: Apple Mail (2.924) --Boundary_(ID_wqvUdTTYHPEol3dnYqNEFP) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT A guaranteed 3-6 inches within weeks, plus added girth - find out more here http://www.lmaeven.com/ --Boundary_(ID_wqvUdTTYHPEol3dnYqNEFP) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT A guaranteed 3-6 inches within weeks, plus added girth - find out more here --Boundary_(ID_wqvUdTTYHPEol3dnYqNEFP)-- Received: from 203.129.159.231.dynamic.rev.dft.com.au (203.129.159.231.dynamic.rev.dft.com.au [203.129.159.231]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m560mISr004008; Thu, 5 Jun 2008 17:48:22 -0700 (MST) (envelope-from cbornnn@medlogix.org) Received: from 192.168.29.15 ([192.168.29.15] helo=CKkNY) by 190-172-138-130.speedy.com.ar with asmtp (Exim 4.24) id JcwKYS-00086Q-Yu; Fri, 06 Jun 2008 03:47:01 +0400 Message-ID: <000301c8c766$6b3fe400$5b19000a@CKkNY> From: "Lenna" To: "ietf-pkix-archive" Subject: Looking for Fun,Travel and Good Times. Date: Fri, 06 Jun 2008 03:47:01 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Aloha, my friend Today everything is not so as always. Today my eyes are full of tears and my soul is ill. Today I have understood how alone I am. Woman...There are so many qualities consist in this word! What the real woman has to be? I think she has to be loving, affectionate, tender, careful, sensible. The woman can't be the real woman without these qualities. I can tell that I am the woman, the real woman. But I have nobody to present my love, affectionate and tenderness. I have nobody to take care of. I have nobody to be sensible with. I can't realize myself like the woman without you. Only you can help me to become the real woman! I will wait http://createyourlove.net/8054/ Looking forward to get a note from you Lenna Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55HEp2D008659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 10:14:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m55HEpnC008657; Thu, 5 Jun 2008 10:14:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.multicert.com (mail.multicert.com [62.48.217.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55HEmPi008641; Thu, 5 Jun 2008 10:14:49 -0700 (MST) (envelope-from ricardo.barroso@multicert.com) Received: from 10.0.0.194 (webmail.multicert.com [10.0.0.194]) by mail.multicert.prod (Postfix) with SMTP id D7DB072E46; Thu, 5 Jun 2008 18:14:47 +0100 (WEST) X-Spambayes-Classification: unsure; 0.26 Received: from teste.multicert.com (unknown [62.48.177.165]) by mail.multicert.com (Postfix) with ESMTP id E07E272F2E; Thu, 5 Jun 2008 18:14:45 +0100 (WEST) Received: from [192.168.10.88] (unknown [192.168.10.88]) by teste.multicert.com (Postfix) with ESMTP id 1025D5B764; Thu, 5 Jun 2008 18:14:44 +0100 (WEST) Message-ID: <48481F06.5010301@multicert.com> Date: Thu, 05 Jun 2008 18:14:46 +0100 From: Ricardo Barroso User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Aram Perez Cc: PKIX , ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available References: <200806051325.m55DPCtJ009671@mail.nbusr.sk> <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> In-Reply-To: <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> Content-Type: multipart/alternative; boundary="------------020908070306050005030907" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------020908070306050005030907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi all! I would like to mention ASN.1 Editor (for Windows) which is not a web-based tool and although it can't provide default values from DER, it lets you: - inspect ASN.1 structures and encapsulate parts of the structures in a more user-friendly way than simple dump tools; - edit ASN.1 structures; - save sub-parts/structures to a new file; - etc. It also includes a simple but nice data converter between PEM, HEX and BASE64 formats. Best regards, Ricardo Barroso Aram Perez wrote: > Hi Peter, >> >> Have you any free tools which are not the simple dump of asn1 DER/BER >> but which also can read a data according the 1988, 93 ASN.1 Syntax? >> Like default values from DER... > > I'm afraid I do not and I'm not aware of any such tool. To get the > default values, you would need the actual ASN.1 (which provides the > default values) and the BER/DER data. > > BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others > similar tools just decode the BER/DER and present it in a "more" human > readable form. > > Regards, > Aram > >> >> >> Peter >> >> >> >> -----Original Message----- >> From: owner-ietf-smime@mail.imc.org >> [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram >> Sent: Wednesday, June 04, 2008 6:04 PM >> To: PKIX; ietf-smime@imc.org >> Subject: Re: Web-based ASN.1 decoding tool available >> >> On 6/4/08 6:53 AM, Peter Hesse wrote: >> >>> All, >>> >>> We have recently made available a web-based tool for doing an ASN.1 >>> dump. It >>> displays the ASCII HEX and the ASN structure, and when you hover >>> over the >>> structure, it highlights the relevant portion of the hex. (Clicking >>> makes the >>> highlight stick.) >>> >>> Due to PHP’s inefficiency and memory usage during parsing, we have >>> limited it >>> to files 64K and smaller. Still, it is useful for displaying >>> smaller objects >>> when you don’t have dumpasn1 installed or available. >>> >>> It can be found here: >>> http://geminisecurity.com/features-downloads/tools#fd_5 >>> Click on “Click to try the application” under PHPdumpASN. >> >> For Windows, you can also try BERViewer >> >> . I haven’t had >> time to remove the nag dialog box from the Mac version. >> >> Regards, >> Aram Perez >> >> >> > -- * Ricardo Barroso* *Telefone:* +351 217 123 010 *Telemóvel:* +351 968 332 327 *Fax:* +351 217 123 011 *Email:* ricardo.barroso@multicert.com *MULTICERT S.A.* Estrada do Casal do Canas, Lote 6, Alfragide 2720-092 Amadora - Portugal --------------020908070306050005030907 Content-Type: multipart/related; boundary="------------060705050402080307010006" --------------060705050402080307010006 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi all!

I would like to mention ASN.1 Editor (for Windows) which is not a web-based tool and although it can't provide default values from DER,
it lets you:
    - inspect ASN.1 structures and encapsulate parts of the structures in a more user-friendly way than simple dump tools;
    - edit ASN.1 structures;
    - save sub-parts/structures to a new file;
    - etc.

It also includes a simple but nice data converter between PEM, HEX and BASE64 formats.

Best regards,
Ricardo Barroso


Aram Perez wrote:
Hi Peter,

Have you any free tools which are not the simple dump of asn1 DER/BER but which also can read a data according the 1988, 93 ASN.1 Syntax?
Like default values from DER...

I'm afraid I do not and I'm not aware of any such tool. To get the default values, you would need the actual ASN.1 (which provides the default values) and the BER/DER data.

BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others similar tools just decode the BER/DER and present it in a "more" human readable form.

Regards,
Aram



Peter



-----Original Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram
Sent: Wednesday, June 04, 2008 6:04 PM
To: PKIX; ietf-smime@imc.org
Subject: Re: Web-based ASN.1 decoding tool available

On 6/4/08 6:53 AM, Peter Hesse  wrote:

All,

We have recently made available a web-based tool for doing an ASN.1 dump.  It
displays the ASCII HEX and the ASN structure, and when you hover over the
structure, it highlights the relevant portion of the hex. (Clicking makes the
highlight stick.)

Due to PHP’s inefficiency and memory usage during parsing, we have limited it
to files 64K and smaller.  Still, it is useful for displaying smaller objects
when you don’t have dumpasn1 installed or available.

It can be found here: http://geminisecurity.com/features-downloads/tools#fd_5
Click on “Click to try the application” under PHPdumpASN.

For Windows, you can also try BERViewer <http://homepage.mac.com/aramperez/berviewer.html> <http://homepage.mac.com/aramperez/berviewer.html> . I haven’t had time to remove the nag dialog box from the Mac version.

Regards,
Aram Perez






--
MySignatura2008
    Ricardo Barroso
Telefone: +351 217 123 010
Telemóvel: +351 968 332 327
Fax: +351 217 123 011		 Email:
ricardo.barroso@multicert.com		 MULTICERT S.A.
Estrada do Casal do Canas,
 Lote 6, Alfragide
2720-092 Amadora - Portugal

--------------060705050402080307010006 Content-Type: image/jpeg; name="MailLogoMULTICERT.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="MailLogoMULTICERT.jpg" /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CAAtAaYDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDkKdHTadHX0h8eiylTpUCVOlSzRFmOp46g jqeOoZoixHVlOgqtHVlOgrNmiJ0qzHVZKsx1mzVFiPtU8dQR9qnjqGaIsrU6VAtTpUGqLMdW EqvHVhKzZoiwnarCVXTtVhKhmqLMfap4+tQR9qnj61DNEWI6njqCOp46zZqiynSn0xOlPqDQ KKKKACiiigAooooAKKKKACimu6xozuwVFGWYnAA9a4ab4v8Ag+KZ4/ts8gU43pbsVP0OKlyU d2a06FSr/Di36Hd0VzGo+P8AQdJsrO5vpZ4TdrvihaE+bt/vFeqj61BpfxK8MavqEVjb3kiT ynbGJYigY9hk8ZrZUako86i7HPKpCMuST1OuopryJEu6R1RfVjgUoIYAggg8gisyxaKYZog5 QyoGAyV3DIFEcscoJjkVwOpU5oHYfRUfnw7ynmx7h1XcMiljmjlBMciPjrtYHFAWY+ioTd2w JBuIgR1G8Uoubds7Z4zgZOHHAoCzJaKakkcq7o3Vx0ypzTGurdSQ08QI6guKAsyWiml0Cbyy 7MZ3Z4xTFurd2CrPEzHoA4JNAWZLRUP2u2/5+Iv++xUiSxyjMbq4HdTmgLMdRUP2u2/5+If+ +xTo54pSRHKjkddrA0BZklFFFAj5Rp0dNp0dfSHx6LKVOlQJU6VLNEWY6njqCOp46hmiLEdW U6Cq0dWU6Cs2aInSrMdVkqzHWbNUWI+1Tx1BH2qeOoZoiytTpUC1OlQaosx1YSq8dWErNmiL CdqsJVdO1WEqGaosx9qnj61BH2qePrUM0RYjqeOoI6njrNmqLKdKfTE6U+oNAooooAKKKKAC iiigAooooAyfFHHhLWcf8+M//otq8X8M33h/QPh3Dqt5pFre6vJdyLaGWME5Xack+i5Fe1eJ Y3l8LavHGpZ3splVQOSShwK8H8N674Qh8KWlrrqXst7Y3EtxBHACFYttIBPTkqKmLpRrRdX4 T0KUK9TBVI4f4rotWOmx3lvN4y8Y3BkglzJbQmUKb113Zj9VHygAelGsXWk6lJ4V1TSdIi0t J7t0eKPGSUkQAkgD1NVy998QtSuNY1ic6Z4dtSDNtcmNCBjbGD1dvYd/wq9r+r6FrOreFdP8 MwSrBZzCMRGIr1dD+J4JJr0sLXrYiv7S1oK/psebj8HhsFh1RbvWbTfkd38Zv+RAf/r6i/ma 4TwD8RR4d8MarYXshd4IzNp6vzljxs+mSD9N1ei/FbTb3VfBT22n2k11ObiNvLiXc2ATk4rk tO+FLa5oHhy4vN1hcQK0d9DJGQ8iCRiB7HBxn0I9K8aal7S8ex72Fnh/qfJX2cv+D/wDiPBt xPd6/q1xcyPLPLpV67u5yWJjPNei/An/AJF7VP8Ar7X/ANAFZeieEdSPxQ1rztMubbS7lLuB J/KIQI42rg9OnSqehQeP/h5Ne2FjoP2+CVw28RNIjEcblKkEZGODUQTi035nVipQxEJU4NJt Re5T/wCav+Iv+uV9/wCiWro/gN/yDta/66w/+gtVLwv4O8R3mqa34m1qze2nmtbgRwFcPLJI hHC9gAcc+1ZXg+Xx34MguorHwrcTC5ZWcz278FQRxgj1ojeMlJruFflq0ZUoSV0orfsHxM8B 2/hiFdWiv5Z3vbxw0boAE3bm4IrVsPA0GifDrUvEUd9LLJfaKQ0LIAqbwrcH2xitb4j2Wu+J PAmhSLpM76g0qy3FvDESYiYznjqOTXQXWm3r/Bv+zltZje/2UsX2fb8+/YBtx61XIuZ2XQ53 i6nsKalLXms9tkzyaz1y90f4RPFYzPC97qzxSSIcMEESkgHtnium0b4LW2p6JZX1xrVwktzC szKkQIXcM4yeT1qnYeANa1T4XTWbWUtvqNtqTXMUE42GVTGqkDP6fSr2m+KviTpOmW+nr4Ta ZbaMRLI9s+SFGBnBwePSpil9taWOirUm1L6tNKXM76r5bmJ8R7yWLxJYeFrjUZYNI0+3giZ1 UnPyjMhUfeOMYFXfAuh+ELjxjYNpWv39xeQMZkiltNittHOTVvxx4T8RXmr6b4sstLW7mlgh a6szHv8ALlVRlSh6qemOvFXvC+peJF8SWKy+ALDTYZJNkt1DYNG0aEcndnii3v6ol1P9lSpy 6O+qWvW63PMtFsND1DWL6PXdXfTIFLGORIi+9t3TAB7Vt+HriLQfiPp1t4Y1afULK4ljilYx lBIGOGBXvgc5x2rf+HngSS48Rap/wkugSm1KEwm6iIUtv7e+KuWfhK98P/GaCfSdKuI9Gz/r VQtGitH8w3Hp81TGDsn5m1bFU5SnT5r+7tpbb77nJfETwJb+CksZIL+W6N20mRIgXbtweMfW vVvh94Dt/CqvqEV/LcNe28e5HQAL/Fxj61i/GfRNU1mDSBpmn3N4YzNv8mMttyFxnH0NelaY jxaTZxupV1gRWU9QQo4raFNKo9DzcVi6k8HBOV273276Fqiiiug8c+UadHTadHX0h8eiylTp UCVOlSzRFmOp46gjqeOoZoixHVlOgqtHVlOgrNmiJ0qzHVZKsx1mzVFiPtU8dQR9qnjqGaIs rU6VAtTpUGqLMdWEqvHVhKzZoiwnarCVXTtVhKhmqLMfap4+tQR9qnj61DNEWI6njqCOp46z ZqiynSn0xOlPqDQKKKKACiiigAooooAKKKKACsWXwh4cnlaWXQtOaRzlmNsuSfXpW1RSaT3K jOUfhdjNfw9o0thFYvpdo1pCd0cBiGxT6hemaSy8O6Lp1wLiy0qyt5gMCSOFVYfQ4rToq1KS Vk9CGk3zPcKKKKkYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH/2Q== --------------060705050402080307010006-- --------------020908070306050005030907-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55EYq2S075364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 07:34:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m55EYqBj075362; Thu, 5 Jun 2008 07:34:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55EYn7c075337; Thu, 5 Jun 2008 07:34:50 -0700 (MST) (envelope-from rybar@nbusr.sk) Message-Id: <200806051436.m55EaAf9010452@mail.nbusr.sk> From: "Peter Rybar" To: "'Aram Perez'" , "'PKIX'" , ietf-smime@imc.org Subject: RE: Web-based ASN.1 decoding tool available Date: Thu, 5 Jun 2008 16:35:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcjHGW+R09LPo1xoT+u+1UI0FfXXTQAALrmQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> X-NAI-Spam-Level: * X-NAI-Spam-Score: 1 X-NAI-Spam-Report: 3 Rules triggered * 1 -- INFO_TLD -- URI: Contains a URL in the INFO top-level domain * 0 -- MISSING_MSGID -- Missing Message-ID header * 0 -- RV3031 -- BODY: Version number Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, This one is also nice...=20 And somebody could try to use it in online PHP :-) with at least ASN.1 = modules which are described in PKIX, SMIME RFCs. http://lionet.info/asn1c/ Peter -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Aram Perez Sent: Thursday, June 05, 2008 4:03 PM To: PKIX; ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available Hi Peter, =09 Have you any free tools which are not the simple dump of asn1 DER/BER = but which also can read a data according the 1988, 93 ASN.1 Syntax?=20 Like default values from DER... I'm afraid I do not and I'm not aware of any such tool. To get the = default values, you would need the actual ASN.1 (which provides the = default values) and the BER/DER data. BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others = similar tools just decode the BER/DER and present it in a "more" human = readable form. Regards, Aram Peter =09 =09 =09 -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram Sent: Wednesday, June 04, 2008 6:04 PM To: PKIX; ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available =09 On 6/4/08 6:53 AM, Peter Hesse wrote: =09 =09 All, =09 We have recently made available a web-based tool for doing an ASN.1 = dump. It=20 =09 displays the ASCII HEX and the ASN structure, and when you hover over = the=20 =09 structure, it highlights the relevant portion of the hex. (Clicking = makes the=20 =09 highlight stick.) =09 Due to PHP=E2=80=99s inefficiency and memory usage during parsing, we = have limited it=20 =09 to files 64K and smaller. Still, it is useful for displaying smaller = objects=20 =09 when you don=E2=80=99t have dumpasn1 installed or available. =09 It can be found here: = http://geminisecurity.com/features-downloads/tools#fd_5 =09 Click on =E2=80=9CClick to try the application=E2=80=9D under = PHPdumpASN. =09 For Windows, you can also try BERViewer = = . I haven=E2=80=99t = had time to remove the nag dialog box from the Mac version. =09 Regards, Aram Perez =09 =09 =09 =09 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55E3IHY068344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 07:03:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m55E3IZA068343; Thu, 5 Jun 2008 07:03:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.68]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55E3GL1068331; Thu, 5 Jun 2008 07:03:17 -0700 (MST) (envelope-from aramperez@mac.com) Received: from asmtp016-bge351000 (asmtp016-bge351000 [10.150.69.79]) by smtpoutm.mac.com (Xserve/smtpout005/MantshX 4.0) with ESMTP id m55E3G21024009; Thu, 5 Jun 2008 07:03:16 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ)" Received: from [192.168.1.3] ([76.88.67.30]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K1Z00M9UTPD0P20@asmtp016.mac.com>; Thu, 05 Jun 2008 07:03:16 -0700 (PDT) Message-id: <7CF18E27-23FD-464F-8BCE-1D53E8257DF7@mac.com> From: Aram Perez To: PKIX , ietf-smime@imc.org In-reply-to: <200806051325.m55DPCtJ009671@mail.nbusr.sk> Subject: Re: Web-based ASN.1 decoding tool available Date: Thu, 05 Jun 2008 07:03:12 -0700 References: <200806051325.m55DPCtJ009671@mail.nbusr.sk> X-Mailer: Apple Mail (2.924) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ) Content-type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-transfer-encoding: quoted-printable Hi Peter, > > Have you any free tools which are not the simple dump of asn1 DER/=20 > BER but which also can read a data according the 1988, 93 ASN.1 =20 > Syntax? > Like default values from DER... I'm afraid I do not and I'm not aware of any such tool. To get the =20 default values, you would need the actual ASN.1 (which provides the =20 default values) and the BER/DER data. BERViewer, Peter Hesse's web tool, Peter Gutmann's dumpasn1 and others =20= similar tools just decode the BER/DER and present it in a "more" human =20= readable form. Regards, Aram > > > Peter > > > > -----Original Message----- > From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org=20 > ] On Behalf Of Perez, Aram > Sent: Wednesday, June 04, 2008 6:04 PM > To: PKIX; ietf-smime@imc.org > Subject: Re: Web-based ASN.1 decoding tool available > > On 6/4/08 6:53 AM, Peter Hesse wrote: > >> All, >> >> We have recently made available a web-based tool for doing an ASN.1 =20= >> dump. It >> displays the ASCII HEX and the ASN structure, and when you hover =20 >> over the >> structure, it highlights the relevant portion of the hex. (Clicking =20= >> makes the >> highlight stick.) >> >> Due to PHP=92s inefficiency and memory usage during parsing, we have =20= >> limited it >> to files 64K and smaller. Still, it is useful for displaying =20 >> smaller objects >> when you don=92t have dumpasn1 installed or available. >> >> It can be found here: = http://geminisecurity.com/features-downloads/tools#fd_5 >> Click on =93Click to try the application=94 under PHPdumpASN. > > For Windows, you can also try BERViewer = > . I haven=92t had = =20 > time to remove the nag dialog box from the Mac version. > > Regards, > Aram Perez > > > --Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ) Content-type: text/html; charset=WINDOWS-1252 Content-transfer-encoding: quoted-printable Hi Peter,

Have you any free tools which are not the = simple dump of asn1 DER/BER but which also can read a data according the = 1988, 93 ASN.1 Syntax?
Like default values from = DER...

I'm afraid I do not and I'm = not aware of any such tool. To get the default values, you would need = the actual ASN.1 (which provides the default values) and the BER/DER = data.

BERViewer, Peter Hesse's web tool, Peter = Gutmann's dumpasn1 and others similar tools just decode the BER/DER and = present it in a "more" human readable = form.

Regards,
Aram



Peter



-----Original= Message-----
From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail= .imc.org] On Behalf Of Perez, Aram
Sent: Wednesday, June 04, 2008 = 6:04 PM
To: PKIX; ietf-smime@imc.org
Subject: = Re: Web-based ASN.1 decoding tool available

On 6/4/08 6:53 AM, = Peter Hesse  wrote:

All,

We have = recently made available a web-based tool for doing an ASN.1 dump. =  It
displays the ASCII = HEX and the ASN structure, and when you hover over the =
structure, it highlights the = relevant portion of the hex. (Clicking makes the =
highlight = stick.)

Due to PHP=92s = inefficiency and memory usage during parsing, we have limited it =
to files 64K and smaller. =  Still, it is useful for displaying smaller objects =
when you don=92t have = dumpasn1 installed or available.

It can be found = here: http://ge= minisecurity.com/features-downloads/tools#fd_5
Click on =93Click to try the application=94 under = PHPdumpASN.

For Windows, you can also try BERViewer = <http://homepage.= mac.com/aramperez/berviewer.html> <http://homepage.= mac.com/aramperez/berviewer.html> . I haven=92t had time to remove = the nag dialog box from the Mac version.

Regards,
Aram = Perez




= --Boundary_(ID_FkuvH/Tz1lYEXqbTGUCRSQ)-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55DNtrn059437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2008 06:23:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m55DNtur059436; Thu, 5 Jun 2008 06:23:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m55DNqHj059413; Thu, 5 Jun 2008 06:23:53 -0700 (MST) (envelope-from rybar@nbusr.sk) Message-Id: <200806051325.m55DPCtJ009671@mail.nbusr.sk> From: "Peter Rybar" To: "'Perez, Aram'" , "'PKIX'" , ietf-smime@imc.org Subject: RE: Web-based ASN.1 decoding tool available Date: Thu, 5 Jun 2008 15:24:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcjGSlK0B56RJ/K4QmuS9tqZTIyH0AAEj9f7ACxVXxA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-NAI-Spam-Score: 0 X-NAI-Spam-Report: 2 Rules triggered * 0 -- MISSING_MSGID -- Missing Message-ID header * 0 -- RV3031 -- BODY: Version number Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Have you any free tools which are not the simple dump of asn1 DER/BER = but which also can read a data according the 1988, 93 ASN.1 Syntax?=20 Like default values from DER... Peter -----Original Message----- From: owner-ietf-smime@mail.imc.org = [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Perez, Aram Sent: Wednesday, June 04, 2008 6:04 PM To: PKIX; ietf-smime@imc.org Subject: Re: Web-based ASN.1 decoding tool available On 6/4/08 6:53 AM, Peter Hesse wrote: > All, > =20 > We have recently made available a web-based tool for doing an ASN.1 = dump. It=20 > displays the ASCII HEX and the ASN structure, and when you hover over = the=20 > structure, it highlights the relevant portion of the hex. (Clicking = makes the=20 > highlight stick.) > =20 > Due to PHP=E2=80=99s inefficiency and memory usage during parsing, we = have limited it=20 > to files 64K and smaller. Still, it is useful for displaying smaller = objects=20 > when you don=E2=80=99t have dumpasn1 installed or available. > =20 > It can be found here: = http://geminisecurity.com/features-downloads/tools#fd_5 > Click on =E2=80=9CClick to try the application=E2=80=9D under = PHPdumpASN. For Windows, you can also try BERViewer = = . I haven=E2=80=99t = had time to remove the nag dialog box from the Mac version. Regards, Aram Perez Received: from sub-223ip198.onenet.an ([190.4.148.231]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m557quHc075175 for ; Thu, 5 Jun 2008 00:53:00 -0700 (MST) (envelope-from o^leuses1991@Icmint.com) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vmrPwTSXSDZdg2nhCxISCP)" Message-id: <58DA8AD3-C7FA-5449-A364-0086DA9D9B0F@Icmint.com> From: Toivanen To: ietf-pkix-archive@imc.org Subject: Massive inches in weeks Date: Thu, 5 Jun 2008 03:52:58 -0400 X-Mailer: Apple Mail (2.924) --Boundary_(ID_vmrPwTSXSDZdg2nhCxISCP) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT Most women find a large, muscular manhood and incredible visual turn on - upsize yours today. http://www.samurfs.com/ --Boundary_(ID_vmrPwTSXSDZdg2nhCxISCP) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT Most women find a large, muscular manhood and incredible visual turn on - upsize yours today. --Boundary_(ID_vmrPwTSXSDZdg2nhCxISCP)-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m54G3q28053226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 09:03:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m54G3q8Z053224; Wed, 4 Jun 2008 09:03:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m54G3pg0053206 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Wed, 4 Jun 2008 09:03:52 -0700 (MST) (envelope-from aramp@qualcomm.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=aramp@qualcomm.com; q=dns/txt; s=qcdkim; t=1212595432; x=1244131432; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Perez,=20Aram"=20|To:=20PKI X=20,=20"ietf-smime@imc.org"=20|Date:=20Wed,=204=20Jun=202008=2009:03:47=20 -0700|Subject:=20Re:=20Web-based=20ASN.1=20decoding=20too l=20available|Thread-Topic:=20Web-based=20ASN.1=20decodin g=20tool=20available|Thread-Index:=20AcjGSlK0B56RJ/K4QmuS 9tqZTIyH0AAEj9f7|Message-ID:=20|In-Reply-To:=20<50a001c8c64a$543e55b0$fcbb0110$@ com>|Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C46C0AF3F950arampqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 200,2160,5309"=3B=20a=3D"3673079"; bh=AnTuq5KFYeB8xBRr15aB8mR9qciaTkpwkm7gN2kPfvM=; b=hcsaii9veicIk67RE2REQPaG/uvkRsUraHECzsRIpx6RQ+Z+2gU0PTSL 9cl681oGsRAtxuuNw+DWz5WstKzAMtEEbagdYh8IAtV90grXLXT73cAWf CqetJeMUugnnADdBKy4I1s5AKs/Bzp5SGbbWx7Qc6ttwu7hmmghRMLMF9 A=; X-IronPort-AV: E=McAfee;i="5200,2160,5309"; a="3673079" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jun 2008 09:03:51 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m54G3p6Y004910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Jun 2008 09:03:51 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m54G3oR9025029 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Jun 2008 09:03:51 -0700 Received: from nasanex01a.na.qualcomm.com (129.46.132.246) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 4 Jun 2008 09:03:50 -0700 Received: from NASANEXMB05.na.qualcomm.com ([129.46.52.178]) by nasanex01a.na.qualcomm.com ([129.46.132.246]) with mapi; Wed, 4 Jun 2008 09:03:50 -0700 From: "Perez, Aram" To: PKIX , "ietf-smime@imc.org" Date: Wed, 4 Jun 2008 09:03:47 -0700 Subject: Re: Web-based ASN.1 decoding tool available Thread-Topic: Web-based ASN.1 decoding tool available Thread-Index: AcjGSlK0B56RJ/K4QmuS9tqZTIyH0AAEj9f7 Message-ID: In-Reply-To: <50a001c8c64a$543e55b0$fcbb0110$@com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C46C0AF3F950arampqualcommcom_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_C46C0AF3F950arampqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 6/4/08 6:53 AM, Peter Hesse wrote: > All, > > We have recently made available a web-based tool for doing an ASN.1 dump.= It > displays the ASCII HEX and the ASN structure, and when you hover over the > structure, it highlights the relevant portion of the hex. (Clicking makes= the > highlight stick.) > > Due to PHP's inefficiency and memory usage during parsing, we have limite= d it > to files 64K and smaller. Still, it is useful for displaying smaller obj= ects > when you don't have dumpasn1 installed or available. > > It can be found here: http://geminisecurity.com/features-downloads/tools#= fd_5 > Click on "Click to try the application" under PHPdumpASN. For Windows, you can also try BERViewer . I haven'= t had time to remove the nag dialog box from the Mac version. Regards, Aram Perez --_000_C46C0AF3F950arampqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Web-based ASN.1 decoding tool available O= n 6/4/08 6:53 AM, Peter Hesse  wrote:

> All,
>  
> We have recently made available a web-based tool for doing an ASN.1 du= mp.  It
> displays the ASCII HEX and the ASN structure, and when you hover over = the
> structure, it highlights the relevant portion of the hex. (Clicking ma= kes the
> highlight stick.)
>  
> Due to PHP’s inefficiency and memory usage during parsing, we ha= ve limited it
> to files 64K and smaller.  Still, it is useful for displaying sma= ller objects
> when you don’t have dumpasn1 installed or available.
>  
> It can be found here: http://geminisecurity.com/features-downloads/tools#fd_5=
> Click on “Click to try the application” under PHPdumpASN.<= BR>
For Windows, you can also try BERViewer <http://homepage.mac.com/aramperez/berviewer.h= tml>. I haven’t had time to remove the nag dialog box from the= Mac version.

Regards,
Aram Perez
 --_000_C46C0AF3F950arampqualcommcom_-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m54DrF4v025270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 06:53:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m54DrFMd025269; Wed, 4 Jun 2008 06:53:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from prospect.joyent.us (prospect.joyent.us [8.12.36.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m54DrDNh025250; Wed, 4 Jun 2008 06:53:13 -0700 (MST) (envelope-from pmhesse@geminisecurity.com) Received: from PeterVT43 (static-68-163-72-26.res.east.verizon.net [68.163.72.26]) by prospect.joyent.us (Postfix) with ESMTP id 07AF288883; Wed, 4 Jun 2008 13:53:11 +0000 (GMT) From: "Peter Hesse" To: "'pkix'" , Subject: Web-based ASN.1 decoding tool available Date: Wed, 4 Jun 2008 09:53:10 -0400 Message-ID: <50a001c8c64a$543e55b0$fcbb0110$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_50A1_01C8C628.CD2CB5B0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcjGSlK0B56RJ/K4QmuS9tqZTIyH0A== Content-Language: en-us Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_50A1_01C8C628.CD2CB5B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, We have recently made available a web-based tool for doing an ASN.1 dump. It displays the ASCII HEX and the ASN structure, and when you hover over the structure, it highlights the relevant portion of the hex. (Clicking makes the highlight stick.) Due to PHP's inefficiency and memory usage during parsing, we have limited it to files 64K and smaller. Still, it is useful for displaying smaller objects when you don't have dumpasn1 installed or available. It can be found here: http://geminisecurity.com/features-downloads/tools#fd_5 Click on "Click to try the application" under PHPdumpASN. Enjoy! Please send me any feedback. --Peter Hesse _____ Peter Hesse pmhesse@geminisecurity.com Phone: 703-378-5808 x105 Gemini Security Solutions, Inc. Visit our relaunched website! http://geminisecurity.com "A good programmer is someone who always looks both ways before crossing a one-way street." --Doug Linder ------=_NextPart_000_50A1_01C8C628.CD2CB5B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

We have recently made available a web-based tool = for doing an ASN.1 dump.  It displays the ASCII HEX and the ASN structure, = and when you hover over the structure, it highlights the relevant portion of the = hex.  (Clicking makes the highlight stick.)

 

Due to PHP’s inefficiency and memory usage = during parsing, we have limited it to files 64K and smaller.  Still, it is = useful for displaying smaller objects when you don’t have dumpasn1 installed or = available.

 

It can be found here: http://g= eminisecurity.com/features-downloads/tools#fd_5

Click on “Click to try the application” = under PHPdumpASN.

 

Enjoy!  Please send me any = feedback.

 

--Peter Hesse

 

 Peter Hesse           &n= bsp;           pmhesse@gemini= security.com

 Phone: = 703-378-5808 x105      Gemini Security Solutions, = Inc.

    Visit our relaunched website! http://geminisecurity.com

"A good programmer is someone who always looks both = ways before
 crossing a one-way street." --Doug = Linder

 

------=_NextPart_000_50A1_01C8C628.CD2CB5B0-- Received: from host126-180-static.38-88-b.business.telecomitalia.it (host126-180-static.38-88-b.business.telecomitalia.it [88.38.180.126]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m53N4T8n001685 for ; Tue, 3 Jun 2008 16:04:33 -0700 (MST) (envelope-from Santiago-vty:n@3-klank.nl) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_aoeExQLEYOVat5fcSrSEGF)" Message-id: From: debuhr To: ietf-pkix-archive@imc.org Subject: The most beautiful women on Earth Date: Wed, 4 Jun 2008 01:04:32 +0200 X-Mailer: Apple Mail (2.924) --Boundary_(ID_aoeExQLEYOVat5fcSrSEGF) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT You now know the importance of an increased length http://www.loastern.com/ --Boundary_(ID_aoeExQLEYOVat5fcSrSEGF) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT You now know the importance of an increased length --Boundary_(ID_aoeExQLEYOVat5fcSrSEGF)--