trust anchor management problem statement

From owner-ietf-trust-anchor Fri Jun 8 05:05:00 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l58C50Sn080305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jun 2007 05:05:00 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l58C50FG080304; Fri, 8 Jun 2007 05:05:00 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l58C4vJH080289 for ; Fri, 8 Jun 2007 05:04:59 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 2051 invoked from network); 8 Jun 2007 12:03:36 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;08 Jun 2007 12:03:36 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 8 Jun 2007 12:03:36 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Fri, 8 Jun 2007 08:04:55 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: trust anchor management problem statement Date: Fri, 8 Jun 2007 08:04:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A9C5.39D42F68" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C7A9C5.39D42F68 Content-Type: text/plain FYI, since it was posted after the mailing list was set-up, the initial draft of a problem statement for the proposed trust anchor management BOF can be found here: http://www.ietf.org/internet-drafts/draft-wallace-ta-mgmt-problem-statement- 00.txt. ------_=_NextPart_001_01C7A9C5.39D42F68 Content-Type: text/html Content-Transfer-Encoding: quoted-printable trust anchor management problem statement

FYI, since it was posted after the mailing list was = set-up, the initial draft of a problem statement for the proposed trust = anchor management BOF can be found here: http://www.ietf.org/internet-drafts/draft-wallace-ta-m= gmt-problem-statement-00.txt.

------_=_NextPart_001_01C7A9C5.39D42F68-- From owner-ietf-trust-anchor Mon Jun 11 16:55:51 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5BNtpMG081468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2007 16:55:51 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5BNtpu9081467; Mon, 11 Jun 2007 16:55:51 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5BNtnfo081461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Jun 2007 16:55:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> Date: Mon, 11 Jun 2007 16:55:46 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Types of object for trust anchors Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. One thing that I didn't see in section 3 of draft-wallace-ta-mgmt-problem-statement-00 was something acknowledging that trust anchors might come in multiple formats. At a minimum, some systems want them as bare public keys and others want them as certificates. In the latter category, some systems would want them as PKIX certificates and some would want them as PGP certificates. It makes sense to allow one set of trust anchors being delivered to contain multiple types and let the receiver sort out which types it can use. So, an additional requirement might be that the trust anchor protocol be able to deliver different types of trust anchors, and that each anchor is appropriately marked (probably by an OID). --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Mon Jun 11 17:26:25 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C0QOuP083236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2007 17:26:24 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5C0QOpm083235; Mon, 11 Jun 2007 17:26:24 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C0QNIJ083222; Mon, 11 Jun 2007 17:26:24 -0700 (MST) (envelope-from mcr@marajade.sandelman.ca) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [205.150.200.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marajade.sandelman.ca.", Issuer "Michael Richardson" (verified OK)) by cod.sandelman.ca (Postfix) with ESMTP id B7C6B1263E; Mon, 11 Jun 2007 20:26:22 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 5213D4E7A7; Mon, 11 Jun 2007 20:26:17 -0400 (EDT) From: Michael Richardson To: Paul Hoffman cc: ietf-trust-anchor@vpnc.org Subject: Re: Types of object for trust anchors In-Reply-To: Message from Paul Hoffman of "Mon, 11 Jun 2007 16:55:46 PDT." References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) Date: Mon, 11 Jun 2007 20:26:16 -0400 Message-ID: <11394.1181607976@marajade.sandelman.ca> Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Paul" == Paul Hoffman writes: Paul> Greetings again. One thing that I didn't see in section 3 of Paul> draft-wallace-ta-mgmt-problem-statement-00 was something Paul> acknowledging that trust anchors might come in multiple Paul> formats. At a minimum, some systems want them as bare public Paul> keys and others want them as certificates. In the latter Paul> category, some systems would want them as PKIX certificates I didn't see a lot of mention of bare public keys in the document. Nor as PGP certificates. Paul> and some would want them as PGP certificates. It makes sense Paul> to allow one set of trust anchors being delivered to contain Paul> multiple types and let the receiver sort out which types it Paul> can use. That seems more complicated (in code space) than just making everyone use BER CMS to me... I would say that it's either something like YAML + DNS presentation format of bare keys, or CMS. Not both. I also think that some SPKI stuff needs to br brought up in the BOF. Specifically, relating to section 3, paragraph 3. While I appreciate section 4, I'd rather that it be removed and placed into a seperate document prior to the BOF. Who are the BOF chairs? - -- ] Bear: "Me, I'm just the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRm3oJoCLcPvd0N1lAQI+IAgAwT2WqtWmEjrTnfRxQskcdE2wgQ4zhrtu HbVaUPx8vD4vR8nGm1ameenKUaNq1wP1x75VDjC18fOzA5uK6ynSS3NjlGSAuZHF Oueinl89NjGSITBDsMhz/PO/iGOIDbv4Cc0aLomCZ1DcFV2pRPgNQaAL1Xz0d9PB GNdg+iezcBpZMzyJ7aJRMVZRemawch+VLxiVI/SfxdkdAFcl/9kAzCrvRzLMJzkS z0Z4y9WbIriDODU3qPDP8NdcIUNCVt9u4lH4OLAPExsCuevnWQzYE9fBHwJ8x3oP WGkss0IS4YYeZqiLITJKq5gkNL0FslZNg4fnbccjqiXhkCS/FIodeA== =o750 -----END PGP SIGNATURE----- From owner-ietf-trust-anchor Mon Jun 11 18:22:17 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C1MHfJ085917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2007 18:22:17 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5C1MHNc085916; Mon, 11 Jun 2007 18:22:17 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C1MFJk085909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Jun 2007 18:22:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <11394.1181607976@marajade.sandelman.ca> References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> <11394.1181607976@marajade.sandelman.ca> Date: Mon, 11 Jun 2007 18:19:31 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Re: Types of object for trust anchors Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:26 PM -0400 6/11/07, Michael Richardson wrote: > Paul> and some would want them as PGP certificates. It makes sense > Paul> to allow one set of trust anchors being delivered to contain > Paul> multiple types and let the receiver sort out which types it > Paul> can use. > > That seems more complicated (in code space) than just making everyone >use BER CMS to me... BER CMS of *what*? A bare public key? A cert of a particular format? What I'm thinking is a requirement for flexibility is not the housing, but the contents. >I would say that it's either something like YAML + >DNS presentation format of bare keys, or CMS. Not both. If you are saying "no certs allowed", then it makes the solution unusable for IE, for Mac OSX, and for Firefox. That feels kinda limiting to me. > I also think that some SPKI stuff needs to br brought up in the BOF. > Specifically, relating to section 3, paragraph 3. I don't see why that is SPKI specific... It seems quite relevant to PGP certs, and should be relevant to PKIX certs. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Mon Jun 11 18:23:44 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C1NhQT085988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2007 18:23:43 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5C1Nhqq085987; Mon, 11 Jun 2007 18:23:43 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C1NgN0085981 for ; Mon, 11 Jun 2007 18:23:43 -0700 (MST) (envelope-from jon@pgpeng.com) Received: from keys.pgpeng.com (keys.pgpeng.com [127.0.0.1]) by keys.pgpeng.com (PGP Universal) with ESMTP id B7D54F0152 for ; Mon, 11 Jun 2007 18:23:42 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Mon, 11 Jun 2007 18:23:42 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Mon, 11 Jun 2007 18:23:42 -0700 Received: from [63.251.255.74] (account jon HELO keys.pgpeng.com) by pgpeng.com (CommuniGate Pro SMTP 4.3.7) with ESMTPSA id 1807112 for ietf-trust-anchor@vpnc.org; Mon, 11 Jun 2007 18:23:42 -0700 Received: from [63.251.255.205] ([63.251.255.205]) by keys.pgpeng.com (PGP Universal service); Mon, 11 Jun 2007 18:23:42 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Mon, 11 Jun 2007 18:23:42 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> Message-Id: <737A8762-2ADA-4B1D-A549-65F56FBBDD0B@pgpeng.com> From: Jon Callas Subject: Re: Types of object for trust anchors Date: Mon, 11 Jun 2007 18:24:07 -0700 To: ietf-trust-anchor@vpnc.org X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would like to see a better description of what you mean by a trust anchor. I know what you mean, but it took me a couple readings. A scenario or use case would help a lot. Paul Hoffman brings up a very good point as well. In my reading of it at first I noted that you were only talking about ASN.1 and CMS, and thus shackled my thinking around X.509 and PKIX. However, I think that not only should you cover OpenPGP certificates as well, but at the very least anything you can store in the DNS via RFC 4398, as well as being able to specify trust anchors for key-centric systems such as DKIM where the trust anchor *is* DNS and yet there are those who want more security but not a tacit presumption that DNSSEC will be both necessary and sufficient. Lastly, I don't want to get into yet another debate about ASN.1, particularly since you're using CMS and CMS is one of the few places where there haven't been horrible security problems using ASN.1, but these days self-describing data is pretty universally encoded with XML. Love it or hate it, it seems that everything can parse XML. A trust anchor syntax that is ASN.1-only would be pretty limited, and would get us yet another set of ways to buffer-overflow a system by giving it a bizarrely coded ASN.1 object. At a minimum, there should both an ASN.1 and an XML syntax if we want this to be widely used. Alternatively, the trust anchors could be coded only in XML and that XML structure protected with CMS, or OpenPGP, or even XML-based protection. If there is no XML syntax, then at the end of the day we'll have to make one anyway, so why not just do it up front? Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 3460 West Bayshore Fax: +1 (650) 319-9001 Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From owner-ietf-trust-anchor Mon Jun 11 19:24:35 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C2OZc9089015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2007 19:24:35 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5C2OZ88089014; Mon, 11 Jun 2007 19:24:35 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C2OYVq089001; Mon, 11 Jun 2007 19:24:34 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.117.70]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hxw3c-0007Ml-4o; Mon, 11 Jun 2007 22:24:32 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <11394.1181607976@marajade.sandelman.ca> References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> <11394.1181607976@marajade.sandelman.ca> Date: Mon, 11 Jun 2007 22:24:27 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: Types of object for trust anchors Cc: Paul Hoffman , ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >... > I also think that some SPKI stuff needs to br brought up in the BOF. > Specifically, relating to section 3, paragraph 3. > SPKI is not a standards track PKI RFC model, unlike X.509, OpenPGP, and DNSSEC. Thus it does not necessarily merit equal consideration here. Steve From owner-ietf-trust-anchor Mon Jun 11 19:24:22 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C2OMYD088988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2007 19:24:22 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5C2OMOf088987; Mon, 11 Jun 2007 19:24:22 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C2OJGO088974; Mon, 11 Jun 2007 19:24:21 -0700 (MST) (envelope-from mcr@marajade.sandelman.ca) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [205.150.200.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marajade.sandelman.ca.", Issuer "Michael Richardson" (verified OK)) by cod.sandelman.ca (Postfix) with ESMTP id DE0AF12624; Mon, 11 Jun 2007 22:24:18 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 149CA4E7A7; Mon, 11 Jun 2007 22:24:17 -0400 (EDT) From: Michael Richardson To: Paul Hoffman cc: ietf-trust-anchor@vpnc.org Subject: Re: Types of object for trust anchors In-Reply-To: Message from Paul Hoffman of "Mon, 11 Jun 2007 18:19:31 PDT." References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> <11394.1181607976@marajade.sandelman.ca> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) Date: Mon, 11 Jun 2007 22:24:17 -0400 Message-ID: <15541.1181615057@marajade.sandelman.ca> Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Paul" == Paul Hoffman writes: >> That seems more complicated (in code space) than just making >> everyone use BER CMS to me... Paul> BER CMS of *what*? A bare public key? A cert of a particular Paul> format? What I'm thinking is a requirement for flexibility is Paul> not the housing, but the contents. >> I would say that it's either something like YAML + DNS >> presentation format of bare keys, or CMS. Not both. Paul> If you are saying "no certs allowed", then it makes the Paul> solution unusable for IE, for Mac OSX, and for Firefox. That Paul> feels kinda limiting to me. I don't see your point. Either new code is necessary, or it's not. If it's not new code, then it has to be an existing format, which is implemented already. If it it's new code, then it's new code. >> I also think that some SPKI stuff needs to br brought up in the >> BOF. Specifically, relating to section 3, paragraph 3. Paul> I don't see why that is SPKI specific... It seems quite Paul> relevant to PGP certs, and should be relevant to PKIX certs. SPKI made some very clear statements about what it means to have trust anchors, and how you can trust them. If you want to have trust anchors for specific things, but not trust them for other thiings, then SPKI has ways to express that, or at least, has some (english) language for explaining that. - -- ] Bear: "Me, I'm just the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRm4D0ICLcPvd0N1lAQLgRAf+LHe+MN7JV2i077OMmv6cUB5mDyr691I0 xMltr9Xa5f1wCNcAlWs+Ap8QWwInt64s688L4qXKZbaKUFFhx7IXgVtMz+jo4rTN 8lsSBVL5fEkBP++t6DDzCAVMZX4Yp0cU2vJ27kW7NaxbXICcu1lm8kFwIiucyLK/ iIB2aQz+052Zv58spVzU3GAqpTABtN4xxwd9sNx6FC+6xynUGp1/BbS2a9ieBCar ifTUnkC7E+YJ0v2o472IrZRbX0geo+LdhYfwR4w3zFQcLCaifkFnKo0s8a58i9XT c3kcKvGpI7nHehhEilCaAvWfCAym0d1lemo+n63IhNVFp+uudL6VPQ== =n6oH -----END PGP SIGNATURE----- From owner-ietf-trust-anchor Mon Jun 11 19:24:33 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C2OXuc088999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2007 19:24:33 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5C2OXNq088998; Mon, 11 Jun 2007 19:24:33 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C2OWEr088992 for ; Mon, 11 Jun 2007 19:24:33 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.117.70]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hxw3b-0007Ml-4p; Mon, 11 Jun 2007 22:24:31 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <737A8762-2ADA-4B1D-A549-65F56FBBDD0B@pgpeng.com> References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> <737A8762-2ADA-4B1D-A549-65F56FBBDD0B@pgpeng.com> Date: Mon, 11 Jun 2007 22:20:48 -0400 To: Jon Callas From: Stephen Kent Subject: Re: Types of object for trust anchors Cc: ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 6:24 PM -0700 6/11/07, Jon Callas wrote: >I would like to see a better description of what you mean by a trust >anchor. I know what you mean, but it took me a couple readings. A >scenario or use case would help a lot. > >Paul Hoffman brings up a very good point as well. In my reading of >it at first I noted that you were only talking about ASN.1 and CMS, >and thus shackled my thinking around X.509 and PKIX. However, I >think that not only should you cover OpenPGP certificates as well, >but at the very least anything you can store in the DNS via RFC >4398, as well as being able to specify trust anchors for key-centric >systems such as DKIM where the trust anchor *is* DNS and yet there >are those who want more security but not a tacit presumption that >DNSSEC will be both necessary and sufficient. It is certainly within the purview of a BOF to decide the scope of this work. That could be purely X.509-centric, or including OpenPGP certs and DNSSEC as well. But, what other PKI models use the term "rust anchor?" I tend to associate it with the X.509 and derivative specs, e.g., RFC 3280. >Lastly, I don't want to get into yet another debate about ASN.1, >particularly since you're using CMS and CMS is one of the few places >where there haven't been horrible security problems using ASN.1, but >these days self-describing data is pretty universally encoded with >XML. Love it or hate it, it seems that everything can parse XML. A >trust anchor syntax that is ASN.1-only would be pretty limited, and >would get us yet another set of ways to buffer-overflow a system by >giving it a bizarrely coded ASN.1 object. Surely you are not suggesting that ASN.1 decoders are more prone to buffer overflow than other software. ASN.1 syntax would be appropriate for an X.509-centric activity. Accommodating other PKI models would argue for additional syntax options. >At a minimum, there should both an ASN.1 and an XML syntax if we >want this to be widely used. Alternatively, the trust anchors could >be coded only in XML and that XML structure protected with CMS, or >OpenPGP, or even XML-based protection. If there is no XML syntax, >then at the end of the day we'll have to make one anyway, so why not >just do it up front? XML syntax might be appropriate IF the BOF decides to encompass PKI models beyond X.509. Steve From owner-ietf-trust-anchor Tue Jun 12 07:59:27 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CExRkK028861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 07:59:27 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5CExR3U028860; Tue, 12 Jun 2007 07:59:27 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CExNsL028849 for ; Tue, 12 Jun 2007 07:59:26 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l5CExL2h014213 for ; Tue, 12 Jun 2007 16:59:22 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AD02.41BED89F" Subject: trust anchors mgmt- comments Date: Tue, 12 Jun 2007 16:59:21 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868011E4330@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: trust anchors mgmt- comments Thread-Index: AcetAkHgJgQi7/nwRUmXd+M4wZ15lw== X-Priority: 5 Importance: low From: "Tobias Gondrom" To: Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AD02.41BED89F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, the document is a good first write-up for a BOF.=20 I take it that the ta mgmt. should be the focus of the BOF, so I would = agree with Michael and rather prefer it to be not bound to one format, = leaving section 4 about CMS to a separate solution I-D and not in the = first mission statement, though for the BOF it is definitely good to = have that section at this time so that people know where we are heading. Besides CMS the BOF should definitely also cover XML.=20 And I am not so sure about the documents that shall be produced in the = planned WG? - document specifying define ta in CMS - new data format for package of ta data (container, ???) - data structure for region limits for tas (sign code, sign other tas)? = (which looks like what we already have in a bit unstructured way with = CMS attributes today?) - protocol how to get ta? Any opinions?=20 Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der = Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: = +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, = Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID: = DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton This email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C7AD02.41BED89F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable trust anchors mgmt- comments

Hello,

the = document is a good first write-up for a BOF. =

I take it that the ta mgmt. should be the focus of the BOF, so I would agree = with Michael and rather prefer it to be not bound to one = format, leaving section 4 about CMS to a separate solution I-D and not in the first mission statement, though for the = BOF it is definitely good to have that section at this time so that people know where we are = heading.

Besides CMS the BOF should definitely also cover = XML.

And I = am not so sure about the documents that shall be produced in the planned = WG?

- document specifying define ta in CMS

- new = data format for package of ta data (container, ???)

- data structure for region limits for tas (sign code, sign other = tas)? = (which looks like what we already have in a bit unstructured way with CMS attributes today?)

- = protocol how to get ta?

Any = opinions?

Tobias

__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team
Director, Product Security

Open Text = Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/ =

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift = 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) = 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | = Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID: DE 114 = 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton

This = email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized = Recipient") for the purpose for which it was sent by OTC. All other = rights and licenses to this email are fully reserved to OTC. If you are = not an Authorized Recipient, you are required to immediately delete this = email in its entirety without printing, copying, using, and/or = re-transmitting this email, either in whole or in part. The transmission = of this email by OTC is not to be construed as a waiver by OTC and/or = the individual sending this email on behalf of OTC of any of their = respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C7AD02.41BED89F-- From owner-ietf-trust-anchor Tue Jun 12 11:01:36 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CI1a5h041823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 11:01:36 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5CI1aV1041822; Tue, 12 Jun 2007 11:01:36 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CI1ZrA041816 for ; Tue, 12 Jun 2007 11:01:35 -0700 (MST) (envelope-from jon@pgpeng.com) Received: from keys.pgpeng.com (keys.pgpeng.com [127.0.0.1]) by keys.pgpeng.com (PGP Universal) with ESMTP id 0E49DF0172 for ; Tue, 12 Jun 2007 11:01:35 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Tue, 12 Jun 2007 11:01:35 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Tue, 12 Jun 2007 11:01:35 -0700 Received: from [63.251.255.74] (account jon HELO keys.pgpeng.com) by pgpeng.com (CommuniGate Pro SMTP 4.3.7) with ESMTPSA id 1808402 for ietf-trust-anchor@vpnc.org; Tue, 12 Jun 2007 11:01:34 -0700 Received: from [66.93.68.165] ([66.93.68.165]) by keys.pgpeng.com (PGP Universal service); Tue, 12 Jun 2007 11:01:34 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Tue, 12 Jun 2007 11:01:34 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> <11394.1181607976@marajade.sandelman.ca> Message-Id: <67DF0ADA-24F8-4036-8188-EDD494ACB4FE@pgpeng.com> From: Jon Callas Subject: Re: Types of object for trust anchors Date: Tue, 12 Jun 2007 11:01:59 -0700 To: ietf-trust-anchor@vpnc.org X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > SPKI is not a standards track PKI RFC model, unlike X.509, OpenPGP, > and DNSSEC. Thus it does not necessarily merit equal consideration > here. > Yes, but. RFC 4398 (Certs in DNS) has provisions for SPKI. There's precedent. If you come up with a trust anchor mechanism that can handle X.509, OpenPGP, and DNSSEC (and bare keys a la DKIM -- which I suppose can be considered the null cert), but *cannot* handle SPKI without surgery, then you have a great touchstone for deciding whether to do the surgery. If, on the other hand, the trust anchor structure has a syntax that says, "cert of syntax S goes here," all that's needed is a constant that says, "SPKI" similarly to 4398. And then we can go back to admiring but not using it. Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 3460 West Bayshore Fax: +1 (650) 319-9001 Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From owner-ietf-trust-anchor Tue Jun 12 12:28:37 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CJSbpC047622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 12:28:37 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5CJSb5l047621; Tue, 12 Jun 2007 12:28:37 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5CJSZ9N047595 for ; Tue, 12 Jun 2007 12:28:36 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200706121928.l5CJSZ9N047595@balder-227.proper.com> Received: (qmail 26800 invoked by uid 0); 12 Jun 2007 19:28:29 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.176) by woodstock.binhost.com with SMTP; 12 Jun 2007 19:28:29 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Jun 2007 14:57:13 -0400 To: Paul Hoffman , ietf-trust-anchor@vpnc.org From: Russ Housley Subject: Re: Types of object for trust anchors In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> <11394.1181607976@marajade.sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul: >At 8:26 PM -0400 6/11/07, Michael Richardson wrote: >> Paul> and some would want them as PGP certificates. It makes sense >> Paul> to allow one set of trust anchors being delivered to contain >> Paul> multiple types and let the receiver sort out which types it >> Paul> can use. >> >> That seems more complicated (in code space) than just making everyone >>use BER CMS to me... > >BER CMS of *what*? A bare public key? A cert of a particular format? >What I'm thinking is a requirement for flexibility is not the >housing, but the contents. I suspect this is a reference to a PKCS#7 that contains only as single certificate. This is the format that is used by many CAs in response to a PKCS#10 certificate request. Russ From owner-ietf-trust-anchor Tue Jun 12 12:28:36 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CJSaOb047616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 12:28:36 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5CJSaac047615; Tue, 12 Jun 2007 12:28:36 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5CJSZLQ047597 for ; Tue, 12 Jun 2007 12:28:36 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200706121928.l5CJSZLQ047597@balder-227.proper.com> Received: (qmail 26802 invoked by uid 0); 12 Jun 2007 19:28:29 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.176) by woodstock.binhost.com with SMTP; 12 Jun 2007 19:28:29 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Jun 2007 15:09:33 -0400 To: Jon Callas From: Russ Housley Subject: Re: Types of object for trust anchors Cc: ietf-trust-anchor@vpnc.org In-Reply-To: <737A8762-2ADA-4B1D-A549-65F56FBBDD0B@pgpeng.com> References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> <737A8762-2ADA-4B1D-A549-65F56FBBDD0B@pgpeng.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon: >I would like to see a better description of what you mean by a trust >anchor. I know what you mean, but it took me a couple readings. A >scenario or use case would help a lot. > >Paul Hoffman brings up a very good point as well. In my reading of it >at first I noted that you were only talking about ASN.1 and CMS, and >thus shackled my thinking around X.509 and PKIX. However, I think >that not only should you cover OpenPGP certificates as well, but at >the very least anything you can store in the DNS via RFC 4398, as >well as being able to specify trust anchors for key-centric systems >such as DKIM where the trust anchor *is* DNS and yet there are those >who want more security but not a tacit presumption that DNSSEC will >be both necessary and sufficient. I have not objection to discussion PGP certificates as well as X.509 certificates. This ought to support certification path validation, regardless of the repository mechanism used for the certificates. In RFC 4108, the trust anchor public key can be used to validate the signature on a CMS SignedData object directly. This is an important use case for dealing with digitally signed firmware. I'm not sure that public keys for DKIM makes sense, but maybe I am misunderstanding you. In DKIM, the trust model is centered around an administrator being able to configure the MTA to make use of a particular private key and the DNS to contain the corresponding public key. There is not a need for a trust anchor to validate a certification path. >Lastly, I don't want to get into yet another debate about ASN.1, >particularly since you're using CMS and CMS is one of the few places >where there haven't been horrible security problems using ASN.1, but >these days self-describing data is pretty universally encoded with >XML. Love it or hate it, it seems that everything can parse XML. A >trust anchor syntax that is ASN.1-only would be pretty limited, and >would get us yet another set of ways to buffer-overflow a system by >giving it a bizarrely coded ASN.1 object. I do not buy that rationale. ASN.1 has worked out pretty well for CMS and certificates. Given that the trust anchors will be used in such and environment (and possibly others), I see no reason to run away from ASN.1 for this protocol. >At a minimum, there should both an ASN.1 and an XML syntax if we want >this to be widely used. Alternatively, the trust anchors could be >coded only in XML and that XML structure protected with CMS, or >OpenPGP, or even XML-based protection. If there is no XML syntax, >then at the end of the day we'll have to make one anyway, so why not >just do it up front? I am not opposed to working on both ASN.1 and XML encodings of the same basic protocol. Russ From owner-ietf-trust-anchor Tue Jun 12 15:00:06 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CM06Ud057154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 15:00:06 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5CM06dl057153; Tue, 12 Jun 2007 15:00:06 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CLxxa8057103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Jun 2007 15:00:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> Date: Tue, 12 Jun 2007 14:59:56 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Requirements for the container Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Section 4 of draft-wallace-ta-mgmt-problem-statement-00 specifies that CMS is a requirement. While I hope that CMS is the ultimate choice made by this group, it is not a requirement for the protocol. I propose that this whole section be removed from the requirements document and put into the rationale section of whatever CMS-based protocol spec might be later produced. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jun 12 15:07:20 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CM7JNd057468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 15:07:20 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5CM7JT8057467; Tue, 12 Jun 2007 15:07:19 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5CM7H5V057461 for ; Tue, 12 Jun 2007 15:07:18 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 14214 invoked from network); 12 Jun 2007 22:05:51 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;12 Jun 2007 22:05:51 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 12 Jun 2007 22:05:51 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Tue, 12 Jun 2007 18:07:17 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D0A7E@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: Requirements for the container Date: Tue, 12 Jun 2007 18:07:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AD3E.0982E8C6" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C7AD3E.0982E8C6 Content-Type: text/plain Section 4 does not require CMS. It discusses how CMS could be used to support a TA management protocol. It is a little out of place in this doc and would be better in a protocol spec as you suggest. > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of > Paul Hoffman > Sent: Tuesday, June 12, 2007 6:00 PM > To: ietf-trust-anchor@vpnc.org > Subject: Requirements for the container > > > Section 4 of draft-wallace-ta-mgmt-problem-statement-00 > specifies that CMS is a requirement. While I hope that CMS is > the ultimate choice made by this group, it is not a > requirement for the protocol. > I propose that this whole section be removed from the > requirements document and put into the rationale section of > whatever CMS-based protocol spec might be later produced. > > --Paul Hoffman, Director > --VPN Consortium > ------_=_NextPart_001_01C7AD3E.0982E8C6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Requirements for the container
Section 4 does not require CMS. It discusses = how CMS could be used to support a TA management protocol. It is = a little out of place in this doc and would be better in a protocol = spec as you suggest.

> -----Original Message-----
> From: owner-ietf-trust-anchor@mail.vpnc.org =
> [mailto:owner-ietf-= trust-anchor@mail.vpnc.org] On Behalf Of
> Paul Hoffman
> Sent: Tuesday, June 12, 2007 6:00 PM
> To: ietf-trust-anchor@vpnc.org
> Subject: Requirements for the container
>
>
> Section 4 of = draft-wallace-ta-mgmt-problem-statement-00
> specifies that CMS is a requirement. While I = hope that CMS is
> the ultimate choice made by this group, it is = not a
> requirement for the protocol.
> I propose that this whole section be removed = from the
> requirements document and put into the = rationale section of
> whatever CMS-based protocol spec might be later = produced.
>
> --Paul Hoffman, Director
> --VPN Consortium
>
------_=_NextPart_001_01C7AD3E.0982E8C6-- From owner-ietf-trust-anchor Tue Jun 12 17:18:35 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5D0IZpr066582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 17:18:35 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5D0IZiI066581; Tue, 12 Jun 2007 17:18:35 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5D0IXBt066574 for ; Tue, 12 Jun 2007 17:18:34 -0700 (MST) (envelope-from jon@pgpeng.com) Received: from keys.pgpeng.com (keys.pgpeng.com [127.0.0.1]) by keys.pgpeng.com (PGP Universal) with ESMTP id 90142F0176; Tue, 12 Jun 2007 17:18:33 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Tue, 12 Jun 2007 17:18:33 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Tue, 12 Jun 2007 17:18:33 -0700 Received: from [63.251.255.74] (account jon HELO keys.pgpeng.com) by pgpeng.com (CommuniGate Pro SMTP 4.3.7) with ESMTPSA id 1810364; Tue, 12 Jun 2007 17:18:33 -0700 Received: from [63.251.255.205] ([63.251.255.205]) by keys.pgpeng.com (PGP Universal service); Tue, 12 Jun 2007 17:18:33 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Tue, 12 Jun 2007 17:18:33 -0700 In-Reply-To: <200706121928.l5CJSZLQ047597@balder-227.proper.com> References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> <737A8762-2ADA-4B1D-A549-65F56FBBDD0B@pgpeng.com> <200706121928.l5CJSZLQ047597@balder-227.proper.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: Cc: ietf-trust-anchor@vpnc.org From: Jon Callas Subject: Re: Types of object for trust anchors Date: Tue, 12 Jun 2007 17:18:58 -0700 To: Russ Housley X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 12, 2007, at 12:09 PM, Russ Housley wrote: >> I would like to see a better description of what you mean by a trust >> anchor. I know what you mean, but it took me a couple readings. A >> scenario or use case would help a lot. >> >> Paul Hoffman brings up a very good point as well. In my reading of it >> at first I noted that you were only talking about ASN.1 and CMS, and >> thus shackled my thinking around X.509 and PKIX. However, I think >> that not only should you cover OpenPGP certificates as well, but at >> the very least anything you can store in the DNS via RFC 4398, as >> well as being able to specify trust anchors for key-centric systems >> such as DKIM where the trust anchor *is* DNS and yet there are those >> who want more security but not a tacit presumption that DNSSEC will >> be both necessary and sufficient. > > I have not objection to discussion PGP certificates as well as X. > 509 certificates. This ought to support certification path > validation, regardless of the repository mechanism used for the > certificates. > > In RFC 4108, the trust anchor public key can be used to validate > the signature on a CMS SignedData object directly. This is an > important use case for dealing with digitally signed firmware. > > I'm not sure that public keys for DKIM makes sense, but maybe I am > misunderstanding you. In DKIM, the trust model is centered around > an administrator being able to configure the MTA to make use of a > particular private key and the DNS to contain the corresponding > public key. There is not a need for a trust anchor to validate a > certification path. > It is a feature of DKIM that its basic trust anchor is DNS itself. However, people have asked for cryptographic trust anchors since the beginning of DKIM. I like the portion of this document that notes that trust anchors have traditionally been a manual, out-of-band process. My reply to people who wanted a cryptographic trust anchor in DKIM was to say that since DKIM uses bare keys, you can put that key in a cert request, get your favorite CA to make a cert, and poof, instant trust anchor. Validate said trust anchor with your favorite trust mechanism. If there is now going to a trust anchor protocol, we could consider the older DKIM concern as well. If people have decided in the meantime that there is no real need for DKIM trust anchors, so much the better. Simple is good. >> Lastly, I don't want to get into yet another debate about ASN.1, >> particularly since you're using CMS and CMS is one of the few places >> where there haven't been horrible security problems using ASN.1, but >> these days self-describing data is pretty universally encoded with >> XML. Love it or hate it, it seems that everything can parse XML. A >> trust anchor syntax that is ASN.1-only would be pretty limited, and >> would get us yet another set of ways to buffer-overflow a system by >> giving it a bizarrely coded ASN.1 object. > > I do not buy that rationale. ASN.1 has worked out pretty well for > CMS and certificates. Given that the trust anchors will be used in > such and environment (and possibly others), I see no reason to run > away from ASN.1 for this protocol. > Please accept my apology for starting a comment with, "I don't want to get into another debate" and thus start the debate. I am not suggesting we should get rid of ASN.1. I'm even violating my own rule of not saying "don't code bugs" in a standard. I'm sorry. >> At a minimum, there should both an ASN.1 and an XML syntax if we want >> this to be widely used. Alternatively, the trust anchors could be >> coded only in XML and that XML structure protected with CMS, or >> OpenPGP, or even XML-based protection. If there is no XML syntax, >> then at the end of the day we'll have to make one anyway, so why not >> just do it up front? > > I am not opposed to working on both ASN.1 and XML encodings of the > same basic protocol. Excellent. Thanks. Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 3460 West Bayshore Fax: +1 (650) 319-9001 Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From owner-ietf-trust-anchor Fri Jun 15 10:58:53 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5FHwqD4012905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 10:58:52 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5FHwqc1012904; Fri, 15 Jun 2007 10:58:52 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5FHwpSO012873; Fri, 15 Jun 2007 10:58:51 -0700 (MST) (envelope-from mcr@marajade.sandelman.ca) Received: from sandelman.ottawa.on.ca (unknown [206.191.15.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marajade.sandelman.ca.", Issuer "Michael Richardson" (verified OK)) by cod.sandelman.ca (Postfix) with ESMTP id 073CF1275A; Fri, 15 Jun 2007 13:58:49 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 16DA24E79F; Fri, 15 Jun 2007 13:58:49 -0400 (EDT) From: Michael Richardson To: Stephen Kent cc: Paul Hoffman , ietf-trust-anchor@vpnc.org Subject: Re: Types of object for trust anchors In-Reply-To: Message from Stephen Kent of "Mon, 11 Jun 2007 22:24:27 EDT." References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> <11394.1181607976@marajade.sandelman.ca> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) Date: Fri, 15 Jun 2007 13:58:49 -0400 Message-ID: <12306.1181930329@marajade.sandelman.ca> Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Stephen" == Stephen Kent writes: >> ... I also think that some SPKI stuff needs to br brought up in >> the BOF. Specifically, relating to section 3, paragraph 3. >> Stephen> SPKI is not a standards track PKI RFC model, unlike X.509, Stephen> OpenPGP, and DNSSEC. Thus it does not necessarily merit Stephen> equal consideration here. Nor did I propose it as a standard. I said that it had some relevant discussion about what it means to configure a local trust anchor. - -- ] Bear: "Me, I'm just the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRnLTRICLcPvd0N1lAQIy5Qf+IbVi69nOlDhLouA5xKgy44PzA1l4HCfW roCdxGbPRSIe7sVT+5Tef5IwXjbPV6UEBLH3wWikPO4gkoX+T51WFGnc1wtOngWD JdkXYpDfrGKIWi1vOJjHsjRpLO6Qvx0SeUqE+UoAgFGoeHIHxsr5TTvE8mt1Abg3 Dhvuh6Kc9H53xJYiROzwrg7/42PA10vFCyAwSlutUZztVs/zuySGi8rSLySUzEsu jx5U4mZAv3AeiuN2IQtkaXoKJJByMIkocIcAZivsGXDhhQBwIxClqW1rVl+vUj9o bP8ttmlvaOToK9wSmJwLUjd7OAMXVOjYcTNip9Z9NKizBnKYQ6+04A== =w/ed -----END PGP SIGNATURE----- From owner-ietf-trust-anchor Fri Jun 15 11:34:57 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5FIYvnD024948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 11:34:57 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5FIYvhr024945; Fri, 15 Jun 2007 11:34:57 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5FIYtHB024908; Fri, 15 Jun 2007 11:34:56 -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 1HzGdH-000272-63; Fri, 15 Jun 2007 14:34:52 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <12306.1181930329@marajade.sandelman.ca> References: <886F5D4C78AFB14D87261206BFB9612E1D1D0952@scygmxs1.cygnacom.com> <11394.1181607976@marajade.sandelman.ca> <12306.1181930329@marajade.sandelman.ca> Date: Fri, 15 Jun 2007 14:21:38 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: Types of object for trust anchors Cc: Paul Hoffman , ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:58 PM -0400 6/15/07, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>>>>> "Stephen" == Stephen Kent writes: > >> ... I also think that some SPKI stuff needs to br brought up in > >> the BOF. Specifically, relating to section 3, paragraph 3. > >> > > Stephen> SPKI is not a standards track PKI RFC model, unlike X.509, > Stephen> OpenPGP, and DNSSEC. Thus it does not necessarily merit > Stephen> equal consideration here. > > Nor did I propose it as a standard. > I said that it had some relevant discussion about what it means to >configure a local trust anchor. fair enough. Steve From owner-ietf-trust-anchor Fri Jun 15 13:38:48 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5FKcmjd059190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 13:38:48 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5FKcm3a059189; Fri, 15 Jun 2007 13:38:48 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5FKckdo059181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Jun 2007 13:38:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 15 Jun 2007 13:38:38 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Meeting in Chicago Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: According to , there will be a BoF on the subject of this mailing list. For those of you making travel plans, we are currently scheduled Friday morning. IETF schedules change a great deal until about two weeks before the meeting, but anyone who wants to be at this BoF should probably not plan on leaving until Friday noon. Given that we are scheduled in the Grand Ballroom, maybe they're expecting a big crowd. :-) --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Jun 15 14:06:39 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5FL6d2Z066726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 14:06:39 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5FL6dda066725; Fri, 15 Jun 2007 14:06:39 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from vacation.karoshi.com. (vacation.karoshi.com [198.32.6.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5FL6b8t066702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 14:06:38 -0700 (MST) (envelope-from bmanning@karoshi.com) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com. (8.12.8/8.12.8) with ESMTP id l5FL6bnC026066; Fri, 15 Jun 2007 21:06:37 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id l5FL6bHW026065; Fri, 15 Jun 2007 21:06:37 GMT Date: Fri, 15 Jun 2007 21:06:37 +0000 From: bmanning@karoshi.com To: Paul Hoffman Cc: ietf-trust-anchor@vpnc.org Subject: Re: Meeting in Chicago Message-ID: <20070615210637.GA25975@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jun 15, 2007 at 01:38:38PM -0700, Paul Hoffman wrote: > > According to > , > there will be a BoF on the subject of this mailing list. For those of you a BOF on Meeting in Chicago? > making travel plans, we are currently scheduled Friday morning. IETF > schedules change a great deal until about two weeks before the meeting, but > anyone who wants to be at this BoF should probably not plan on leaving > until Friday noon. > > Given that we are scheduled in the Grand Ballroom, maybe they're > expecting a big crowd. :-) > > --Paul Hoffman, Director > --VPN Consortium From owner-ietf-trust-anchor Fri Jun 15 14:54:23 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5FLsNJ2079740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 14:54:23 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5FLsNBn079738; Fri, 15 Jun 2007 14:54:23 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5FLsJTB079721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 14:54:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20070615210637.GA25975@vacation.karoshi.com.> References: <20070615210637.GA25975@vacation.karoshi.com.> Date: Fri, 15 Jun 2007 14:54:11 -0700 To: bmanning@karoshi.com From: Paul Hoffman Subject: Re: Meeting in Chicago Cc: ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:06 PM +0000 6/15/07, bmanning@karoshi.com wrote: >On Fri, Jun 15, 2007 at 01:38:38PM -0700, Paul Hoffman wrote: >> >> According to >> >>, >> there will be a BoF on the subject of this mailing list. For those of you > > a BOF on Meeting in Chicago? It sure looks that way. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jun 19 13:07:56 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JK7uPu071917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 13:07:56 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JK7uxZ071916; Tue, 19 Jun 2007 13:07:56 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JK7qBL071901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 13:07:55 -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 l5JK7WMb030184; Tue, 19 Jun 2007 16:07:32 -0400 In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Paul Hoffman , Stephen Farrell , Sean Turner Content-Transfer-Encoding: 7bit From: Tim Polk Subject: Re: Meeting in Chicago Date: Tue, 19 Jun 2007 16:07:31 -0400 To: ietf-trust-anchor@vpnc.org 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-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As Paul astutely observed, a request for a BOF on trust anchor management has been approved for the Chicago IETF meeting. I am very pleased to announce Stephen Farrell and Sean Turner have agreed to lead the BOF. Most of you will know Stephen and Sean from their respective positions co-chairing dkim and smime, and their contributions to other IETF WGs. Thanks guys! Given the limited discussions on this topic to date, the BOF will be focused on whether a constituency exists within the IETF to support future work on trust anchor management. If you look at the goals specified in the introduction of draft-narten-successful-bof-02.txt, we will be concentrating on the first two: > demonstrate that the community has agreement that: > > - there is a problem that needs solving, and the IETF is the right > group to attempt solving it. > > - there is a critical mass of participants willing to work on the > problem (e.g., write drafts, review drafts, etc.) I would also like to make progress on the third goal: > demonstrate that the community has agreement that: > > - the scope of the problem is well defined and understood, that is, > people generally understand what the WG will work on (and what > not) and what its actual deliverables will be > Asa result, I would expect this session to focus on the problem statement. If we can demonstrate a constituency for this work, the usual charter bashing can happen at a future date. As Paul also noted, the BOF is currently scheduled for Friday morning. I am still hoping for an earlier slot, but I hope you will all plan on a late afternoon Friday getaway just in case! Thanks, Tim Polk From owner-ietf-trust-anchor Tue Jun 19 13:17:37 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKHbjS073334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 13:17:37 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JKHbON073333; Tue, 19 Jun 2007 13:17:37 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKHa5r073321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jun 2007 13:17:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> Date: Tue, 19 Jun 2007 13:16:14 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Re: Meeting in Chicago Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 4:07 PM -0400 6/19/07, Tim Polk wrote: >As Paul also noted, the BOF is currently scheduled for Friday >morning. I am still hoping for an earlier slot, but I hope you will >all plan on a late afternoon Friday getaway just in case! I think there is an advantage for Friday morning, namely that it comes after the SAAG meeting on Thursday. Given that we don't have a good way to publicize BoFs, having this one after SAAG may give us a chance to pick up more people interested in the topic. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jun 19 13:43:07 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKh7cb075707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 13:43:07 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JKh75u075706; Tue, 19 Jun 2007 13:43:07 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKh5wX075698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jun 2007 13:43:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> Date: Tue, 19 Jun 2007 13:42:29 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Does the problem need solving? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 4:07 PM -0400 6/19/07, Tim Polk wrote: >If you look at the goals specified in the introduction of >draft-narten-successful-bof-02.txt, we will be concentrating on the >first two: >>demonstrate that the community has agreement that: >> >> - there is a problem that needs solving, and the IETF is the right >> group to attempt solving it. >> >> - there is a critical mass of participants willing to work on the >> problem (e.g., write drafts, review drafts, etc.) Even though we have gone well over a decade without an interoperable solution, I think we got here mostly through applied denial and kludges. One result of that has been that organizational users of PKI are stuck with having to live with the trust decisions made by their OS vendors, their applications vendors, or both. Another is that people have been trained to click through the "this cert is not signed by a trusted root" dialog because it is too hard for an enterprise to push their desired trust anchors to their employees. I would argue in favor that the problem needs solving. I hope that there is also a critical mass of people who care enough about the future of the PKI user experience to do the work. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jun 19 13:59:15 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKxFVX077300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 13:59:15 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JKxFV3077299; Tue, 19 Jun 2007 13:59:15 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JKxESV077286; Tue, 19 Jun 2007 13:59:14 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.100]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I0kn9-0005Ha-5r; Tue, 19 Jun 2007 16:59:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> Date: Tue, 19 Jun 2007 16:59:10 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: Does the problem need solving? Cc: ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with Paul that there is a problem to be solved. We need to iterate on the description of the problem, relative to the statement that has been posted, which IO think is too narrow, but certainly fixable. Then we need to see if we can achieve agreement on the scope of the problem to be solved, as we try to improve the problem statement. Steve From owner-ietf-trust-anchor Wed Jun 20 12:35:40 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KJZeYH048673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 12:35:40 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KJZeZ6048672; Wed, 20 Jun 2007 12:35:40 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from relay.imagine.ie (dns2.dns.imagine.ie [87.232.1.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KJZbMJ048648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Jun 2007 12:35:39 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id 86701413B; Wed, 20 Jun 2007 20:35:36 +0100 (IST) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id l5KJZWlX022695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2007 20:35:32 +0100 Message-ID: <467981EE.2050400@cs.tcd.ie> Date: Wed, 20 Jun 2007 20:37:18 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephen Kent CC: Paul Hoffman , ietf-trust-anchor@vpnc.org Subject: Re: Does the problem need solving? References: <20070615210637.GA25975@vacation.karoshi.com.> In-Reply-To: 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: 10442443 - 7b25ad0550da X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Steve, Stephen Kent wrote: > > I agree with Paul that there is a problem to be solved. We need to > iterate on the description of the problem, relative to the statement > that has been posted, which IO think is too narrow, but certainly > fixable. Do you have any suggestions now for extending the problem statement? Be good to get those talked about as soon as we can. > Then we need to see if we can achieve agreement on the scope of > the problem to be solved, as we try to improve the problem statement. That's probably right, though there may be one or two scoping issues (e.g. is this for enterprises only or also e.g. of interest also for those who do Internet banking?) that might need to be discussed along with the problem statement. Cheers, Stephen. From owner-ietf-trust-anchor Thu Jun 21 10:09:07 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LH97JW068407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 10:09:07 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LH97Cx068406; Thu, 21 Jun 2007 10:09:07 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LH95Ek068390 for ; Thu, 21 Jun 2007 10:09:06 -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 1I1Q9V-0000mr-6Q; Thu, 21 Jun 2007 13:09:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <467981EE.2050400@cs.tcd.ie> References: <20070615210637.GA25975@vacation.karoshi.com.> <467981EE.2050400@cs.tcd.ie> Date: Thu, 21 Jun 2007 13:08:57 -0400 To: Stephen Farrell From: Stephen Kent Subject: Re: Does the problem need solving? Cc: ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:37 PM +0100 6/20/07, Stephen Farrell wrote: >Hi Steve, > >Stephen Kent wrote: >> >>I agree with Paul that there is a problem to be solved. We need to >>iterate on the description of the problem, relative to the >>statement that has been posted, which IO think is too narrow, but >>certainly fixable. > >Do you have any suggestions now for extending the problem >statement? Be good to get those talked about as soon as we can. One suggestion is that we view the problem not as managing TAs for a box, but more generally for applications, recognizing that different apps may need different sets of TAs. If a box has just one app, then this seems like a roughly equivalent formulation of the problem. This would help avoid the language such as "Once installed, a trust anchor represents an entity with authority over a device." which seems too narrow. > > Then we need to see if we can achieve agreement on the scope of >>the problem to be solved, as we try to improve the problem statement. > >That's probably right, though there may be one or two scoping >issues (e.g. is this for enterprises only or also e.g. of >interest also for those who do Internet banking?) that might >need to be discussed along with the problem statement. I was thinking more about the issue of whether we are defining a solution that is agnostic re syntactic details of the PKI context in which it operates, or not. Thus whether we will deal only with certs of one type, certs of several types, public keys without a cert context, ... From owner-ietf-trust-anchor Thu Jun 21 10:43:46 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LHhkit072048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 10:43:46 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LHhk1p072047; Thu, 21 Jun 2007 10:43:46 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LHhfwV072040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 Jun 2007 10:43:45 -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 0C3D2320B4; Thu, 21 Jun 2007 18:43:41 +0100 (IST) Received: from [10.87.48.2] (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 l5LHhXse005154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jun 2007 18:43:36 +0100 Message-ID: <467AB92F.1060408@cs.tcd.ie> Date: Thu, 21 Jun 2007 18:45:19 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephen Kent CC: ietf-trust-anchor@vpnc.org Subject: Re: Does the problem need solving? References: <20070615210637.GA25975@vacation.karoshi.com.> <467981EE.2050400@cs.tcd.ie> In-Reply-To: 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: 10528710 - a1cb56bf61f7 (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen Kent wrote: > At 8:37 PM +0100 6/20/07, Stephen Farrell wrote: >> Hi Steve, >> >> Stephen Kent wrote: >>> >>> I agree with Paul that there is a problem to be solved. We need to >>> iterate on the description of the problem, relative to the statement >>> that has been posted, which IO think is too narrow, but certainly >>> fixable. >> >> Do you have any suggestions now for extending the problem >> statement? Be good to get those talked about as soon as we can. > > One suggestion is that we view the problem not as managing TAs for a > box, but more generally for applications, recognizing that different > apps may need different sets of TAs. If a box has just one app, then > this seems like a roughly equivalent formulation of the problem. This > would help avoid the language such as "Once installed, a trust anchor > represents an entity with authority over a device." which seems too narrow. Seems like a fair point. >> > Then we need to see if we can achieve agreement on the scope of >>> the problem to be solved, as we try to improve the problem statement. >> >> That's probably right, though there may be one or two scoping >> issues (e.g. is this for enterprises only or also e.g. of >> interest also for those who do Internet banking?) that might >> need to be discussed along with the problem statement. > > I was thinking more about the issue of whether we are defining a > solution that is agnostic re syntactic details of the PKI context in > which it operates, or not. Thus whether we will deal only with certs of > one type, certs of several types, public keys without a cert context, ... > Sure, that level of scoping can be for later. S. From owner-ietf-trust-anchor Thu Jun 21 10:45:40 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LHjetV072181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 10:45:40 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LHjeiP072179; Thu, 21 Jun 2007 10:45:40 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LHjbvT072166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Jun 2007 10:45:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> <467981EE.2050400@cs.tcd.ie> Date: Thu, 21 Jun 2007 10:33:23 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Trust anchors for multiple applications Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:08 PM -0400 6/21/07, Stephen Kent wrote: >One suggestion is that we view the problem not as managing TAs for a >box, but more generally for applications, recognizing that different >apps may need different sets of TAs. If a box has just one app, then >this seems like a roughly equivalent formulation of the problem. >This would help avoid the language such as "Once installed, a trust >anchor represents an entity with authority over a device." which >seems too narrow. Fully agree. A real-world example of this is installing the Firefox browser on a Windows system. The Firefox browser has its own set of trust anchors, separate from the ones for Windows. A more hypothetical example, but one that is valuable in the corporate marketplace, is a set of trust anchors for a corporate-developed application. That application might start off with just one trust anchor, from the developer, but could expand to others as partners outside the corporation are added. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 21 10:45:40 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LHjeDT072182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 10:45:40 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LHje8j072180; Thu, 21 Jun 2007 10:45:40 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LHjbvV072166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Jun 2007 10:45:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 21 Jun 2007 10:45:24 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Distribution of trust anchor policy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Another requirement that I see only touched on a bit in the first draft is that of policy. As the trust anchor administrator, I might want to distribute a trust anchor but to require that it only be used for trusting certificates whose domain names are in example.com. The trust anchor itself might not have the name constraint in it, but the constraint is what I, as administrator, am telling my users to trust it for. Thus, I need to be able to express some kind of policy with a trust anchor. Yes, I know, I used the P-word and therefore created a can of worms rolling down a slippery slope towards a rat hole. Nonetheless, it is a real-world need that is not currently met except by distributing a trust anchor signed by me and a non-anchor that I sign with policy constraints in that non-anchor. The latter forces relying parties to be able to do chaining following the quite-complex PKIX chaining rules; the former does not. I would rather see this group embrace policy distribution with the trust anchors than to force the policy into the trust anchors themselves simply because the policy should be being made by the administrator, not the authorities who create the trust anchors. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 21 10:54:44 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LHsiYi074183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 10:54:44 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LHsiB4074182; Thu, 21 Jun 2007 10:54:44 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5LHsdSl074133 for ; Thu, 21 Jun 2007 10:54:43 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 17528 invoked from network); 21 Jun 2007 17:52:59 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Jun 2007 17:52:59 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 21 Jun 2007 17:52:59 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Jun 2007 13:54:37 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D0CE0@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: Trust anchors for multiple applications Date: Thu, 21 Jun 2007 13:54:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B42D.37A39818" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C7B42D.37A39818 Content-Type: text/plain > At 1:08 PM -0400 6/21/07, Stephen Kent wrote: > >One suggestion is that we view the problem not as managing TAs for a > >box, but more generally for applications, recognizing that different > >apps may need different sets of TAs. If a box has just one app, then > >this seems like a roughly equivalent formulation of the problem. > >This would help avoid the language such as "Once installed, a trust > >anchor represents an entity with authority over a device." > which seems > >too narrow. > > Fully agree. A real-world example of this is installing the > Firefox browser on a Windows system. The Firefox browser has > its own set of trust anchors, separate from the ones for Windows. > > A more hypothetical example, but one that is valuable in the > corporate marketplace, is a set of trust anchors for a > corporate-developed application. That application might start > off with just one trust anchor, from the developer, but could > expand to others as partners outside the corporation are added. I agree the "authority over a device" language needs improvement. The draft does call out that multiple trust stores may reside on a particular machine and may be application specific. ------_=_NextPart_001_01C7B42D.37A39818 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Trust anchors for multiple applications
> At 1:08 PM -0400 6/21/07, Stephen Kent = wrote:
> >One suggestion is that we view the problem = not as managing TAs for a
> >box, but more generally for applications, = recognizing that different
> >apps may need different sets of TAs. If a = box has just one app, then
> >this seems like a roughly equivalent = formulation of the problem.
> >This would help avoid the language such as = "Once installed, a trust
> >anchor represents an entity with authority = over a device."
> which seems
> >too narrow.
>
> Fully agree. A real-world example of this is = installing the
> Firefox browser on a Windows system. The = Firefox browser has
> its own set of trust anchors, separate from the = ones for Windows.
>
> A more hypothetical example, but one that is = valuable in the
> corporate marketplace, is a set of trust = anchors for a
> corporate-developed application. That = application might start
> off with just one trust anchor, from the = developer, but could
> expand to others as partners outside the = corporation are added.

I agree the "authority over a device" = language needs improvement. The draft does call out that multiple = trust stores may reside on a particular machine and may be application = specific.
------_=_NextPart_001_01C7B42D.37A39818-- From owner-ietf-trust-anchor Thu Jun 21 11:10:52 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LIAp8I078301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 11:10:51 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LIAp3S078300; Thu, 21 Jun 2007 11:10:51 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LIAn66078278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jun 2007 11:10:50 -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 B5780320B8; Thu, 21 Jun 2007 19:10:48 +0100 (IST) Received: from [10.87.48.2] (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 l5LIAljm009074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jun 2007 19:10:47 +0100 Message-ID: <467ABF90.5040500@cs.tcd.ie> Date: Thu, 21 Jun 2007 19:12:32 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Paul Hoffman CC: ietf-trust-anchor@vpnc.org Subject: Re: Distribution of trust anchor policy References: In-Reply-To: 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: 10530389 - 5761b52b3774 X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Hoffman wrote: > I would rather see this group embrace policy distribution with the trust > anchors than to force the policy into the trust anchors themselves > simply because the policy should be being made by the administrator, not > the authorities who create the trust anchors. I'm a bit confused by that, there seem to be two separable issues:- 1. Some of the more exotic PKIX policy stuff may not be implemented everywhere. 2. You want the admin for this (putative) protocol to control these settings and not a subbordinate CA. I don't see how 1=>2 which is what I thought you were saying above, S. From owner-ietf-trust-anchor Thu Jun 21 11:26:06 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LIQ6US082599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 11:26:06 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LIQ6vn082598; Thu, 21 Jun 2007 11:26:06 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5LIQ3Hf082580 for ; Thu, 21 Jun 2007 11:26:04 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: (qmail 2847 invoked from network); 21 Jun 2007 18:25:56 -0000 Received: from sharon.boeyen@entrust.com by sottccs1.entrust.com with EntrustECS-Server-8.0;21 Jun 2007 18:25:56 -0000 Received: from unknown (HELO sottexch1.corp.ad.entrust.com) (10.4.51.28) by sottccs1.entrust.com with SMTP; 21 Jun 2007 18:25:56 -0000 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" Subject: RE: Distribution of trust anchor policy Date: Thu, 21 Jun 2007 14:25:59 -0400 Message-ID: <04398A2C9F306C4690265C144089972D01BE7580@sottexch1.corp.ad.entrust.com> In-Reply-To: <467ABF90.5040500@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Distribution of trust anchor policy Thread-Index: Ace0MGjq7cMPJbH6Q22PVY1DwEoQWAAAR0Pw References: <467ABF90.5040500@cs.tcd.ie> From: "Sharon Boeyen" To: "Stephen Farrell" , "Paul Hoffman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5LIQ5Hf082591 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I also think we need to be cautious and keep this focused on actual trust anchors (as opposed to an alternative to cross-certification). -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen Farrell Sent: Thursday, June 21, 2007 2:13 PM To: Paul Hoffman Cc: ietf-trust-anchor@vpnc.org Subject: Re: Distribution of trust anchor policy Paul Hoffman wrote: > I would rather see this group embrace policy distribution with the > trust anchors than to force the policy into the trust anchors > themselves simply because the policy should be being made by the > administrator, not the authorities who create the trust anchors. I'm a bit confused by that, there seem to be two separable issues:- 1. Some of the more exotic PKIX policy stuff may not be implemented everywhere. 2. You want the admin for this (putative) protocol to control these settings and not a subbordinate CA. I don't see how 1=>2 which is what I thought you were saying above, S. From owner-ietf-trust-anchor Thu Jun 21 11:40:12 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LIeCtU086112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 11:40:12 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LIeC1I086111; Thu, 21 Jun 2007 11:40:12 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LIeBns086098; Thu, 21 Jun 2007 11:40:12 -0700 (MST) (envelope-from chokhani@orionsec.com) 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" Subject: RE: Distribution of trust anchor policy Date: Thu, 21 Jun 2007 11:40:02 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879082B334A@EXVS01.ex.dslextreme.net> In-Reply-To: <467ABF90.5040500@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Distribution of trust anchor policy thread-index: Ace0MOykfAvcAgfMRJ2xlboZJjDHvQAAoZtQ References: <467ABF90.5040500@cs.tcd.ie> From: "Santosh Chokhani" To: "Stephen Farrell" , "Paul Hoffman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5LIeCns086099 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Constraints such as certificate policies, name constraints, policy constraints, should be available to apply to trust anchor so that a TA is not all or nothing proposition. -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen Farrell Sent: Thursday, June 21, 2007 2:13 PM To: Paul Hoffman Cc: ietf-trust-anchor@vpnc.org Subject: Re: Distribution of trust anchor policy Paul Hoffman wrote: > I would rather see this group embrace policy distribution with the trust > anchors than to force the policy into the trust anchors themselves > simply because the policy should be being made by the administrator, not > the authorities who create the trust anchors. I'm a bit confused by that, there seem to be two separable issues:- 1. Some of the more exotic PKIX policy stuff may not be implemented everywhere. 2. You want the admin for this (putative) protocol to control these settings and not a subbordinate CA. I don't see how 1=>2 which is what I thought you were saying above, S. From owner-ietf-trust-anchor Thu Jun 21 12:08:57 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJ8uGC092362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 12:08:57 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LJ8udh092360; Thu, 21 Jun 2007 12:08:56 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (adsl-66-125-125-71.dsl.pltn13.pacbell.net [66.125.125.71]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJ8j6h092308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 12:08:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <467ABF90.5040500@cs.tcd.ie> <04398A2C9F306C4690265C144089972D01BE7580@sottexch1.corp.ad.entrust.com> <82D5657AE1F54347A734BDD33637C879082B334A@EXVS01.ex.dslextreme.net> References: <467ABF90.5040500@cs.tcd.ie> <467ABF90.5040500@cs.tcd.ie> <04398A2C9F306C4690265C144089972D01BE7580@sottexch1.corp.ad.entrust.com> <467ABF90.5040500@cs.tcd.ie> <82D5657AE1F54347A734BDD33637C879082B334A@EXVS01.ex.dslextreme.net> Date: Thu, 21 Jun 2007 12:08:32 -0700 To: Stephen Farrell , "Sharon Boeyen" , "Santosh Chokhani" From: Paul Hoffman Subject: Re: Distribution of trust anchor policy Cc: ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:12 PM +0100 6/21/07, Stephen Farrell wrote: >Paul Hoffman wrote: >>I would rather see this group embrace policy distribution with the >>trust anchors than to force the policy into the trust anchors >>themselves simply because the policy should be being made by the >>administrator, not the authorities who create the trust anchors. > >I'm a bit confused by that, there seem to be two separable >issues:- > >1. Some of the more exotic PKIX policy stuff may not be implemented >everywhere. > >2. You want the admin for this (putative) protocol to control >these settings and not a subbordinate CA. > >I don't see how 1=>2 which is what I thought you were saying >above, Sorry, I meant to say that both #1 and #2 are true, separately. Even if the users have all the PKIX policy stuff implemented, the trust admin should still be able to specify it himself/herself without having to issue additional certs. At 2:25 PM -0400 6/21/07, Sharon Boeyen wrote: >I also think we need to be cautious and keep this focused on actual >trust anchors (as opposed to an alternative to cross-certification). The policy I used in the example (which trust anchor is allowed to vouch for which identities) is not related to cross-certification. In current PKIX terms, a trust anchor is allowed to vouch for any identities whatsoever. At 11:40 AM -0700 6/21/07, Santosh Chokhani wrote: >Constraints such as certificate policies, name constraints, policy >constraints, should be available to apply to trust anchor so that a TA >is not all or nothing proposition. Exactly. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 21 12:15:40 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJFe0Y094071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 12:15:40 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LJFeMD094070; Thu, 21 Jun 2007 12:15:40 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from ca-server2.wavx.wavesys.com (ca-server2.wavx.wavesys.com [65.197.200.86] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJFcJP094030; Thu, 21 Jun 2007 12:15:39 -0700 (MST) (envelope-from thardjono@wavesys.com) 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" Subject: RE: Trust anchors for multiple applications Date: Thu, 21 Jun 2007 12:15:53 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trust anchors for multiple applications Thread-Index: Ace0LQANIllyCjb+QSuPEbfoISof2wACbruA From: "Thomas Hardjono" To: "Paul Hoffman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5LJFdJP094044 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hmmm, in reading the draft -00, I was under the impression that trust anchors (defined as an "explicitly trusted public key") were chosen and owned by the IT admin of an Enterprise (who also owns all the devices within the Enterprise). I would think that if the Enterprise has authorized a number of applications to be present at and run on devices (e.g. laptops, desktops) within the Enterprise, these applications would implicitly accept the TA (or multiple TAs) that were chosen and installed by the IT Admin. So, really the IT Admin defines the TAs first (ie. trusted public keys), and the applications follow (ie. they simply accept the TAs that have chosen and can be found on the devices). I guess the IT Admin could do a mix-and-match between multiple applications and multiple TAs but that function is lower priority for this WG. I think we need to differentiate between (a) the management of TAs within 1 organization (domain) and (b) the sharing of TAs across organizational boundaries. Maybe for this BOF/WG the priority should be (a) first and then (b). /thomas/ -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul Hoffman Sent: Thursday, June 21, 2007 10:33 AM To: ietf-trust-anchor@vpnc.org Subject: Trust anchors for multiple applications At 1:08 PM -0400 6/21/07, Stephen Kent wrote: >One suggestion is that we view the problem not as managing TAs for a >box, but more generally for applications, recognizing that different >apps may need different sets of TAs. If a box has just one app, then >this seems like a roughly equivalent formulation of the problem. >This would help avoid the language such as "Once installed, a trust >anchor represents an entity with authority over a device." which seems >too narrow. Fully agree. A real-world example of this is installing the Firefox browser on a Windows system. The Firefox browser has its own set of trust anchors, separate from the ones for Windows. A more hypothetical example, but one that is valuable in the corporate marketplace, is a set of trust anchors for a corporate-developed application. That application might start off with just one trust anchor, from the developer, but could expand to others as partners outside the corporation are added. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 21 12:37:07 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJb7W5099983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 12:37:07 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LJb7n2099982; Thu, 21 Jun 2007 12:37:07 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from ca-server2.wavx.wavesys.com (ca-server2.wavx.wavesys.com [65.197.200.86] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJb50S099969 for ; Thu, 21 Jun 2007 12:37:06 -0700 (MST) (envelope-from thardjono@wavesys.com) 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" Subject: RE: Distribution of trust anchor policy Date: Thu, 21 Jun 2007 12:37:20 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Distribution of trust anchor policy Thread-Index: Ace0OGUl7lZOAqvNSGSOnSSMmsV4GwAAWCpg From: "Thomas Hardjono" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5LJb60S099976 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: OK, so my (limited) understanding of Trust Anchors (TA) is that they represent an *authority* over the entity (device) at which the TA has been installed. This means that TA Management (which is what the draft-00 covers) is really "authority management". Which is whi the draft talks about stuff like "authority over devices etc." I think this is distinct from *policy management*, which in this context I take to be the management of the rules governing the usage of a TA (e.g. which applications must accept a TA, when Tas need to be replaced, conditions for deleting TAs, etc). So, it makes sense not to bloat a TA with various policy-related information. A TA should have an identifier that policy-management tools and policy-engines refer to. /thomas/ -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul Hoffman Sent: Thursday, June 21, 2007 12:09 PM To: Stephen Farrell; Sharon Boeyen; Santosh Chokhani Cc: ietf-trust-anchor@vpnc.org Subject: Re: Distribution of trust anchor policy At 7:12 PM +0100 6/21/07, Stephen Farrell wrote: >Paul Hoffman wrote: >>I would rather see this group embrace policy distribution with the >>trust anchors than to force the policy into the trust anchors >>themselves simply because the policy should be being made by the >>administrator, not the authorities who create the trust anchors. > >I'm a bit confused by that, there seem to be two separable >issues:- > >1. Some of the more exotic PKIX policy stuff may not be implemented >everywhere. > >2. You want the admin for this (putative) protocol to control these >settings and not a subbordinate CA. > >I don't see how 1=>2 which is what I thought you were saying above, Sorry, I meant to say that both #1 and #2 are true, separately. Even if the users have all the PKIX policy stuff implemented, the trust admin should still be able to specify it himself/herself without having to issue additional certs. At 2:25 PM -0400 6/21/07, Sharon Boeyen wrote: >I also think we need to be cautious and keep this focused on actual >trust anchors (as opposed to an alternative to cross-certification). The policy I used in the example (which trust anchor is allowed to vouch for which identities) is not related to cross-certification. In current PKIX terms, a trust anchor is allowed to vouch for any identities whatsoever. At 11:40 AM -0700 6/21/07, Santosh Chokhani wrote: >Constraints such as certificate policies, name constraints, policy >constraints, should be available to apply to trust anchor so that a TA >is not all or nothing proposition. Exactly. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 21 12:42:31 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJgVVx001336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 12:42:31 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LJgVh0001335; Thu, 21 Jun 2007 12:42:31 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJgUwk001322; Thu, 21 Jun 2007 12:42:30 -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 1I1SY1-0002gA-5A; Thu, 21 Jun 2007 15:42:29 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 21 Jun 2007 15:42:27 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: Distribution of trust anchor policy Cc: ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:45 AM -0700 6/21/07, Paul Hoffman wrote: >Another requirement that I see only touched on a bit in the first >draft is that of policy. As the trust anchor administrator, I might >want to distribute a trust anchor but to require that it only be >used for trusting certificates whose domain names are in >example.com. The trust anchor itself might not have the name >constraint in it, but the constraint is what I, as administrator, am >telling my users to trust it for. Thus, I need to be able to express >some kind of policy with a trust anchor. I agree with your example and it has long been a source of frustration for me that name constraints (and some other cert path validation constraints) are not inherited from a TA, as per X.509! Of course that can be addressed by adding a cert under the TA with the desired constraints, so long as one can ensure that paths terminating at the TA pass through the inferior cert ... >Yes, I know, I used the P-word and therefore created a can of worms >rolling down a slippery slope towards a rat hole. block that mixed metaphor! >Nonetheless, it is a real-world need that is not currently met >except by distributing a trust anchor signed by me and a non-anchor >that I sign with policy constraints in that non-anchor. The latter >forces relying parties to be able to do chaining following the >quite-complex PKIX chaining rules; the former does not. right. >I would rather see this group embrace policy distribution with the >trust anchors than to force the policy into the trust anchors >themselves simply because the policy should be being made by the >administrator, not the authorities who create the trust anchors. We did that in RFC 3779, i.e., the PKIX-defined extensions for address space and AS numbers state that these constraints apply starting at a TA! The problem is conflicting with the X.509 path validation rules for the standard extensions, vs. private extensions. Also, let's not confuse the common practice of using self-signed certs as a TA data representation with the technical definition (at least ion the X.509 context), where a TA defined as a public key and associated parameters. the latter definition allows an admin who distributes TAs to make the parameters whatever they want, irrespective of the entity represented by the public key. Steve From owner-ietf-trust-anchor Thu Jun 21 12:59:32 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJxW1O005170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 12:59:32 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LJxWjo005169; Thu, 21 Jun 2007 12:59:32 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5LJxT4n005155 for ; Thu, 21 Jun 2007 12:59:30 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: (qmail 12462 invoked from network); 21 Jun 2007 19:59:25 -0000 Received: from sharon.boeyen@entrust.com by sottccs1.entrust.com with EntrustECS-Server-8.0;21 Jun 2007 19:59:25 -0000 Received: from sottexch1.corp.ad.entrust.com (10.4.51.28) by sottccs1.entrust.com with SMTP; 21 Jun 2007 19:59:25 -0000 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" Subject: RE: Distribution of trust anchor policy Date: Thu, 21 Jun 2007 15:59:28 -0400 Message-ID: <04398A2C9F306C4690265C144089972D01BE7588@sottexch1.corp.ad.entrust.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Distribution of trust anchor policy Thread-Index: Ace0PHAHGDO9oVAUQKSx+tXqWhOdxAAAbdWA References: From: "Sharon Boeyen" To: "Stephen Kent" , "Paul Hoffman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5LJxV4n005160 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree that the policy "stuff" should be separate. I think of that as really "packaging" of the path validation variables initial values. I think that everything that has been mentioned so far in terms of "policy" is covered by those variables, now that the recent edition of X.509 added one for the initial subtrees for name constraints (acceptable and prohibited). In some environments it may be very appropriate to have those values differ from one application to another even though the applications may use the same trust anchor(s). For example a high assurance app might require initial policy "high assurance" while another app may accept both "medium" and "high" assurance policies. -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen Kent Sent: Thursday, June 21, 2007 3:42 PM To: Paul Hoffman Cc: ietf-trust-anchor@vpnc.org Subject: Re: Distribution of trust anchor policy At 10:45 AM -0700 6/21/07, Paul Hoffman wrote: >Another requirement that I see only touched on a bit in the first draft >is that of policy. As the trust anchor administrator, I might want to >distribute a trust anchor but to require that it only be used for >trusting certificates whose domain names are in example.com. The trust >anchor itself might not have the name constraint in it, but the >constraint is what I, as administrator, am telling my users to trust it >for. Thus, I need to be able to express some kind of policy with a >trust anchor. I agree with your example and it has long been a source of frustration for me that name constraints (and some other cert path validation constraints) are not inherited from a TA, as per X.509! Of course that can be addressed by adding a cert under the TA with the desired constraints, so long as one can ensure that paths terminating at the TA pass through the inferior cert ... >Yes, I know, I used the P-word and therefore created a can of worms >rolling down a slippery slope towards a rat hole. block that mixed metaphor! >Nonetheless, it is a real-world need that is not currently met except >by distributing a trust anchor signed by me and a non-anchor that I >sign with policy constraints in that non-anchor. The latter forces >relying parties to be able to do chaining following the quite-complex >PKIX chaining rules; the former does not. right. >I would rather see this group embrace policy distribution with the >trust anchors than to force the policy into the trust anchors >themselves simply because the policy should be being made by the >administrator, not the authorities who create the trust anchors. We did that in RFC 3779, i.e., the PKIX-defined extensions for address space and AS numbers state that these constraints apply starting at a TA! The problem is conflicting with the X.509 path validation rules for the standard extensions, vs. private extensions. Also, let's not confuse the common practice of using self-signed certs as a TA data representation with the technical definition (at least ion the X.509 context), where a TA defined as a public key and associated parameters. the latter definition allows an admin who distributes TAs to make the parameters whatever they want, irrespective of the entity represented by the public key. Steve From owner-ietf-trust-anchor Thu Jun 21 13:12:44 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LKCiFo008582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 13:12:44 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LKCiiV008581; Thu, 21 Jun 2007 13:12:44 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LKCg0i008573 for ; Thu, 21 Jun 2007 13:12:43 -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 1I1T1G-00032K-4M; Thu, 21 Jun 2007 16:12:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 21 Jun 2007 16:12:41 -0400 To: "Thomas Hardjono" From: Stephen Kent Subject: RE: Distribution of trust anchor policy Cc: Content-Type: multipart/alternative; boundary="============_-1029665730==_ma============" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --============_-1029665730==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 12:37 PM -0700 6/21/07, Thomas Hardjono wrote: >OK, so my (limited) understanding of Trust Anchors (TA) is that they >represent an *authority* over the entity (device) at which the TA has >been installed. This means that TA Management (which is what the >draft-00 covers) is really "authority management". Which is whi the >draft talks about stuff like "authority over devices etc." I would not adopt that working definition, despite its presence in the -00 draft. I think Carl has agreed that this is not the best way to characterize the problem. >I think this is distinct from *policy management*, which in this context >I take to be the management of the rules governing the usage of a TA >(e.g. which applications must accept a TA, when Tas need to be replaced, >conditions for deleting TAs, etc). A device may have multiple TAs in it, for use by different apps. If so, one needs to define the scope for each TA, to that its use by an app, or set of apps, is well-defined. Also, one may define a TA that controls the management of other TAs, which then sounds more like control over a device (from the perspective of TAs). If there are TAs that control what software may be loaded into a device, then that too sounds like device control, but not all contexts may require signed software and thus we would be (unduly) limiting our scope if we talked only in these terms. >So, it makes sense not to bloat a TA with various policy-related >information. A TA should have an identifier that policy-management >tools and policy-engines refer to. Maybe. But I think it is also worth examining definition of a data package that includes the path validation constraints, and data defining the scope of the TA, as a way of consolidating this info. Steve --============_-1029665730==_ma============ Content-Type: text/html; charset="us-ascii" RE: Distribution of trust anchor policy
At 12:37 PM -0700 6/21/07, Thomas Hardjono wrote:

OK, so my (limited) understanding of Trust Anchors (TA) is that they
represent an *authority* over the entity (device) at which the TA has
been installed. This means that TA Management (which is what the
draft-00 covers) is really "authority management". Which is whi the
draft talks about stuff like "authority over devices etc."

I would not adopt that working definition, despite its presence in the -00 draft. I think Carl has agreed that this is not the best way to characterize the problem.

I think this is distinct from *policy management*, which in this context
I take to be the management of the rules governing the usage of a TA
(e.g. which applications must accept a TA, when Tas need to be replaced,
conditions for deleting TAs, etc).

A device may have multiple TAs in it, for use by different apps. If so, one needs to define the scope for each TA, to that its use by an app, or set of apps, is well-defined. Also, one may define a TA that controls the management of other TAs, which then sounds more like control over a device (from the perspective of TAs). If there are TAs that control what software may be loaded into a device, then that too sounds like device control, but not all contexts may require signed software and thus we would be (unduly) limiting our scope if we talked only in these terms.

So, it makes sense not to bloat a TA with various policy-related
information. A TA should have an identifier that policy-management

tools and policy-engines refer to.

Maybe. But I think it is also worth examining definition of a data package that includes the path validation constraints, and data defining the scope of the TA, as a way of consolidating this info.

Steve
--============_-1029665730==_ma============-- From owner-ietf-trust-anchor Thu Jun 21 13:55:46 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LKtkBh020895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 13:55:46 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LKtkwD020892; Thu, 21 Jun 2007 13:55:46 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LKthEm020871 for ; Thu, 21 Jun 2007 13:55:45 -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 1I1Tgs-0003Vs-5D for ietf-trust-anchor@vpnc.org; Thu, 21 Jun 2007 16:55:42 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 21 Jun 2007 16:44:16 -0400 To: ietf-trust-anchor@vpnc.org From: Stephen Kent Subject: slight whoops Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I said "I agree with your example and it has long been a source of frustration for me that name constraints (and some other cert path validation constraints) are not inherited from a TA, as per X.509!" What I meant to say was that some path validation constraints that can be expressed by extensions in a self-signed cert representation of a TA are not automatically used to initialize the path validation algorithm (in X.509 and PKIX). For example, the path validation algorithm allows one to specify permitted and excluded subtrees as initialization parameters for path validation, but they are not described as being extracted from a self-signed cert used as a TA. Steve From owner-ietf-trust-anchor Thu Jun 21 14:07:37 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LL7b0w023627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 14:07:37 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LL7bfT023626; Thu, 21 Jun 2007 14:07:37 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LL7alK023612; Thu, 21 Jun 2007 14:07:36 -0700 (MST) (envelope-from jon@pgpeng.com) Received: from keys.pgpeng.com (keys.pgpeng.com [127.0.0.1]) by keys.pgpeng.com (PGP Universal) with ESMTP id E0FF3F01AD; Thu, 21 Jun 2007 14:07:35 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Thu, 21 Jun 2007 14:07:35 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 21 Jun 2007 14:07:35 -0700 Received: from [63.251.255.74] (account jon HELO keys.pgpeng.com) by pgpeng.com (CommuniGate Pro SMTP 4.3.7) with ESMTPSA id 1833950; Thu, 21 Jun 2007 14:07:35 -0700 Received: from [10.240.72.115] ([208.54.15.1]) by keys.pgpeng.com (PGP Universal service); Thu, 21 Jun 2007 14:07:35 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 21 Jun 2007 14:07:35 -0700 In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <2DDAF7BE-C522-4370-BC34-CC94CEC07B54@pgpeng.com> Cc: ietf-trust-anchor@vpnc.org From: Jon Callas Subject: Re: Does the problem need solving? Date: Thu, 21 Jun 2007 11:29:21 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Even though we have gone well over a decade without an > interoperable solution, I think we got here mostly through applied > denial and kludges. One result of that has been that organizational > users of PKI are stuck with having to live with the trust decisions > made by their OS vendors, their applications vendors, or both. > Another is that people have been trained to click through the "this > cert is not signed by a trusted root" dialog because it is too hard > for an enterprise to push their desired trust anchors to their > employees. > > I would argue in favor that the problem needs solving. I hope that > there is also a critical mass of people who care enough about the > future of the PKI user experience to do the work. > Can we get a clear statement of what the problem is? I think I can infer it -- that browsers and other software that have to supply some set of roots do so ad hoc. There's no unified mechanism to specify what the collected set of roots is. Is that the problem? Am I even close? I think having a clear problem statement should be a prerequisite to having a BOF, myself. Without this, we're guaranteed that the outcome will not have focus. I have a lot of other questions, but they presuppose I understand the problem statement, and I don't know that I do. Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 3460 West Bayshore Fax: +1 (650) 319-9001 Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From owner-ietf-trust-anchor Thu Jun 21 14:16:47 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LLGl3L025925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 14:16:47 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LLGl5Q025924; Thu, 21 Jun 2007 14:16:47 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (adsl-66-125-125-71.dsl.pltn13.pacbell.net [66.125.125.71]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LLGjux025917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 14:16:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <2DDAF7BE-C522-4370-BC34-CC94CEC07B54@pgpeng.com> References: <20070615210637.GA25975@vacation.karoshi.com.> <2DDAF7BE-C522-4370-BC34-CC94CEC07B54@pgpeng.com> Date: Thu, 21 Jun 2007 14:16:29 -0700 To: Jon Callas From: Paul Hoffman Subject: Re: Does the problem need solving? Cc: ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:29 AM -0700 6/21/07, Jon Callas wrote: >I think I can infer it -- that browsers and other software that have >to supply some set of roots do so ad hoc. I would say it differently: that applications that *need* some set of roots get those roots ad hoc. >There's no unified mechanism to specify what the collected set of roots is. There's no unified mechanism to get a collection of roots from a trusted source. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 21 14:35:09 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LLZ92N030529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 14:35:09 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LLZ9F5030528; Thu, 21 Jun 2007 14:35:09 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LLZ6Vu030498; Thu, 21 Jun 2007 14:35:08 -0700 (MST) (envelope-from jon@pgpeng.com) Received: from keys.pgpeng.com (keys.pgpeng.com [127.0.0.1]) by keys.pgpeng.com (PGP Universal) with ESMTP id 02189F01AF; Thu, 21 Jun 2007 14:35:06 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Thu, 21 Jun 2007 14:35:06 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 21 Jun 2007 14:35:06 -0700 Received: from [63.251.255.74] (account jon HELO keys.pgpeng.com) by pgpeng.com (CommuniGate Pro SMTP 4.3.7) with ESMTPSA id 1834032; Thu, 21 Jun 2007 14:35:05 -0700 Received: from [10.240.72.115] ([208.54.15.1]) by keys.pgpeng.com (PGP Universal service); Thu, 21 Jun 2007 14:35:05 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 21 Jun 2007 14:35:05 -0700 In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> <2DDAF7BE-C522-4370-BC34-CC94CEC07B54@pgpeng.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: Cc: ietf-trust-anchor@vpnc.org From: Jon Callas Subject: Re: Does the problem need solving? Date: Thu, 21 Jun 2007 14:35:05 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 21, 2007, at 2:16 PM, Paul Hoffman wrote: > At 11:29 AM -0700 6/21/07, Jon Callas wrote: >> I think I can infer it -- that browsers and other software that >> have to supply some set of roots do so ad hoc. > > I would say it differently: that applications that *need* some set > of roots get those roots ad hoc. > I'm reminded of an old joke -- a woman walks into a restaurant in Boston of over a century ago and sees some matrons with amazing hats. She asks one matron, "What a lovely hat! Where did you get it?" The matron sniffed disapprovingly and said, "We didn't *get* our hats, we *have* our hats." In other words, I hear you on need versus have, but is there a difference? Acquiring sets of roots is only ad-hoc if you think of them that way. Internet Explorer gets its from Microsoft, Mozilla gets its roots from its anchors from its makers, and so on. My software has a set of roots, which it gets from me. Why shouldn't it get its roots from me? >> There's no unified mechanism to specify what the collected set of >> roots is. > > There's no unified mechanism to get a collection of roots from a > trusted source. > So am I correct in thinking that this is in some way making a root-of- all-roots? Let me phrase it another way: if I receive a Trust Anchor object containing a set of roots, how do I know it's trustworthy? How do I know that that replacement root for a given CA really came from them? It seems to me that there's an easy answer -- the makers of software bake a Trust Anchor object into their software, and if you need new Trust Anchors you import additional Trust Anchors into a Trust Anchor database. I have many more questions, but they presuppose I understand this. Before that, the question on the subject line still remains a good one, along with "what problem are we actually solving?" As a maker of software that supplies roots, will this make my life easier? It sounds to me like I'm ceding authority to some unspecified party. Would that party be IANA? Alternatively, let's suppose I want to become a CA. Will this make my life easier getting my root into a number of places? Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 3460 West Bayshore Fax: +1 (650) 319-9001 Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From owner-ietf-trust-anchor Thu Jun 21 14:37:56 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LLbtYC031332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 14:37:55 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LLbtXv031331; Thu, 21 Jun 2007 14:37:55 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LLbsgj031309; Thu, 21 Jun 2007 14:37:55 -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 1I1ULi-00040o-3L; Thu, 21 Jun 2007 17:37:54 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <2DDAF7BE-C522-4370-BC34-CC94CEC07B54@pgpeng.com> References: <20070615210637.GA25975@vacation.karoshi.com.> <2DDAF7BE-C522-4370-BC34-CC94CEC07B54@pgpeng.com> Date: Thu, 21 Jun 2007 17:30:44 -0400 To: Jon Callas From: Stephen Kent Subject: Re: Does the problem need solving? Cc: Paul Hoffman , ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:29 AM -0700 6/21/07, Jon Callas wrote: >>Even though we have gone well over a decade without an >>interoperable solution, I think we got here mostly through applied >>denial and kludges. One result of that has been that organizational >>users of PKI are stuck with having to live with the trust decisions >>made by their OS vendors, their applications vendors, or both. >>Another is that people have been trained to click through the "this >>cert is not signed by a trusted root" dialog because it is too hard >>for an enterprise to push their desired trust anchors to their >>employees. >> >>I would argue in favor that the problem needs solving. I hope that >>there is also a critical mass of people who care enough about the >>future of the PKI user experience to do the work. >> > >Can we get a clear statement of what the problem is? > >I think I can infer it -- that browsers and other software that have >to supply some set of roots do so ad hoc. There's no unified >mechanism to specify what the collected set of roots is. first, the aps don't supply the roots, they are consumers of roots :-)! And yes, there is no standard, good way to supply the roots, including info that constrains how the roots are used. Steve From owner-ietf-trust-anchor Thu Jun 21 14:44:32 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LLiV1k033094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 14:44:31 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LLiViD033093; Thu, 21 Jun 2007 14:44:31 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from ca-server2.wavx.wavesys.com (ca-server2.wavx.wavesys.com [65.197.200.86] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LLiUAA033063; Thu, 21 Jun 2007 14:44:31 -0700 (MST) (envelope-from thardjono@wavesys.com) 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" Subject: RE: Does the problem need solving? Date: Thu, 21 Jun 2007 14:44:46 -0700 Message-ID: In-Reply-To: <2DDAF7BE-C522-4370-BC34-CC94CEC07B54@pgpeng.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace0SO+Y/tM2Ff2MQ6Sh47V/+CzfTgABCs2g From: "Thomas Hardjono" To: "Jon Callas" , "Paul Hoffman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5LLiVAA033078 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I thought Section 2 (last parag) of the draft-00 was a good start to defining the problem: ...standard means for reporting the trust anchors installed in a particular device" and "for managing those trust anchors". I think the key word is *management* (Create TAs, Verify TAs, Distribute TAs, Install/Delete TAs, Replace TAs, etc) in a secure manner. Maybe we need to agree on the definition of Trust Anchors -- before we can agree how to manage them :) /thomas/ -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Jon Callas Sent: Thursday, June 21, 2007 11:29 AM To: Paul Hoffman Cc: ietf-trust-anchor@vpnc.org Subject: Re: Does the problem need solving? > > Even though we have gone well over a decade without an interoperable > solution, I think we got here mostly through applied denial and > kludges. One result of that has been that organizational users of PKI > are stuck with having to live with the trust decisions made by their > OS vendors, their applications vendors, or both. > Another is that people have been trained to click through the "this > cert is not signed by a trusted root" dialog because it is too hard > for an enterprise to push their desired trust anchors to their > employees. > > I would argue in favor that the problem needs solving. I hope that > there is also a critical mass of people who care enough about the > future of the PKI user experience to do the work. > Can we get a clear statement of what the problem is? I think I can infer it -- that browsers and other software that have to supply some set of roots do so ad hoc. There's no unified mechanism to specify what the collected set of roots is. Is that the problem? Am I even close? I think having a clear problem statement should be a prerequisite to having a BOF, myself. Without this, we're guaranteed that the outcome will not have focus. I have a lot of other questions, but they presuppose I understand the problem statement, and I don't know that I do. Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 3460 West Bayshore Fax: +1 (650) 319-9001 Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From owner-ietf-trust-anchor Thu Jun 21 14:52:27 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LLqRNt035632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 14:52:27 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LLqRW4035629; Thu, 21 Jun 2007 14:52:27 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from ca-server2.wavx.wavesys.com (ca-server2.wavx.wavesys.com [65.197.200.86] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LLqPEb035600; Thu, 21 Jun 2007 14:52:26 -0700 (MST) (envelope-from thardjono@wavesys.com) 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" Subject: RE: Does the problem need solving? Date: Thu, 21 Jun 2007 14:52:41 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace0TULVrj+zfHadQ4e6M3Piur/JTAAAEiPg From: "Thomas Hardjono" To: "Stephen Kent" , "Jon Callas" Cc: "Paul Hoffman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5LLqQEb035602 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with Steve: the aps don't supply the roots. (ps. users of IE have been brainwashed to just accept CA certs that happen to be shipping in IE). Furthermore, I think TA management needs to be IT-driven. That is, the IT Admin person through the (remote) management console needs to be the entity managing the TAs at the device end-points. I know that this is Enterprise-centric view, but it probably limits the scope of work to be something achieveable in a WG within reasonable time. /thomas/ -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen Kent Sent: Thursday, June 21, 2007 2:31 PM To: Jon Callas Cc: Paul Hoffman; ietf-trust-anchor@vpnc.org Subject: Re: Does the problem need solving? At 11:29 AM -0700 6/21/07, Jon Callas wrote: >>Even though we have gone well over a decade without an interoperable >>solution, I think we got here mostly through applied denial and >>kludges. One result of that has been that organizational users of PKI >>are stuck with having to live with the trust decisions made by their >>OS vendors, their applications vendors, or both. >>Another is that people have been trained to click through the "this >>cert is not signed by a trusted root" dialog because it is too hard >>for an enterprise to push their desired trust anchors to their >>employees. >> >>I would argue in favor that the problem needs solving. I hope that >>there is also a critical mass of people who care enough about the >>future of the PKI user experience to do the work. >> > >Can we get a clear statement of what the problem is? > >I think I can infer it -- that browsers and other software that have to >supply some set of roots do so ad hoc. There's no unified mechanism to >specify what the collected set of roots is. first, the aps don't supply the roots, they are consumers of roots :-)! And yes, there is no standard, good way to supply the roots, including info that constrains how the roots are used. Steve From owner-ietf-trust-anchor Thu Jun 21 15:07:04 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LM740l039829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 15:07:04 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LM74ri039828; Thu, 21 Jun 2007 15:07:04 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LM72Jb039812; Thu, 21 Jun 2007 15:07:03 -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 1I1Unu-0004GW-4F; Thu, 21 Jun 2007 18:07:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> <2DDAF7BE-C522-4370-BC34-CC94CEC07B54@pgpeng.com> Date: Thu, 21 Jun 2007 17:49:00 -0400 To: Jon Callas From: Stephen Kent Subject: Re: Does the problem need solving? Cc: Paul Hoffman , ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:35 PM -0700 6/21/07, Jon Callas wrote: >On Jun 21, 2007, at 2:16 PM, Paul Hoffman wrote: > >>At 11:29 AM -0700 6/21/07, Jon Callas wrote: >>>I think I can infer it -- that browsers and other software that >>>have to supply some set of roots do so ad hoc. >> >>I would say it differently: that applications that *need* some set >>of roots get those roots ad hoc. >> > >I'm reminded of an old joke -- a woman walks into a restaurant in >Boston of over a century ago and sees some matrons with amazing >hats. She asks one matron, "What a lovely hat! Where did you get >it?" The matron sniffed disapprovingly and said, "We didn't *get* >our hats, we *have* our hats." In other words, I hear you on need >versus have, but is there a difference? as someone living on Boston, but not owning any hats that merit such attention, I still believe in the need to be accurate in the words we use in this discussion. >Acquiring sets of roots is only ad-hoc if you think of them that >way. Internet Explorer gets its from Microsoft, Mozilla gets its >roots from its anchors from its makers, and so on. My software has a >set of roots, which it gets from me. Why shouldn't it get its roots >from me? In the case of the browsers, enterprise IT administrative staff often want the ability to change the default set of TAs supplied by the browsers, and there is no standard (nor easy) way to do that, short of becoming a surrogate distribution point for the browser software. So, in general, there are situations in which it is appropriate for other than the software vendor to be the supplier of TAs for use by that software. >>>There's no unified mechanism to specify what the collected set of roots is. >> >>There's no unified mechanism to get a collection of roots from a >>trusted source. >> > >So am I correct in thinking that this is in some way making a >root-of-all-roots? maybe, if what you mean is a TA that can be used to manage the import of and control the scope of other TAs, and if the single TA may be either locally managed or managed by the supplier of a device. >Let me phrase it another way: if I receive a Trust Anchor object >containing a set of roots, how do I know it's trustworthy? How do I >know that that replacement root for a given CA really came from them? this is only part of the problem. >It seems to me that there's an easy answer -- the makers of software >bake a Trust Anchor object into their software, and if you need new >Trust Anchors you import additional Trust Anchors into a Trust >Anchor database. that would not be sufficient, because it assumes that I never want to replace the TA supplied by the SW vendor, only augment it. >I have many more questions, but they presuppose I understand this. > >Before that, the question on the subject line still remains a good >one, along with "what problem are we actually solving?" > >As a maker of software that supplies roots, will this make my life easier? viable solutions should make life easier for two classes of folks: those who want to locally manage TAs and those who supply HW (and maybe SW) and want to maintain control over some TAs, but cede some of that control to local TA managers. > It sounds to me like I'm ceding authority to some unspecified >party. Would that party be IANA? not even close. >Alternatively, let's suppose I want to become a CA. Will this make >my life easier getting my root into a number of places? I don't know about your example, but if I am a CA for an enterprise and I want to install a TA in a set of machines in that enterprise, the solution should enable that. Steve From owner-ietf-trust-anchor Thu Jun 21 15:44:17 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LMiH1L051524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 15:44:17 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LMiHiB051523; Thu, 21 Jun 2007 15:44:17 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LMiGR4051516 for ; Thu, 21 Jun 2007 15:44:16 -0700 (MST) (envelope-from jon@pgpeng.com) Received: from keys.pgpeng.com (keys.pgpeng.com [127.0.0.1]) by keys.pgpeng.com (PGP Universal) with ESMTP id 371BAF01AD for ; Thu, 21 Jun 2007 15:44:16 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Thu, 21 Jun 2007 15:44:16 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 21 Jun 2007 15:44:16 -0700 Received: from [63.251.255.74] (account jon HELO keys.pgpeng.com) by pgpeng.com (CommuniGate Pro SMTP 4.3.7) with ESMTPSA id 1834398 for ietf-trust-anchor@vpnc.org; Thu, 21 Jun 2007 15:44:15 -0700 Received: from [10.224.95.147] ([208.54.15.129]) by keys.pgpeng.com (PGP Universal service); Thu, 21 Jun 2007 15:44:16 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 21 Jun 2007 15:44:16 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Message-Id: <1D4FE308-1856-4033-89FF-783D4B0579BA@pgpeng.com> From: Jon Callas Subject: Re: Does the problem need solving? Date: Thu, 21 Jun 2007 15:18:42 -0700 To: ietf-trust-anchor@vpnc.org X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 21, 2007, at 2:44 PM, Thomas Hardjono wrote: > > > Maybe we need to agree on the definition of Trust Anchors -- before we > can agree how to manage them :) > Hear, hear. The more we discuss this, the less I think we have a decent definition on it. Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 3460 West Bayshore Fax: +1 (650) 319-9001 Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From owner-ietf-trust-anchor Thu Jun 21 15:44:18 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LMiHlq051533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 15:44:17 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LMiHaq051532; Thu, 21 Jun 2007 15:44:17 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LMiHuX051525 for ; Thu, 21 Jun 2007 15:44:17 -0700 (MST) (envelope-from jon@pgpeng.com) Received: from keys.pgpeng.com (keys.pgpeng.com [127.0.0.1]) by keys.pgpeng.com (PGP Universal) with ESMTP id 3627EF01AD for ; Thu, 21 Jun 2007 15:44:17 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Thu, 21 Jun 2007 15:44:17 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 21 Jun 2007 15:44:17 -0700 Received: from [63.251.255.74] (account jon HELO keys.pgpeng.com) by pgpeng.com (CommuniGate Pro SMTP 4.3.7) with ESMTPSA id 1834396 for ietf-trust-anchor@vpnc.org; Thu, 21 Jun 2007 15:44:16 -0700 Received: from [10.224.95.147] ([208.54.15.129]) by keys.pgpeng.com (PGP Universal service); Thu, 21 Jun 2007 15:44:17 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 21 Jun 2007 15:44:17 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> <2DDAF7BE-C522-4370-BC34-CC94CEC07B54@pgpeng.com> Message-Id: From: Jon Callas Subject: Re: Does the problem need solving? Date: Thu, 21 Jun 2007 15:24:32 -0700 To: ietf-trust-anchor@vpnc.org X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 21, 2007, at 2:30 PM, Stephen Kent wrote: > >> >> I think I can infer it -- that browsers and other software that >> have to supply some set of roots do so ad hoc. There's no unified >> mechanism to specify what the collected set of roots is. > > first, the aps don't supply the roots, they are consumers of > roots :-)! And yes, there is no standard, good way to supply the > roots, including info that constrains how the roots are used. > Steve, I realize you have a smiley face on your statement, and my mailer doesn't implement the ISO 10646 tone-of-voice bits. However, as someone who makes an app that supplies roots, it's a statement of fact that I supply the roots, just as I supply the executable code. If you are saying that I (and by implication everyone like me, including Microsoft, Mozilla, and others) should get them from some common source, I have to blink a few times. Is this, then the root-of-all-roots BOF? Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 3460 West Bayshore Fax: +1 (650) 319-9001 Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From owner-ietf-trust-anchor Thu Jun 21 15:49:30 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LMnUTH053270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 15:49:30 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LMnUl5053269; Thu, 21 Jun 2007 15:49:30 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from nmta3.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.108]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LMnTfS053256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 15:49:30 -0700 (MST) (envelope-from hotz@jpl.nasa.gov) Received: from xmta2.jpl.nasa.gov (xmta2.jpl.nasa.gov [137.78.160.56]) by nmta3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l5LMnSik006073; Thu, 21 Jun 2007 15:49:28 -0700 Received: from [137.78.61.96] (laphotz.jpl.nasa.gov [137.78.61.96]) by xmta2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l5LMnQ96004058; Thu, 21 Jun 2007 15:49:27 -0700 In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> <467981EE.2050400@cs.tcd.ie> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ietf-trust-anchor@vpnc.org Content-Transfer-Encoding: 7bit From: "Henry B. Hotz" Subject: Re: Trust anchors for multiple applications Date: Thu, 21 Jun 2007 15:49:25 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.752.3) X-Source-IP: laphotz.jpl.nasa.gov [137.78.61.96] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 21, 2007, at 10:33 AM, Paul Hoffman wrote: > At 1:08 PM -0400 6/21/07, Stephen Kent wrote: >> One suggestion is that we view the problem not as managing TAs for >> a box, but more generally for applications, recognizing that >> different apps may need different sets of TAs. If a box has just >> one app, then this seems like a roughly equivalent formulation of >> the problem. This would help avoid the language such as "Once >> installed, a trust anchor represents an entity with authority over >> a device." which seems too narrow. > > Fully agree. A real-world example of this is installing the Firefox > browser on a Windows system. The Firefox browser has its own set of > trust anchors, separate from the ones for Windows. > > A more hypothetical example, but one that is valuable in the > corporate marketplace, is a set of trust anchors for a corporate- > developed application. That application might start off with just > one trust anchor, from the developer, but could expand to others as > partners outside the corporation are added. As a specifically different category, the trust anchor I use with PKINIT/Kerberos to control workstation login SHOULD be different from the collection I use with IE/Firefox to say if a web site is legit. With Jabber I may want two sets in the same application: a specific one for the company service, and a generic collection (perhaps the same as IE/Firefox) that I use to verify other public services. We all agree that different things probably need different anchors. I think we need to let the user (or the IT support organization) specify different levels of trust associated with different trust anchors. We need to be able to specify that certain services need to be authenticated with certain trust anchors. Let me be more concrete: I know that the cert's used for JPL's Kerberos, LDAP, email, web, and Jabber services will come from specific CA's. They aren't all from the same one, either. I need to guarantee that JPL (at least) clients will authenticate the legitimate certs for those services. I also need to guarantee that a correctly formatted cert from some front organization that traces to some other usually legitimate CA is still rejected for those services. Finally (though this is less important) I would like a way to change those specific CA's when a service migrates to a new CA. ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From owner-ietf-trust-anchor Thu Jun 21 16:50:33 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LNoXJK070822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 16:50:33 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LNoXEF070821; Thu, 21 Jun 2007 16:50:33 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from nmta2.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.215]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LNoWZS070806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 16:50:32 -0700 (MST) (envelope-from hotz@jpl.nasa.gov) Received: from xmta2.jpl.nasa.gov (xmta2.jpl.nasa.gov [137.78.160.56]) by nmta2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l5LNoUPV001609; Thu, 21 Jun 2007 16:50:30 -0700 Received: from [137.78.61.96] (laphotz.jpl.nasa.gov [137.78.61.96]) by xmta2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l5LNoTeS001207; Thu, 21 Jun 2007 16:50:29 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <606890F7-6C77-4621-9667-4B7317DB5DC3@jpl.nasa.gov> Cc: ietf-trust-anchor@vpnc.org Content-Transfer-Encoding: 7bit From: "Henry B. Hotz" Subject: Re: Distribution of trust anchor policy Date: Thu, 21 Jun 2007 16:50:27 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.752.3) X-Source-IP: laphotz.jpl.nasa.gov [137.78.61.96] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 21, 2007, at 10:45 AM, Paul Hoffman wrote: > Another requirement that I see only touched on a bit in the first > draft is that of policy. As the trust anchor administrator, I might > want to distribute a trust anchor but to require that it only be > used for trusting certificates whose domain names are in > example.com. The trust anchor itself might not have the name > constraint in it, but the constraint is what I, as administrator, > am telling my users to trust it for. Thus, I need to be able to > express some kind of policy with a trust anchor. Following on my last post, I think this stands the real issue on its head. For example: I'm sitting in front of an email client and I can decode this email using a cert that traces in a perfectly valid way to e.g. a Verisign CA. This is a valid CA that I should use for lots of legitimate email to lots of people, so I *want* this CA in my trust anchors. BUT The specific email in question purports to come from someone at e.g. NASA HQ. Verisign has not (and maybe can't) specify any constraints that prohibit the use of the certs in question for @nasa.gov email addresses. However, as a matter of policy all NASA business should be encrypted with certs that are traceable to the Federal Bridge CA. In other words, the problem isn't specifying that a specific chain is only valid for a specific domain/purpose. The problem is specifying that no other chain is valid for that domain/purpose, REGARDLESS OF WHAT THE OTHER CHAINS CLAIM. I think this sort of conflict resolution is inherently outside the scope of what can be represented inside any possible specific anchor. ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From owner-ietf-trust-anchor Thu Jun 21 18:56:46 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5M1ukTE098546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 18:56:46 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5M1ukHI098545; Thu, 21 Jun 2007 18:56:46 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5M1uhqC098528 for ; Thu, 21 Jun 2007 18:56:45 -0700 (MST) (envelope-from jon@pgpeng.com) Received: from keys.pgpeng.com (keys.pgpeng.com [127.0.0.1]) by keys.pgpeng.com (PGP Universal) with ESMTP id 1BABBF01AF for ; Thu, 21 Jun 2007 18:56:43 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Thu, 21 Jun 2007 18:56:43 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 21 Jun 2007 18:56:43 -0700 Received: from [63.251.255.74] (account jon HELO keys.pgpeng.com) by pgpeng.com (CommuniGate Pro SMTP 4.3.7) with ESMTPSA id 1835717 for ietf-trust-anchor@vpnc.org; Thu, 21 Jun 2007 18:56:42 -0700 Received: from [66.93.68.165] ([66.93.68.165]) by keys.pgpeng.com (PGP Universal service); Thu, 21 Jun 2007 18:56:42 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 21 Jun 2007 18:56:42 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> <2DDAF7BE-C522-4370-BC34-CC94CEC07B54@pgpeng.com> Message-Id: From: Jon Callas Subject: Re: Does the problem need solving? Date: Thu, 21 Jun 2007 18:56:21 -0700 To: ietf-trust-anchor@vpnc.org X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 21, 2007, at 2:49 PM, Stephen Kent wrote: >> I'm reminded of an old joke -- a woman walks into a restaurant in >> Boston of over a century ago and sees some matrons with amazing >> hats. She asks one matron, "What a lovely hat! Where did you get >> it?" The matron sniffed disapprovingly and said, "We didn't *get* >> our hats, we *have* our hats." In other words, I hear you on need >> versus have, but is there a difference? > > as someone living on Boston, but not owning any hats that merit > such attention, I still believe in the need to be accurate in the > words we use in this discussion. > Which is precisely what I'm asking for. >> Acquiring sets of roots is only ad-hoc if you think of them that >> way. Internet Explorer gets its from Microsoft, Mozilla gets its >> roots from its anchors from its makers, and so on. My software has >> a set of roots, which it gets from me. Why shouldn't it get its >> roots from me? > > In the case of the browsers, enterprise IT administrative staff > often want the ability to change the default set of TAs supplied by > the browsers, and there is no standard (nor easy) way to do that, > short of becoming a surrogate distribution point for the browser > software. So, in general, there are situations in which it is > appropriate for other than the software vendor to be the supplier > of TAs for use by that software. Excellent! I need this, both as an administrator, and also as a vendor who would like to be able to pass roots around. > >>>> There's no unified mechanism to specify what the collected set >>>> of roots is. >>> >>> There's no unified mechanism to get a collection of roots from a >>> trusted source. >>> >> >> So am I correct in thinking that this is in some way making a root- >> of-all-roots? > > maybe, if what you mean is a TA that can be used to manage the > import of and control the scope of other TAs, and if the single TA > may be either locally managed or managed by the supplier of a device. Well, I'm asking what other people mean. I didn't write this draft, I'm trying to understand it. I think a root-of-all-roots, is not possible and opens up large numbers of intractable questions (which start with the previously mentioned p-word (policy) and get into others (like politics), so I hope this isn't what we're trying to solve. > >> Let me phrase it another way: if I receive a Trust Anchor object >> containing a set of roots, how do I know it's trustworthy? How do >> I know that that replacement root for a given CA really came from >> them? > > this is only part of the problem. Yeah, but if this is a way that I can hand my corporation's internal root to all browsers on all my corporate machines, then I know where it comes from. If I am understanding the problem statement correctly now, there's a minor issue of knowing how to trust your trust anchor, but that's not unsolvable. > >> It seems to me that there's an easy answer -- the makers of >> software bake a Trust Anchor object into their software, and if >> you need new Trust Anchors you import additional Trust Anchors >> into a Trust Anchor database. > > that would not be sufficient, because it assumes that I never want > to replace the TA supplied by the SW vendor, only augment it. > This is also good good news, but I can see where someone might want to remove a root from the National CA of Elbonia, because of policy. >> I have many more questions, but they presuppose I understand this. >> >> Before that, the question on the subject line still remains a good >> one, along with "what problem are we actually solving?" >> >> As a maker of software that supplies roots, will this make my life >> easier? > > viable solutions should make life easier for two classes of folks: > those who want to locally manage TAs and those who supply HW (and > maybe SW) and want to maintain control over some TAs, but cede some > of that control to local TA managers. > >> It sounds to me like I'm ceding authority to some unspecified >> party. Would that party be IANA? > > not even close. > >> Alternatively, let's suppose I want to become a CA. Will this make >> my life easier getting my root into a number of places? > > I don't know about your example, but if I am a CA for an enterprise > and I want to install a TA in a set of machines in that enterprise, > the solution should enable that. > That's even more good news. I'm feeling a lot better than I was a couple hours ago. Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 3460 West Bayshore Fax: +1 (650) 319-9001 Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From owner-ietf-trust-anchor Fri Jun 22 03:44:21 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MAiLt4028297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 03:44:21 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5MAiL2Z028296; Fri, 22 Jun 2007 03:44:21 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from vinyl.extundo.com (vinyl.extundo.com [83.241.192.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MAiIVW028279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Jun 2007 03:44:20 -0700 (MST) (envelope-from simon@josefsson.org) Received: from mocca.josefsson.org (38.177.241.83.in-addr.dgcsystems.net [83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l5MAhwdx010706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jun 2007 12:44:08 +0200 From: Simon Josefsson To: "Henry B. Hotz" Cc: Paul Hoffman , ietf-trust-anchor@vpnc.org Subject: Re: Distribution of trust anchor policy References: <606890F7-6C77-4621-9667-4B7317DB5DC3@jpl.nasa.gov> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070622:hotz@jpl.nasa.gov::ozbGKk7cBUpsPh8P:2ikE X-Hashcash: 1:22:070622:paul.hoffman@vpnc.org::ExpPaT+yRKsLw2yh:BhpY X-Hashcash: 1:22:070622:ietf-trust-anchor@vpnc.org::AcJs8w6RB7Z1obu7:U48e Date: Fri, 22 Jun 2007 12:43:58 +0200 In-Reply-To: <606890F7-6C77-4621-9667-4B7317DB5DC3@jpl.nasa.gov> (Henry B. Hotz's message of "Thu, 21 Jun 2007 16:50:27 -0700") Message-ID: <874pl0mfpt.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Henry B. Hotz" writes: > The specific email in question purports to come from someone at > e.g. NASA HQ. Verisign has not (and maybe can't) specify any > constraints that prohibit the use of the certs in question for > @nasa.gov email addresses. However, as a matter of policy all NASA > business should be encrypted with certs that are traceable to the > Federal Bridge CA. > > In other words, the problem isn't specifying that a specific chain is > only valid for a specific domain/purpose. The problem is specifying > that no other chain is valid for that domain/purpose, REGARDLESS OF > WHAT THE OTHER CHAINS CLAIM. This sounds like a authorization decision to me. It may be wiser to keep authentication and authorization decisions apart. Distributing trust anchors is difficult enough without also having to consider that a particular trust anchor may imply certain authorization decisions in some applications. > I think this sort of conflict resolution is inherently outside the > scope of what can be represented inside any possible specific anchor. I agree. However, one question is then whether this list/BOF/whatever should take on specifying a policy language that would solve your problem? There are already various access control languages around, e.g. XACML. What do you think? /Simon From owner-ietf-trust-anchor Fri Jun 22 04:09:52 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MB9p2x030167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 04:09:51 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5MB9p3m030166; Fri, 22 Jun 2007 04:09:51 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5MB9o6X030158 for ; Fri, 22 Jun 2007 04:09:50 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 26795 invoked from network); 22 Jun 2007 11:08:09 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;22 Jun 2007 11:08:09 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 22 Jun 2007 11:08:09 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Jun 2007 07:09:49 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D0D12@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: Distribution of trust anchor policy Date: Fri, 22 Jun 2007 07:09:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B4BD.D449B61C" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C7B4BD.D449B61C Content-Type: text/plain > > In other words, the problem isn't specifying that a > specific chain is > > only valid for a specific domain/purpose. The problem is > specifying > > that no other chain is valid for that domain/purpose, REGARDLESS OF > > WHAT THE OTHER CHAINS CLAIM. > > This sounds like a authorization decision to me. It may be > wiser to keep authentication and authorization decisions > apart. Distributing trust anchors is difficult enough > without also having to consider that a particular trust > anchor may imply certain authorization decisions in some applications. Including authorization to issue certificates in particular namespaces is routine. By associating name constraints with a TA, a TA manager could make sure no other chain is valid for a particular domain by only authorizing one TA for that domain (or by excluding the domain from all other TAs). Namespaces aside, authorization to manage trust anchors must be addressed. ------_=_NextPart_001_01C7B4BD.D449B61C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Distribution of trust anchor policy
> > In other words, the problem isn't = specifying that a
> specific chain is
> > only valid for a specific = domain/purpose. The problem is
> specifying
> > that no other chain is valid for that = domain/purpose, REGARDLESS OF
> > WHAT THE OTHER CHAINS CLAIM.
>
> This sounds like a authorization decision to = me. It may be
> wiser to keep authentication and authorization = decisions
> apart. Distributing trust anchors is = difficult enough
> without also having to consider that a = particular trust
> anchor may imply certain authorization = decisions in some applications.

Including authorization to issue certificates in = particular namespaces is routine. By associating name constraints = with a TA, a TA manager could make sure no other chain is valid for a = particular domain by only authorizing one TA for that domain (or by = excluding the domain from all other TAs).

Namespaces aside, authorization to manage trust = anchors must be addressed.
------_=_NextPart_001_01C7B4BD.D449B61C-- From owner-ietf-trust-anchor Fri Jun 22 04:45:13 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MBjDVE033962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 04:45:13 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5MBjDcl033961; Fri, 22 Jun 2007 04:45:13 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5MBjBEH033947 for ; Fri, 22 Jun 2007 04:45:12 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 27039 invoked from network); 22 Jun 2007 11:43:32 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;22 Jun 2007 11:43:32 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 22 Jun 2007 11:43:31 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Jun 2007 07:45:09 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D0D13@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? Date: Fri, 22 Jun 2007 07:44:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B4C2.B89FBC4C" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C7B4C2.B89FBC4C Content-Type: text/plain > Well, I'm asking what other people mean. I didn't write this > draft, I'm trying to understand it. > > I think a root-of-all-roots, is not possible and opens up > large numbers of intractable questions (which start with the > previously mentioned p-word (policy) and get into others > (like politics), so I hope this isn't what we're trying to solve. There's no universal root-of-all-roots notion intended in the draft. All roots need not spring from the same place. However, as Steve noted, for any particular trust store there may be a set of trust anchors authorized to manage the contents of the trust store. To some extent, the set of TAs authorized to manage a trust store could be viewed as the roots-of-all-roots for that trust store. In general, the idea is that there must be at least one trust anchor that is installed in any TA store for which trust is established using manual, out-of-band means. After this occurs, in-band management should be possible. Establishing a protocol to do this is the primary goal. Deciding on the trust anchor types to manage, extent of authorization to address, etc. is part of the scoping exercise. ------_=_NextPart_001_01C7B4C2.B89FBC4C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Does the problem need solving?
> Well, I'm asking what other people mean. I = didn't write this
> draft, I'm trying to understand it.
>
> I think a root-of-all-roots, is not possible = and opens up
> large numbers of intractable questions (which = start with the
> previously mentioned p-word (policy) and get = into others
> (like politics), so I hope this isn't what = we're trying to solve.

There's no universal root-of-all-roots notion = intended in the draft. All roots need not spring from the same = place. However, as Steve noted, for any particular trust store = there may be a set of trust anchors authorized to manage the contents = of the trust store. To some extent, the set of TAs authorized to = manage a trust store could be viewed as the roots-of-all-roots for that = trust store.

In general, the idea is that there must be at least = one trust anchor that is installed in any TA store for which trust is = established using manual, out-of-band means. After this occurs, = in-band management should be possible. Establishing a protocol to = do this is the primary goal. Deciding on the trust anchor types = to manage, extent of authorization to address, etc. is part of the = scoping exercise.
------_=_NextPart_001_01C7B4C2.B89FBC4C-- From owner-ietf-trust-anchor Fri Jun 22 05:29:12 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MCTBHd042189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 05:29:11 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5MCTBNo042188; Fri, 22 Jun 2007 05:29:11 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MCTAkh042181 for ; Fri, 22 Jun 2007 05:29:11 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 79861680DE for ; Fri, 22 Jun 2007 13:29:07 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A0196475DA1; Fri, 22 Jun 2007 13:29:07 +0100 Received: from [134.226.63.125] (cswireless63-125.cs.tcd.ie [134.226.63.125]) by imx2.tcd.ie (Postfix) with ESMTP id 60DF2680DE for ; Fri, 22 Jun 2007 13:29:07 +0100 (IST) Message-ID: <467BC102.5000004@cs.tcd.ie> Date: Fri, 22 Jun 2007 13:30:58 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-trust-anchor@vpnc.org Subject: Enterprise-only or more... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A1196475DA1 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.57.6 VDF=9.84.4) Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, It seems clear that we have some reasonable level of interest in trust anchor management for enterprises, where a corporate sysadmin manages various trust anchors for employees etc. One question I'd like to see discussed is whether or not this BoF should encompass other use cases, in particular, things like Internet banking. I could imagine a case where a bank would like to use client certs to authenticate customers, which is currently difficult since it more or less requires that the bank client-cert-root has to be in the browser due to the way that TLS works. (Note: Its been ages since I checked how current browsers handle client-auth so things might have gotten a bit better there, though if they have, I've not noticed;-) The differences here in my mind are that the bank don't own the client, and there's probably no sysadmin anywhere on the client side that understands any of this stuff. I've no real opinion as to whether such differences would result in protocol changes or not, but at least in principle, they could. So, do we have people interested in that, or similar, use cases, or are we really only going to try address our problem for enterprises? There are of course in-between positions, e.g. "both are interesting but only try solve for enterprises for now". If a bunch of people did say that, then I think we would still need to consider the topic at the BoF, e.g. so as to make sure we're not creating something that's good for enterprises, but not so good for the broader Internet. Cheers, Stephen. From owner-ietf-trust-anchor Fri Jun 22 07:02:19 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ME2IZk053877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 07:02:18 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5ME2ICr053876; Fri, 22 Jun 2007 07:02:18 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ME2Hg4053853; Fri, 22 Jun 2007 07:02:17 -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 1I1jiK-0007Zl-4O; Fri, 22 Jun 2007 10:02:16 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> <467981EE.2050400@cs.tcd.ie> Date: Fri, 22 Jun 2007 09:26:11 -0400 To: "Henry B. Hotz" From: Stephen Kent Subject: Re: Trust anchors for multiple applications Cc: Paul Hoffman , ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:49 PM -0700 6/21/07, Henry B. Hotz wrote: >... > >We all agree that different things probably need different anchors. >I think we need to let the user (or the IT support organization) >specify different levels of trust associated with different trust >anchors. Let's not assume that a notion like trust levels is generally applicable. defining the scope for each TA is essential, but there may be no notion of trust level per se. > We need to be able to specify that certain services need to be >authenticated with certain trust anchors. right. >Let me be more concrete: I know that the cert's used for JPL's >Kerberos, LDAP, email, web, and Jabber services will come from >specific CA's. They aren't all from the same one, either. I need >to guarantee that JPL (at least) clients will authenticate the >legitimate certs for those services. I also need to guarantee that >a correctly formatted cert from some front organization that traces >to some other usually legitimate CA is still rejected for those >services. Finally (though this is less important) I would like a >way to change those specific CA's when a service migrates to a new >CA. agreed. Steve From owner-ietf-trust-anchor Fri Jun 22 07:02:19 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ME2JUI053887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 07:02:19 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5ME2JDk053886; Fri, 22 Jun 2007 07:02:19 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ME2IAx053875 for ; Fri, 22 Jun 2007 07:02:19 -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 1I1jiM-0007Zl-4g; Fri, 22 Jun 2007 10:02:18 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1D4FE308-1856-4033-89FF-783D4B0579BA@pgpeng.com> References: <1D4FE308-1856-4033-89FF-783D4B0579BA@pgpeng.com> Date: Fri, 22 Jun 2007 09:50:21 -0400 To: Jon Callas From: Stephen Kent Subject: Re: Does the problem need solving? Cc: ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:18 PM -0700 6/21/07, Jon Callas wrote: >On Jun 21, 2007, at 2:44 PM, Thomas Hardjono wrote: > >> >> >>Maybe we need to agree on the definition of Trust Anchors -- before we >>can agree how to manage them :) >> > >Hear, hear. The more we discuss this, the less I think we have a >decent definition on it. > > Jon As I noted earlier, I know of one PKI standard that uses the term trust anchor, X.509, and so I interpret the problem statement in that context. Informally, X.509 and PKIX define a trust anchor as a public key, public key signature algorithm (plus parameters that may be needed by the algorithm), the issuer name, and other data used to initialize the path validation algorithm. The other data may include values for extensions that constrain path processing, e.g., name constraints, policy constraints, IP address space and AS number constraints. Steve From owner-ietf-trust-anchor Fri Jun 22 07:02:18 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ME2IE9053873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 07:02:18 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5ME2I21053872; Fri, 22 Jun 2007 07:02:18 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ME2Htq053854 for ; Fri, 22 Jun 2007 07:02:17 -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 1I1jiL-0007Zl-3r; Fri, 22 Jun 2007 10:02:17 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> <2DDAF7BE-C522-4370-BC34-CC94CEC07B54@pgpeng.com> Date: Fri, 22 Jun 2007 09:30:07 -0400 To: Jon Callas From: Stephen Kent Subject: Re: Does the problem need solving? Cc: ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:24 PM -0700 6/21/07, Jon Callas wrote: >On Jun 21, 2007, at 2:30 PM, Stephen Kent wrote: > >> >>> >>>I think I can infer it -- that browsers and other software that >>>have to supply some set of roots do so ad hoc. There's no unified >>>mechanism to specify what the collected set of roots is. >> >>first, the aps don't supply the roots, they are consumers of roots >>:-)! And yes, there is no standard, good way to supply the roots, >>including info that constrains how the roots are used. >> > >Steve, I realize you have a smiley face on your statement, and my >mailer doesn't implement the ISO 10646 tone-of-voice bits. > >However, as someone who makes an app that supplies roots, it's a >statement of fact that I supply the roots, just as I supply the >executable code. If you are saying that I (and by implication >everyone like me, including Microsoft, Mozilla, and others) should >get them from some common source, I have to blink a few times. I have said that is NOT the case, more than once, and I think I have said it fairly clearly. >Is this, then the root-of-all-roots BOF? Not in the sense that seems to cause you so much concern. Yes, you and other vendors supply roots. As a user I want to be able to discard them and supply my own. Many sys admins want to have the same local authority. Suppliers of some classes of devices want the same sort of authority, but also want to allow local managers some autonomy in managing some TAs. Steve From owner-ietf-trust-anchor Fri Jun 22 07:02:21 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ME2LLi053911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 07:02:21 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5ME2LXF053910; Fri, 22 Jun 2007 07:02:21 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5ME2KOq053897; Fri, 22 Jun 2007 07:02:20 -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 1I1jiN-0007Zl-4I; Fri, 22 Jun 2007 10:02:20 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <606890F7-6C77-4621-9667-4B7317DB5DC3@jpl.nasa.gov> References: <606890F7-6C77-4621-9667-4B7317DB5DC3@jpl.nasa.gov> Date: Fri, 22 Jun 2007 10:02:11 -0400 To: "Henry B. Hotz" From: Stephen Kent Subject: Re: Distribution of trust anchor policy Cc: Paul Hoffman , ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 4:50 PM -0700 6/21/07, Henry B. Hotz wrote: >On Jun 21, 2007, at 10:45 AM, Paul Hoffman wrote: > >>Another requirement that I see only touched on a bit in the first >>draft is that of policy. As the trust anchor administrator, I might >>want to distribute a trust anchor but to require that it only be >>used for trusting certificates whose domain names are in >>example.com. The trust anchor itself might not have the name >>constraint in it, but the constraint is what I, as administrator, >>am telling my users to trust it for. Thus, I need to be able to >>express some kind of policy with a trust anchor. > >Following on my last post, I think this stands the real issue on its >head. For example: > >I'm sitting in front of an email client and I can decode this email >using a cert that traces in a perfectly valid way to e.g. a Verisign >CA. This is a valid CA that I should use for lots of legitimate >email to lots of people, so I *want* this CA in my trust anchors. > >BUT > >The specific email in question purports to come from someone at e.g. >NASA HQ. Verisign has not (and maybe can't) specify any constraints >that prohibit the use of the certs in question for @nasa.gov email >addresses. However, as a matter of policy all NASA business should >be encrypted with certs that are traceable to the Federal Bridge CA. > >In other words, the problem isn't specifying that a specific chain >is only valid for a specific domain/purpose. The problem is >specifying that no other chain is valid for that domain/purpose, >REGARDLESS OF WHAT THE OTHER CHAINS CLAIM. > >I think this sort of conflict resolution is inherently outside the >scope of what can be represented inside any possible specific anchor. > the name constraints extension is designed to allow one to express the policy you cited above. however, because TTP CAs like VeriSign reserve the right to issue certs to any entity in any name space, life is harder. Nonetheless, it can be done, at least in principle. What one would need to do is to demote the VeriSign TA, i.e., make it NOT a TA. Create your own TA and issue a cert with the VS public key and a name constraints extension. In that extension, list the name spaces for which you know that other CAs are authoritative, as excluded subtrees. Thus, for example, you would like the names of U.S. government agencies as excluded from the VS CA, and list them as permitted for the U.S. federal Bridge CA. Obvioulsy this is a nontrivial management task, and a good example of why one might want to have a local admin be able to remotely manage TAs for a set of enterprise users. Steve From owner-ietf-trust-anchor Fri Jun 22 07:33:19 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MEXJYE058188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 07:33:19 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5MEXJph058187; Fri, 22 Jun 2007 07:33:19 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5MEXHBP058179 for ; Fri, 22 Jun 2007 07:33:18 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200706221433.l5MEXHBP058179@balder-227.proper.com> Received: (qmail 1117 invoked by uid 0); 22 Jun 2007 14:33:15 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.187) by woodstock.binhost.com with SMTP; 22 Jun 2007 14:33:15 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 22 Jun 2007 10:28:09 -0400 To: ietf-trust-anchor@vpnc.org From: Russ Housley Subject: Re: Does the problem need solving? In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> <2DDAF7BE-C522-4370-BC34-CC94CEC07B54@pgpeng.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon & Steve: I do not think that General Motors and Ford are likely to install the same set of trust anchors (or root certificates) in their applications. Some applications are intended for use with company sensitive information, and the administrators will want to ensure that the proper trust anchors are used, even if the two companies are using the same executable software. So, what does "central management" mean? It does not mean that the General Motors administrators can influence the trust anchor configuration in the copies of the software used within Ford. Rather, there is some out-of-band configuration step that is part of deployment to install one or more trust anchors that have the authorization to manage trust anchors. Then, going forward, the trust anchor configuration can be adjusted over the network, with authentication and integrity protection based on the currently installed trust anchors. Neither common set of executable software nor a common protocol means that a single authority has authorization over all of the trust anchor stores. It has already been pointed out that different applications within a single host are likely to need different sets of trust anchors. One very clear example in the X.509 context is Kerberos PKINIT needing a different trust anchor store from the web browser. This tells me that there will need to be a way to identify trust anchor stores in the protocol. Russ At 06:24 PM 6/21/2007, Jon Callas wrote: >On Jun 21, 2007, at 2:30 PM, Stephen Kent wrote: >>>I think I can infer it -- that browsers and other software that >>>have to supply some set of roots do so ad hoc. There's no unified >>>mechanism to specify what the collected set of roots is. >> >>first, the aps don't supply the roots, they are consumers of >>roots :-)! And yes, there is no standard, good way to supply the >>roots, including info that constrains how the roots are used. > >Steve, I realize you have a smiley face on your statement, and my >mailer doesn't implement the ISO 10646 tone-of-voice bits. > >However, as someone who makes an app that supplies roots, it's a >statement of fact that I supply the roots, just as I supply the >executable code. If you are saying that I (and by implication >everyone like me, including Microsoft, Mozilla, and others) should >get them from some common source, I have to blink a few times. > >Is this, then the root-of-all-roots BOF? > > Jon From owner-ietf-trust-anchor Fri Jun 22 10:50:46 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MHokGc000560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 10:50:46 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5MHokYJ000559; Fri, 22 Jun 2007 10:50:46 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MHoik1000547 for ; Fri, 22 Jun 2007 10:50:45 -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 1I1nHP-0008Iz-4l; Fri, 22 Jun 2007 13:50:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <467BC102.5000004@cs.tcd.ie> References: <467BC102.5000004@cs.tcd.ie> Date: Fri, 22 Jun 2007 13:50:45 -0400 To: Stephen Farrell From: Stephen Kent Subject: Re: Enterprise-only or more... Cc: ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen, In addition to the enterprise case, I think we should include the case of a device (and maybe software) distributed by a vendor to multiple enterprises or users. There are several obvious cases - the vendor retains complete control of all TAs for the device - the vendor is able to transfer control of TA management to another entity, e.g., a cable box going from a manufacturer to a cable TV operator - the vendor allows selected entities to install TAs, with well-defined scope (local admin) but retains top-level TA control There are probably more examples other could devise. Steve From owner-ietf-trust-anchor Fri Jun 22 12:16:06 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MJG6AL027492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 12:16:06 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5MJG6Pc027491; Fri, 22 Jun 2007 12:16:06 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MJG3vh027444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Jun 2007 12:16:05 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id EA24832133; Fri, 22 Jun 2007 20:15:58 +0100 (IST) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id l5MJFskn006787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jun 2007 20:15:55 +0100 Message-ID: <467C2055.3050003@cs.tcd.ie> Date: Fri, 22 Jun 2007 20:17:41 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephen Kent CC: ietf-trust-anchor@vpnc.org Subject: Re: Enterprise-only or more... References: <467BC102.5000004@cs.tcd.ie> In-Reply-To: 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: 10635925 - dd6ffb41b45e X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen Kent wrote: > > Stephen, > > In addition to the enterprise case, I think we should include the case > of a device (and maybe software) distributed by a vendor to multiple > enterprises or users. There are several obvious cases > - the vendor retains complete control of all TAs for the device > - the vendor is able to transfer control of TA management to > another entity, e.g., a cable box going from a manufacturer to a > cable TV operator > - the vendor allows selected entities to install TAs, with > well-defined scope (local admin) but retains top-level TA control > > There are probably more examples other could devise. Indeed. I guess I'd think of that as the mobile phone case, but yes, its yet another model that we may, or may not, decide to include here. S. From owner-ietf-trust-anchor Fri Jun 22 14:44:02 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MLi2Vt069120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 14:44:02 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5MLi2Qu069119; Fri, 22 Jun 2007 14:44:02 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from ca-server2.wavx.wavesys.com (ca-server2.wavx.wavesys.com [65.197.200.86] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MLi1pT069105 for ; Fri, 22 Jun 2007 14:44:01 -0700 (MST) (envelope-from thardjono@wavesys.com) 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" Subject: RE: Does the problem need solving? Date: Fri, 22 Jun 2007 14:44:17 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace0161U+L+KgaW/R46Vx0/fjmVPjwAPltmQ From: "Thomas Hardjono" To: "Stephen Kent" , "Jon Callas" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5MLi1pT069112 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ]> -----Original Message----- ]> From: owner-ietf-trust-anchor@mail.vpnc.org ]> [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of ]> Stephen Kent ]> Sent: Friday, June 22, 2007 6:50 AM ]> To: Jon Callas ]> Cc: ietf-trust-anchor@vpnc.org ]> Subject: Re: Does the problem need solving? ]> ]> ]> At 3:18 PM -0700 6/21/07, Jon Callas wrote: ]> >On Jun 21, 2007, at 2:44 PM, Thomas Hardjono wrote: ]> > ]> >> ]> >> ]> >>Maybe we need to agree on the definition of Trust Anchors ]> -- before we ]> >>can agree how to manage them :) ]> >> ]> > ]> >Hear, hear. The more we discuss this, the less I think we ]> have a decent ]> >definition on it. ]> > ]> > Jon ]> ]> As I noted earlier, I know of one PKI standard that uses ]> the term trust anchor, X.509, and so I interpret the ]> problem statement in that context. ]> ]> Informally, X.509 and PKIX define a trust anchor as a ]> public key, public key signature algorithm (plus parameters ]> that may be needed by the algorithm), the issuer name, and ]> other data used to initialize the path validation ]> algorithm. The other data may include values for extensions ]> that constrain path processing, e.g., name constraints, ]> policy constraints, IP address space and AS number constraints. ]> ]> Steve Agree, Steve. When I hear "TA" I immediately think X.509. I was thinking that this BOF/WG would (i) define a minimal X.509 TA (ie. one that is not over-burdened with so many extensions and policy-related information), and (ii) define a *protocol* to manage TA blobs (regardless of what the TA structure finally looks like). /thomas/ From owner-ietf-trust-anchor Fri Jun 22 14:40:11 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MLeBeW067898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2007 14:40:11 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5MLeBfQ067897; Fri, 22 Jun 2007 14:40:11 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from ca-server2.wavx.wavesys.com (ca-server2.wavx.wavesys.com [65.197.200.86] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5MLe8gO067875 for ; Fri, 22 Jun 2007 14:40:10 -0700 (MST) (envelope-from thardjono@wavesys.com) 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" Subject: RE: Enterprise-only or more... Date: Fri, 22 Jun 2007 14:40:22 -0700 Message-ID: In-Reply-To: <467BC102.5000004@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise-only or more... Thread-Index: Ace0ygJVF/cmRqcERGy3ztE7B6P6gwASvhyg From: "Thomas Hardjono" To: "Stephen Farrell" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5MLeAgO067891 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ]> -----Original Message----- ]> From: owner-ietf-trust-anchor@mail.vpnc.org ]> [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of ]> Stephen Farrell ]> Sent: Friday, June 22, 2007 5:31 AM ]> To: ietf-trust-anchor@vpnc.org ]> Subject: Enterprise-only or more... ]> ]> One question I'd like to see discussed is whether or not ]> this BoF should encompass other use cases, in particular, ]> things like Internet banking. I could imagine a case where ]> a bank would like to use client certs to authenticate ]> customers, which is currently difficult since it more or ]> less requires that the bank client-cert-root has to be in ]> the browser due to the way that TLS works. (Note: Its been ]> ages since I checked how current browsers handle ]> client-auth so things might have gotten a bit better there, ]> though if they have, I've not ]> noticed;-) ]> ]> The differences here in my mind are that the bank don't own ]> the client, and there's probably no sysadmin anywhere on ]> the client side that understands any of this stuff. I've no ]> real opinion as to whether such differences would result in ]> protocol changes or not, but at least in principle, they could. ]> ]> So, do we have people interested in that, or similar, use ]> cases, or are we really only going to try address our ]> problem for enterprises? ]> ]> There are of course in-between positions, e.g. "both are ]> interesting but only try solve for enterprises for now". If ]> a bunch of people did say that, then I think we would still ]> need to consider the topic at the BoF, e.g. so as to make ]> sure we're not creating something that's good for ]> enterprises, but not so good for the broader Internet. ]> ]> Cheers, ]> Stephen. Stephen, great example. I think TAs and TA management would be of great interest to the banking/finance industry. Better than this SiteKey thing that B-of-A forces us to use today :) Although the banking example could fall under the "consumer" space, in a sense it is an extension of the Enterprise case (with the consumer being a pseudo-employee under the jurisdiction of the Bank's domain when the user connects to the Bank). I guess the question becomes: would I be happy if my bank pushes-out a TA to my machine and manages that TA remotely (now and then). Or does the Bank need to trust me that I have installed the TA correctly (ps. can't see my Mum managing TAs). /thomas/ From owner-ietf-trust-anchor Sun Jun 24 07:32:37 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5OEWbgK053589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Jun 2007 07:32:37 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5OEWbUZ053588; Sun, 24 Jun 2007 07:32:37 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5OEWZv1053571 for ; Sun, 24 Jun 2007 07:32:36 -0700 (MST) (envelope-from mcr@marajade.sandelman.ca) Received: from sandelman.ottawa.on.ca (wlan196.sandelman.ca [205.150.200.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marajade.sandelman.ca.", Issuer "Michael Richardson" (verified OK)) by cod.sandelman.ca (Postfix) with ESMTP id BB34312386 for ; Sun, 24 Jun 2007 10:32:33 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id D76654E769 for ; Sun, 24 Jun 2007 10:32:27 -0400 (EDT) From: Michael Richardson To: ietf-trust-anchor@vpnc.org Subject: Re: Does the problem need solving? In-Reply-To: Message from "Thomas Hardjono" of "Thu, 21 Jun 2007 14:52:41 PDT." References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) Date: Sun, 24 Jun 2007 10:32:27 -0400 Message-ID: <30463.1182695547@marajade.sandelman.ca> Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Thomas" == Thomas Hardjono writes: Thomas> Furthermore, I think TA management needs to be IT-driven. Thomas> That is, the IT Admin person through the (remote) management Thomas> console needs to be the Well, you know that enterprises IT can already do this when they use the "One-true desktop" running the "One true browser" (IE). MS has provided enterprise customers with the ability to customize the distribution to desks, and that incldues TAs in IE. (gc.ca has such a distro, which includes the gc.ca TAs, but for bureaucratic reasons, they don't use it very often...) But, I would claim that the real problem is with smaller enterprises downtown to the single sophisticated user. - -- ] Bear: "Me, I'm just the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRn6AeoCLcPvd0N1lAQJ9AAf/ZsvNZIQVrJhBSdsTyIAGivyvuWLIppu9 ColuOOGWcPS8ethZStkt7rEx5I9OIzeA6vM40NO3gYJeOEWnY/Q9adV1bqONUTTj 97xZq66m4zzXociKvRr9sGs/oDu7pVoucyVxb2eJqgDfEIiFuOnwU2hQRZ1+ITmS gk4HL5+ElkFqz9bSg2f2QYianud78vL/5kNL6GdM6Z+HzaTsDEEKKrmZ93srH6Rc +0cThCjy0M4xEFjV3z4j+UH2GYTRTI6li1vz5JdMXbvNsF+EbtvyPun3D8Hw7ToN KNwXD5GI9W+0oZnKXQbLp6vvDHznqgaAGUm+CgHVQB4QroHvfT6KOw== =fDLh -----END PGP SIGNATURE----- From owner-ietf-trust-anchor Sun Jun 24 14:27:34 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5OLRYMB059727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Jun 2007 14:27:34 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5OLRYFc059726; Sun, 24 Jun 2007 14:27:34 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5OLRXKB059720 for ; Sun, 24 Jun 2007 14:27:34 -0700 (MST) (envelope-from jon@pgpeng.com) Received: from keys.pgpeng.com (keys.pgpeng.com [127.0.0.1]) by keys.pgpeng.com (PGP Universal) with ESMTP id 74094EFF18 for ; Sun, 24 Jun 2007 14:27:33 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Sun, 24 Jun 2007 14:27:33 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Sun, 24 Jun 2007 14:27:33 -0700 Received: from [63.251.255.74] (account jon HELO keys.pgpeng.com) by pgpeng.com (CommuniGate Pro SMTP 4.3.7) with ESMTPSA id 1839937 for ietf-trust-anchor@vpnc.org; Sun, 24 Jun 2007 14:27:33 -0700 Received: from [66.93.68.165] ([66.93.68.165]) by keys.pgpeng.com (PGP Universal service); Sun, 24 Jun 2007 14:27:33 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Sun, 24 Jun 2007 14:27:33 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D1D0D13@scygmxs1.cygnacom.com> References: <886F5D4C78AFB14D87261206BFB9612E1D1D0D13@scygmxs1.cygnacom.com> Message-Id: <383D3B20-4AB3-4605-99FA-7BFD199BB097@pgpeng.com> From: Jon Callas Subject: Re: Does the problem need solving? Date: Sun, 24 Jun 2007 14:27:34 -0700 To: ietf-trust-anchor@vpnc.org X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 22, 2007, at 4:44 AM, Carl Wallace wrote: > > Well, I'm asking what other people mean. I didn't write this > > draft, I'm trying to understand it. > > > > I think a root-of-all-roots, is not possible and opens up > > large numbers of intractable questions (which start with the > > previously mentioned p-word (policy) and get into others > > (like politics), so I hope this isn't what we're trying to solve. > > There's no universal root-of-all-roots notion intended in the > draft. All roots need not spring from the same place. However, as > Steve noted, for any particular trust store there may be a set of > trust anchors authorized to manage the contents of the trust > store. To some extent, the set of TAs authorized to manage a trust > store could be viewed as the roots-of-all-roots for that trust store. > > In general, the idea is that there must be at least one trust > anchor that is installed in any TA store for which trust is > established using manual, out-of-band means. After this occurs, in- > band management should be possible. Establishing a protocol to do > this is the primary goal. Deciding on the trust anchor types to > manage, extent of authorization to address, etc. is part of the > scoping exercise. > Thank you Carl and Steve (I'm replying to Carl, but thanks go mostly to Steve) for helping me understand this. I now see that this is actually the *antithesis* of what I was erroneously thinking. I think this is solves a problem that needs solving. I still want to see a way that we handle things other then X.509, and would like to see XML wrappers as well, because like XML or not, it's the way things are in much of the world. Jon -- Jon Callas CTO, CSO PGP Corporation Tel: +1 (650) 319-9016 3460 West Bayshore Fax: +1 (650) 319-9001 Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3 USA 28b6 52bf 5a46 bc98 e63d From owner-ietf-trust-anchor Mon Jun 25 07:01:19 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5PE1Jg0060498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jun 2007 07:01:19 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5PE1JGl060497; Mon, 25 Jun 2007 07:01:19 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5PE1IXL060491 for ; Mon, 25 Jun 2007 07:01:19 -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 1I2p82-0003vc-3f; Mon, 25 Jun 2007 10:01:18 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 25 Jun 2007 10:01:23 -0400 To: "Thomas Hardjono" From: Stephen Kent Subject: RE: Does the problem need solving? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:44 PM -0700 6/22/07, Thomas Hardjono wrote: > > >... > >Agree, Steve. When I hear "TA" I immediately think X.509. I was >thinking that this BOF/WG would (i) define a minimal X.509 TA (ie. one >that is not over-burdened with so many extensions and policy-related >information), and (ii) define a *protocol* to manage TA blobs >(regardless of what the TA structure finally looks like). > >/thomas/ I think we do need to include support in a TA for name constraints, to address the sort of problem that Henry Hotz raised. I am less enthusiastic about the policy mapping stuff, but I could be convinced otherwise if enough folks say that the policy extension is, pardon the pun, critical for them. Steve From owner-ietf-trust-anchor Mon Jun 25 15:35:21 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5PMZLsb049375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jun 2007 15:35:21 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5PMZLlR049371; Mon, 25 Jun 2007 15:35:21 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mailbox.reptiles.org (mail.reptiles.org [198.96.210.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5PMZKDC049351; Mon, 25 Jun 2007 15:35:20 -0700 (MST) (envelope-from cat@reptiles.org) Received: from mail.reptiles.org ([198.96.210.227] port=65480) by mailbox.reptiles.org([198.96.210.227] port=25) via TCP with esmtp (2318 bytes) (sender: ) (ident using UNIX) id for ; Mon, 25 Jun 2007 18:35:17 -0400 (EDT) (Smail-3.2.0.121 2005-Nov-17 #4 built 2006-Nov-28) Date: Mon, 25 Jun 2007 18:35:16 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@gecko.reptiles.org Reply-To: Cat Okita To: Paul Hoffman cc: ietf-trust-anchor@vpnc.org Subject: Re: Does the problem need solving? In-Reply-To: Message-ID: <20070625183045.W37986@gecko.reptiles.org> References: <20070615210637.GA25975@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 19 Jun 2007, Paul Hoffman wrote: > Even though we have gone well over a decade without an interoperable > solution, I think we got here mostly through applied denial and kludges. One > result of that has been that organizational users of PKI are stuck with > having to live with the trust decisions made by their OS vendors, their > applications vendors, or both. Another is that people have been trained to > click through the "this cert is not signed by a trusted root" dialog because > it is too hard for an enterprise to push their desired trust anchors to their > employees. Given that most users already click through the "THIS IS UNSAFE" popup boxes from their myriad applications, do we actually believe that this work will have any effect at all on the trained end-user? I'm certainly willing to believe that this may make the administrator's job different - but I'm having a hard time stretching to the belief that the end-user is going to change (or possibly even notice) whether their trust decisions involve one TA, many TAs, valid TAs, invalid TAs. cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From owner-ietf-trust-anchor Mon Jun 25 17:03:37 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5Q03ajt072338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jun 2007 17:03:36 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5Q03a9o072337; Mon, 25 Jun 2007 17:03:36 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5Q03Z0p072327 for ; Mon, 25 Jun 2007 17:03:36 -0700 (MST) (envelope-from chokhani@orionsec.com) 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" Subject: RE: Does the problem need solving? Date: Mon, 25 Jun 2007 17:02:49 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace3MovAqvxvPpp9QpGwFA1GdpMVCAALYuOA References: From: "Santosh Chokhani" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5Q03a0p072332 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steve, In addition to name constraints, we should permit to associate policy related extensions to constrain a TA. Here is the rationale: Certificate policies will be used if a relying party does not want to trust a trust anchor for all the policies trust anchor operates under. Policy mapping will be used when the relying party acceptable policy set does not include a TA domain (oops) policy set. The relying party will need to map its policies to TA domain policies. The relying party could simply use the policies from the TA domain if the relying party is using that single TA for the application. But, when more than one TA are used by a single application and some of the TAs have different policies, this facility is useful. The relying party could take the union of the policies used by the various TAs as its acceptable policy set, but the policy mapping approach is cleaner and more flexible. Inhibit policy mapping will be used when the relying party wants to permit some TAs, but not all TAs to map policies to other domains. Naturally, this is only needed if TAs cross certify with other domains and the application wants to accept some cross certifications and not others. In summary, certificate policies should be required. Policy mapping and policy constraints one could do without; its feature and complexity trade-off. -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen Kent Sent: Monday, June 25, 2007 10:01 AM To: Thomas Hardjono Cc: ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? At 2:44 PM -0700 6/22/07, Thomas Hardjono wrote: > > >... > >Agree, Steve. When I hear "TA" I immediately think X.509. I was >thinking that this BOF/WG would (i) define a minimal X.509 TA (ie. one >that is not over-burdened with so many extensions and policy-related >information), and (ii) define a *protocol* to manage TA blobs >(regardless of what the TA structure finally looks like). > >/thomas/ I think we do need to include support in a TA for name constraints, to address the sort of problem that Henry Hotz raised. I am less enthusiastic about the policy mapping stuff, but I could be convinced otherwise if enough folks say that the policy extension is, pardon the pun, critical for them. Steve From owner-ietf-trust-anchor Tue Jun 26 06:57:53 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QDvrrS030866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 06:57:53 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QDvr7p030865; Tue, 26 Jun 2007 06:57:53 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QDvntS030840 for ; Tue, 26 Jun 2007 06:57:52 -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 1I3BYC-0003bc-3E; Tue, 26 Jun 2007 09:57:48 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> Date: Tue, 26 Jun 2007 09:25:40 -0400 To: "Santosh Chokhani" From: Stephen Kent Subject: RE: Does the problem need solving? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 5:02 PM -0700 6/25/07, Santosh Chokhani wrote: >Steve, > >In addition to name constraints, we should permit to associate policy >related extensions to constrain a TA. Here is the rationale: > >Certificate policies will be used if a relying party does not want to >trust a trust anchor for all the policies trust anchor operates under. > >Policy mapping will be used when the relying party acceptable policy set >does not include a TA domain (oops) policy set. The relying party will >need to map its policies to TA domain policies. The relying party could >simply use the policies from the TA domain if the relying party is using >that single TA for the application. But, when more than one TA are used >by a single application and some of the TAs have different policies, >this facility is useful. The relying party could take the union of the >policies used by the various TAs as its acceptable policy set, but the >policy mapping approach is cleaner and more flexible. > >Inhibit policy mapping will be used when the relying party wants to >permit some TAs, but not all TAs to map policies to other domains. >Naturally, this is only needed if TAs cross certify with other domains >and the application wants to accept some cross certifications and not >others. > >In summary, certificate policies should be required. Policy mapping and >policy constraints one could do without; its feature and complexity >trade-off. > Good argument. I agree that policy support, but not policy mapping or constraints, makes sense here too. Steve From owner-ietf-trust-anchor Tue Jun 26 07:21:42 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QELgvT035161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 07:21:42 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QELfwi035160; Tue, 26 Jun 2007 07:21:42 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QELfQq035147; Tue, 26 Jun 2007 07:21:41 -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 1I3BvG-0003zM-5V; Tue, 26 Jun 2007 10:21:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070625183045.W37986@gecko.reptiles.org> References: <20070615210637.GA25975@vacation.karoshi.com.> <20070625183045.W37986@gecko.reptiles.org> Date: Tue, 26 Jun 2007 10:21:33 -0400 To: Cat Okita From: Stephen Kent Subject: Re: Does the problem need solving? Cc: Paul Hoffman , ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 6:35 PM -0400 6/25/07, Cat Okita wrote: >On Tue, 19 Jun 2007, Paul Hoffman wrote: >>Even though we have gone well over a decade without an >>interoperable solution, I think we got here mostly through applied >>denial and kludges. One result of that has been that organizational >>users of PKI are stuck with having to live with the trust decisions >>made by their OS vendors, their applications vendors, or both. >>Another is that people have been trained to click through the "this >>cert is not signed by a trusted root" dialog because it is too hard >>for an enterprise to push their desired trust anchors to their >>employees. > >Given that most users already click through the "THIS IS UNSAFE" popup >boxes from their myriad applications, do we actually believe that this >work will have any effect at all on the trained end-user? > >I'm certainly willing to believe that this may make the administrator's >job different - but I'm having a hard time stretching to the belief that >the end-user is going to change (or possibly even notice) whether >their trust decisions involve one TA, many TAs, valid TAs, invalid >TAs. > >cheers! I agree that the work being proposed will not magically change user behavior. The real target for this work is "local" administrators and vendors, not typical end users. but that's and OK focus for an IETF activity, e.g., MIBs! Steve From owner-ietf-trust-anchor Tue Jun 26 07:30:34 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QEUTjN036332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 07:30:34 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QEUTGR036331; Tue, 26 Jun 2007 07:30:29 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5QEUQ6s036311 for ; Tue, 26 Jun 2007 07:30:27 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: (qmail 9090 invoked from network); 26 Jun 2007 14:30:23 -0000 Received: from sharon.boeyen@entrust.com by sottccs1.entrust.com with EntrustECS-Server-8.0;26 Jun 2007 14:30:23 -0000 Received: from sottexch1.corp.ad.entrust.com (10.4.51.28) by sottccs1.entrust.com with SMTP; 26 Jun 2007 14:30:22 -0000 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" Subject: RE: Does the problem need solving? Date: Tue, 26 Jun 2007 10:30:24 -0400 Message-ID: <04398A2C9F306C4690265C144089972D01BE759C@sottexch1.corp.ad.entrust.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace3+ku/kVaXM3xHSeiN6kmeZDKbEgAA/nVg References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> From: "Sharon Boeyen" To: "Stephen Kent" , "Santosh Chokhani" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5QEUS6s036316 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I do want to be sure that we aren't tying all the policy stuff too tightly to a key. I want to ensure that we retain the ability to associate a number of various combinations of these settings with the same key - whether that means these are now called different trust anchors (and there would be multiple TAs for the same key in that case) or whether the policy stuff is in a separate construct that can be combined with any given trusted key for a specific application. -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen Kent Sent: Tuesday, June 26, 2007 9:26 AM To: Santosh Chokhani Cc: ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? At 5:02 PM -0700 6/25/07, Santosh Chokhani wrote: >Steve, > >In addition to name constraints, we should permit to associate policy >related extensions to constrain a TA. Here is the rationale: > >Certificate policies will be used if a relying party does not want to >trust a trust anchor for all the policies trust anchor operates under. > >Policy mapping will be used when the relying party acceptable policy >set does not include a TA domain (oops) policy set. The relying party >will need to map its policies to TA domain policies. The relying party >could simply use the policies from the TA domain if the relying party >is using that single TA for the application. But, when more than one >TA are used by a single application and some of the TAs have different >policies, this facility is useful. The relying party could take the >union of the policies used by the various TAs as its acceptable policy >set, but the policy mapping approach is cleaner and more flexible. > >Inhibit policy mapping will be used when the relying party wants to >permit some TAs, but not all TAs to map policies to other domains. >Naturally, this is only needed if TAs cross certify with other domains >and the application wants to accept some cross certifications and not >others. > >In summary, certificate policies should be required. Policy mapping >and policy constraints one could do without; its feature and complexity >trade-off. > Good argument. I agree that policy support, but not policy mapping or constraints, makes sense here too. Steve From owner-ietf-trust-anchor Tue Jun 26 07:50:30 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QEoUxo039346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 07:50:30 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QEoTM5039345; Tue, 26 Jun 2007 07:50:29 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QEoTg6039339 for ; Tue, 26 Jun 2007 07:50:29 -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 1I3CNA-0004PK-5K; Tue, 26 Jun 2007 10:50:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <04398A2C9F306C4690265C144089972D01BE759C@sottexch1.corp.ad.entrust.com> References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE759C@sottexch1.corp.ad.entrust.com> Date: Tue, 26 Jun 2007 10:50:28 -0400 To: "Sharon Boeyen" From: Stephen Kent Subject: RE: Does the problem need solving? Cc: "Santosh Chokhani" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:30 AM -0400 6/26/07, Sharon Boeyen wrote: >I do want to be sure that we aren't tying all the policy stuff too >tightly to a key. I want to ensure that we retain the ability to >associate a number of various combinations of these settings with the >same key - whether that means these are now called different trust >anchors (and there would be multiple TAs for the same key in that case) >or whether the policy stuff is in a separate construct that can be >combined with any given trusted key for a specific application. > I think a TA needs to supply all of the data that we use to initialize path validation, at least in the X.509/PKIX context. Policy info represents some of this data. Your observation above provides one simple way to accommodate the separation of policy data from keys, i.e., bind the same key into multiple TAs, each with different policy data. Steve From owner-ietf-trust-anchor Tue Jun 26 08:01:19 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QF1Jus040984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 08:01:19 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QF1J7T040981; Tue, 26 Jun 2007 08:01:19 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mailbox.reptiles.org (mail.reptiles.org [198.96.210.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QF1I5D040968; Tue, 26 Jun 2007 08:01:18 -0700 (MST) (envelope-from cat@reptiles.org) Received: from mail.reptiles.org ([198.96.210.227] port=58472) by mailbox.reptiles.org([198.96.210.227] port=25) via TCP with esmtp (2391 bytes) (sender: ) (ident using UNIX) id for ; Tue, 26 Jun 2007 11:01:08 -0400 (EDT) (Smail-3.2.0.121 2005-Nov-17 #4 built 2006-Nov-28) Date: Tue, 26 Jun 2007 11:01:06 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@gecko.reptiles.org Reply-To: Cat Okita To: Stephen Kent cc: Cat Okita , Paul Hoffman , ietf-trust-anchor@vpnc.org Subject: Re: Does the problem need solving? In-Reply-To: Message-ID: <20070626105542.Y37986@gecko.reptiles.org> References: <20070615210637.GA25975@vacation.karoshi.com.> <20070625183045.W37986@gecko.reptiles.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 26 Jun 2007, Stephen Kent wrote: > I agree that the work being proposed will not magically change user behavior. > The real target for this work is "local" administrators and vendors, not > typical end users. but that's and OK focus for an IETF activity, e.g., MIBs! I'm not sure if anybody else here remembers the monitoring BoF that the relevant IETF group had at LISA around 2000/1 - but the brief summary would be that the administrators were universally of the opinion that MIBs were an abomination, and frustrating and annoying to deal with on a -good- day. It would be deeply unfortunate to promote similar feelings around this work, which is guaranteed if simplicity and clean design aren't part of the goals here. Perhaps one of the questions should be not only "What problem are we solving", but "Will we create more problems than we solve" (and a spec that's hard to understand/implement/maintain is a guarantee of more problems down the line). cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From owner-ietf-trust-anchor Tue Jun 26 08:51:12 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QFpCwI048479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 08:51:12 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QFpCHc048478; Tue, 26 Jun 2007 08:51:12 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from smtp.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QFpBLY048471 for ; Tue, 26 Jun 2007 08:51:12 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id 1D0DC3D71; Tue, 26 Jun 2007 16:51:10 +0100 (IST) X-Virus-Scanned: amavisd-new at cs.tcd.ie Received: from smtp.cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw57AmikBf98; Tue, 26 Jun 2007 16:51:08 +0100 (IST) Received: from webmail.cs.tcd.ie (wilde.cs.tcd.ie [IPv6:2001:770:10:200:203:baff:fe96:d2b3]) by smtp.cs.tcd.ie (Postfix) with ESMTP id CD30C3D0D; Tue, 26 Jun 2007 16:51:03 +0100 (IST) Received: from 81.241.242.2 (SquirrelMail authenticated user sfarrel6) by webmail.cs.tcd.ie with HTTP; Tue, 26 Jun 2007 16:51:08 +0100 (IST) Message-ID: <2756.81.241.242.2.1182873068.squirrel@webmail.cs.tcd.ie> In-Reply-To: References: <20070615210637.GA25975@vacation.karoshi.com.> <20070625183045.W37986@gecko.reptiles.org> Date: Tue, 26 Jun 2007 16:51:08 +0100 (IST) Subject: Re: Does the problem need solving? From: stephen.farrell@cs.tcd.ie To: "Stephen Kent" Cc: "Cat Okita" , ietf-trust-anchor@vpnc.org Reply-To: stephen.farrell@cs.tcd.ie User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > At 6:35 PM -0400 6/25/07, Cat Okita wrote: >>On Tue, 19 Jun 2007, Paul Hoffman wrote: >>>Even though we have gone well over a decade without an >>>interoperable solution, I think we got here mostly through applied >>>denial and kludges. One result of that has been that organizational >>>users of PKI are stuck with having to live with the trust decisions >>>made by their OS vendors, their applications vendors, or both. >>>Another is that people have been trained to click through the "this >>>cert is not signed by a trusted root" dialog because it is too hard >>>for an enterprise to push their desired trust anchors to their >>>employees. >> >>Given that most users already click through the "THIS IS UNSAFE" popup >>boxes from their myriad applications, do we actually believe that this >>work will have any effect at all on the trained end-user? >> >>I'm certainly willing to believe that this may make the administrator's >>job different - but I'm having a hard time stretching to the belief that >>the end-user is going to change (or possibly even notice) whether >>their trust decisions involve one TA, many TAs, valid TAs, invalid >>TAs. >> >>cheers! > > I agree that the work being proposed will not magically change user > behavior. The real target for this work is "local" administrators and > vendors, not typical end users. but that's and OK focus for an IETF > activity, e.g., MIBs! I agree with you both. I've not (so far anyway) seen much support on this list for the typical end user as a target. There's also a relevant W3C activity that's trying to improve the security UI for browsers [1], so the putative protocol we're having the BoF for, might, or might not, be useful there. (Though the W3C group are much more concerned with nearer-term issues, so they probably won't pay too much attention to this work just yet.) S. [1] http://www.w3.org/2006/WSC/ From owner-ietf-trust-anchor Tue Jun 26 10:19:36 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QHJaoD066886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 10:19:36 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QHJZxa066885; Tue, 26 Jun 2007 10:19:35 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QHJY4E066878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jun 2007 10:19:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 26 Jun 2007 10:19:14 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Requirement: messages, not interactive protocol Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In reading some of the earlier messages on this list, I think that some people are picturing the protocol as interactive (such as client-server). I have a requirement that it *not* be interactive so that a TA administrator can, for example, email the set of trust anchors to users, or give them the trust anchors on a USB fob, and so on. It's fine if we also describe a simple interactive protocol for passing those messages around, but the core protocol needs to be stand-alone messages in order to be useful in many environments. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jun 26 11:11:07 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QIB7oY082133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 11:11:07 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QIB7xo082132; Tue, 26 Jun 2007 11:11:07 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5QIB5sv082110 for ; Tue, 26 Jun 2007 11:11:05 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 61402 invoked from network); 26 Jun 2007 18:11:01 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.43.187 with login) by smtp101.biz.mail.re2.yahoo.com with SMTP; 26 Jun 2007 18:11:01 -0000 X-YMail-OSG: UlfrKVoVM1mCJ9vn9NJgPQfjVmqPUu_xshSoSTOsDG_20JVrJLeQEF6U5fJgiEgl0soQyJRncA-- Reply-To: From: "Turner, Sean P." To: "'Paul Hoffman'" , References: Subject: RE: Requirement: messages, not interactive protocol Date: Tue, 26 Jun 2007 14:02:48 -0400 Organization: IECA, Inc. Message-ID: <001f01c7b81c$34a25f40$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ace4FmeVtqOeEtm4Q/q5SpvCtMZAaQABa0Kw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul, I wouldn't say interactive meant real-time. If it supports store-and-forward I think it can still be a query request type protocol. sot -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul Hoffman Sent: Tuesday, June 26, 2007 1:19 PM To: ietf-trust-anchor@vpnc.org Subject: Requirement: messages, not interactive protocol In reading some of the earlier messages on this list, I think that some people are picturing the protocol as interactive (such as client-server). I have a requirement that it *not* be interactive so that a TA administrator can, for example, email the set of trust anchors to users, or give them the trust anchors on a USB fob, and so on. It's fine if we also describe a simple interactive protocol for passing those messages around, but the core protocol needs to be stand-alone messages in order to be useful in many environments. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jun 26 12:01:45 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QJ1jb1095427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 12:01:45 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QJ1j1Q095426; Tue, 26 Jun 2007 12:01:45 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QJ1ivf095413; Tue, 26 Jun 2007 12:01:45 -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 1I3GIJ-00080v-51; Tue, 26 Jun 2007 15:01:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070626105542.Y37986@gecko.reptiles.org> References: <20070615210637.GA25975@vacation.karoshi.com.> <20070625183045.W37986@gecko.reptiles.org> <20070626105542.Y37986@gecko.reptiles.org> Date: Tue, 26 Jun 2007 12:24:53 -0400 To: Cat Okita From: Stephen Kent Subject: Re: Does the problem need solving? Cc: Cat Okita , Paul Hoffman , ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:01 AM -0400 6/26/07, Cat Okita wrote: >On Tue, 26 Jun 2007, Stephen Kent wrote: >>I agree that the work being proposed will not magically change user >>behavior. The real target for this work is "local" administrators >>and vendors, not typical end users. but that's and OK focus for an >>IETF activity, e.g., MIBs! > >I'm not sure if anybody else here remembers the monitoring BoF that the >relevant IETF group had at LISA around 2000/1 - but the brief summary >would be that the administrators were universally of the opinion that >MIBs were an abomination, and frustrating and annoying to deal with on >a -good- day. > Last time I checked, the IESG still pushes for MIBs for new protocols, so I'm afraid the lesson you cited above has not been internalized :-). Despite what may have been a poor choice of analogy on my part, I still maintain that the IETF does view development of protocols for management as important and thus a trust anchor management protocol is within scope. Steve From owner-ietf-trust-anchor Tue Jun 26 12:04:30 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QJ4Uwl095870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 12:04:30 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QJ4UWZ095867; Tue, 26 Jun 2007 12:04:30 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QJ4Pau095814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 12:04:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <001f01c7b81c$34a25f40$0301a8c0@Wylie> References: <001f01c7b81c$34a25f40$0301a8c0@Wylie> Date: Tue, 26 Jun 2007 12:04:04 -0700 To: , From: Paul Hoffman Subject: RE: Requirement: messages, not interactive protocol Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:02 PM -0400 6/26/07, Turner, Sean P. wrote: >I wouldn't say interactive meant real-time. But I did. :-) >If it supports >store-and-forward I think it can still be a query request type protocol. Fully agree. For example, there might be a query that says "please refresh my TA list" and a response that says "here is a full TA list", but those should not have to be interactive/real-time: they can be in store-and-forward. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jun 26 12:40:35 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QJeZmJ005929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 12:40:35 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QJeZYE005928; Tue, 26 Jun 2007 12:40:35 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QJeWeW005869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 12:40:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <467BC102.5000004@cs.tcd.ie> References: <467BC102.5000004@cs.tcd.ie> Date: Tue, 26 Jun 2007 12:40:11 -0700 To: Stephen Farrell , ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Re: Enterprise-only or more... Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:30 PM +0100 6/22/07, Stephen Farrell wrote: >One question I'd like to see discussed is whether or not this BoF >should encompass other use cases, in particular, things like Internet >banking. I could imagine a case where a bank would like to use client >certs to authenticate customers, which is currently difficult since >it more or less requires that the bank client-cert-root has to be in >the browser due to the way that TLS works. (Note: Its been ages >since I checked how current browsers handle client-auth so things >might have gotten a bit better there, though if they have, I've not >noticed;-) > >The differences here in my mind are that the bank don't own the >client, and there's probably no sysadmin anywhere on the client >side that understands any of this stuff. I've no real opinion as >to whether such differences would result in protocol changes or >not, but at least in principle, they could. > >So, do we have people interested in that, or similar, use cases, >or are we really only going to try address our problem for >enterprises? If there is one TA admin, and that person is someone other than me, then your model does not work. That is, the bank needs to get the single TA admin to bless the bank's TA. If there is more than one TA admin (say, a real TA admin plus the user controlling the application), then the bank only needs to convince one of the (probably the user) to install the bank's TA. I think a reasonable requirement is that the protocol allow the client to specify more than one TA admins. If that requirement is met, a system where the user really does control the system can simply name the user as a TA admin. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jun 26 12:57:27 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QJvRO5010377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 12:57:27 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QJvRXP010376; Tue, 26 Jun 2007 12:57:27 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QJvPLk010352; Tue, 26 Jun 2007 12:57:26 -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 1I3HAC-0000TZ-6N; Tue, 26 Jun 2007 15:57:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <467BC102.5000004@cs.tcd.ie> Date: Tue, 26 Jun 2007 15:57:28 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: Enterprise-only or more... Cc: Stephen Farrell , ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:40 PM -0700 6/26/07, Paul Hoffman wrote: >At 1:30 PM +0100 6/22/07, Stephen Farrell wrote: >>... > >If there is one TA admin, and that person is someone other than me, >then your model does not work. That is, the bank needs to get the >single TA admin to bless the bank's TA. > >If there is more than one TA admin (say, a real TA admin plus the >user controlling the application), then the bank only needs to >convince one of the (probably the user) to install the bank's TA. > >I think a reasonable requirement is that the protocol allow the >client to specify more than one TA admins. If that requirement is >met, a system where the user really does control the system can >simply name the user as a TA admin. There are multiple reasonable models. For example, a device may be "owned" by a vendor who delegates to a user or local admin the authority to install TAs with certain scope, but not all TAs. This might be a model for desk top boxes or cell phones. In an enterprise context, a local admin may want a similar capability for himself, delegating some control to individual users, but retaining ultimate control over TA management for a desktop or laptop. Steve From owner-ietf-trust-anchor Tue Jun 26 15:02:15 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QM2F7c044385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 15:02:15 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QM2FnH044384; Tue, 26 Jun 2007 15:02:15 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from ca-server2.wavx.wavesys.com (ca-server2.wavx.wavesys.com [65.197.200.86] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QM2D30044361; Tue, 26 Jun 2007 15:02:13 -0700 (MST) (envelope-from thardjono@wavesys.com) 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" Subject: RE: Enterprise-only or more... Date: Tue, 26 Jun 2007 15:02:29 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise-only or more... Thread-Index: Ace4LOCnWo+Ufun7SDSBsW9Du4HjqQAD6Kaw From: "Thomas Hardjono" To: "Stephen Kent" , "Paul Hoffman" Cc: "Stephen Farrell" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5QM2E30044363 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen Kent Sent: Tuesday, June 26, 2007 12:57 PM To: Paul Hoffman Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org Subject: Re: Enterprise-only or more... At 12:40 PM -0700 6/26/07, Paul Hoffman wrote: >At 1:30 PM +0100 6/22/07, Stephen Farrell wrote: >>... > >If there is one TA admin, and that person is someone other than me, >then your model does not work. That is, the bank needs to get the >single TA admin to bless the bank's TA. > >If there is more than one TA admin (say, a real TA admin plus the user >controlling the application), then the bank only needs to convince one >of the (probably the user) to install the bank's TA. > >I think a reasonable requirement is that the protocol allow the client >to specify more than one TA admins. If that requirement is met, a >system where the user really does control the system can simply name >the user as a TA admin. There are multiple reasonable models. For example, a device may be "owned" by a vendor who delegates to a user or local admin the authority to install TAs with certain scope, but not all TAs. This might be a model for desk top boxes or cell phones. In an enterprise context, a local admin may want a similar capability for himself, delegating some control to individual users, but retaining ultimate control over TA management for a desktop or laptop. Steve Seems to me that we could have several issues/aspects pertaining to TAs: (1) Definition of a TA (ie. structure, syntax, semantics) (2) Protocol(s) to "manage" TAs (and definition/scope of what we mean by the term "manage") (3) Authorization model (ie. authorization to manage TAs) (4) Delegation model (i.e. authority-over-TA now delegates portions of authority or entire authority) (5) Others... The scope of the BOF/WG can easily become very wide, which is why I was suggesting that the Enterprise use-case may be more manageable :) /thomas/ From owner-ietf-trust-anchor Tue Jun 26 15:59:04 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QMx3ro062971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 15:59:04 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QMx3VW062970; Tue, 26 Jun 2007 15:59:03 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QMwa8W062828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 15:58:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 26 Jun 2007 15:58:14 -0700 To: "Thomas Hardjono" , "Stephen Kent" From: Paul Hoffman Subject: RE: Enterprise-only or more... Cc: "Stephen Farrell" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:02 PM -0700 6/26/07, Thomas Hardjono wrote: >Seems to me that we could have several issues/aspects pertaining to TAs: > >(1) Definition of a TA (ie. structure, syntax, semantics) >(2) Protocol(s) to "manage" TAs (and definition/scope of what we mean by >the term "manage") >(3) Authorization model (ie. authorization to manage TAs) >(4) Delegation model (i.e. authority-over-TA now delegates portions of >authority or entire authority) >(5) Others... > >The scope of the BOF/WG can easily become very wide, which is why I was >suggesting that the Enterprise use-case may be more manageable :) Fully disagree. #1 is obviously needed but quite tractable. #2 is our prime deliverable. #1 should be the introduction to #2. #3 seems like the kind of rathole that the IETF finds quite easily. #4 is just further down the hole. A simple way to avoid both of them, that hits the 90/10 rule just fine, is "end entities inherently trust TA admins, and no one else, to add and remove TAs from specified applications". Done. We only need to think about #5 when #1/2 is done, and only then if there is a business case for extensions and so on. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jun 26 16:29:45 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QNTjN9073119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 16:29:45 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5QNTjiF073118; Tue, 26 Jun 2007 16:29:45 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from ca-server2.wavx.wavesys.com (ca-server2.wavx.wavesys.com [65.197.200.86] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5QNTiYf073103; Tue, 26 Jun 2007 16:29:44 -0700 (MST) (envelope-from thardjono@wavesys.com) 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" Subject: RE: Enterprise-only or more... Date: Tue, 26 Jun 2007 16:30:01 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise-only or more... Thread-Index: Ace4RaRgiVdxwom4SnW9d2CicalvRAABCKew From: "Thomas Hardjono" To: "Paul Hoffman" , "Stephen Kent" Cc: "Stephen Farrell" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5QNTiYf073105 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Tuesday, June 26, 2007 3:58 PM > To: Thomas Hardjono; Stephen Kent > Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org > Subject: RE: Enterprise-only or more... > > At 3:02 PM -0700 6/26/07, Thomas Hardjono wrote: > >Seems to me that we could have several issues/aspects > pertaining to TAs: > > > >(1) Definition of a TA (ie. structure, syntax, semantics) > >(2) Protocol(s) to "manage" TAs (and definition/scope of > what we mean > >by the term "manage") > >(3) Authorization model (ie. authorization to manage TAs) > >(4) Delegation model (i.e. authority-over-TA now delegates > portions of > >authority or entire authority) > >(5) Others... > > > >The scope of the BOF/WG can easily become very wide, which > is why I was > >suggesting that the Enterprise use-case may be more manageable :) > > Fully disagree. #1 is obviously needed but quite tractable. > #2 is our prime deliverable. #1 should be the introduction to #2. > > #3 seems like the kind of rathole that the IETF finds quite easily. > #4 is just further down the hole. A simple way to avoid both > of them, that hits the 90/10 rule just fine, is "end entities > inherently trust TA admins, and no one else, to add and > remove TAs from specified applications". Done. > > We only need to think about #5 when #1/2 is done, and only > then if there is a business case for extensions and so on. > > --Paul Hoffman, Director > --VPN Consortium > Thanks Paul. I was hoping you would fully disagree :) cheers, /thomas/ From owner-ietf-trust-anchor Wed Jun 27 06:41:31 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5RDfUv9013423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 06:41:30 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5RDfU2d013422; Wed, 27 Jun 2007 06:41:30 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5RDfTmi013408 for ; Wed, 27 Jun 2007 06:41:29 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 73698 invoked from network); 27 Jun 2007 13:41:29 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.40.231 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 27 Jun 2007 13:41:28 -0000 X-YMail-OSG: WrCRj0QVM1lZ7Tx49bG649MunfMFVAbEPfMrDJYKvu0WX6B9VU4_Q5ev4fBdmn3Suz5FFOokLg-- Reply-To: From: "Turner, Sean P." To: "'Paul Hoffman'" , "'Thomas Hardjono'" , "'Stephen Kent'" Cc: "'Stephen Farrell'" , References: Subject: RE: Enterprise-only or more... Date: Wed, 27 Jun 2007 09:33:12 -0400 Organization: IECA, Inc. Message-ID: <00c601c7b8bf$b5d66720$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace4RcfwkgagMm88Twuacgluj3CxtAAedgiA Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'd like to not completely give up on #3/4 but doing #1/2 should 1st order of business. spt -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul Hoffman Sent: Tuesday, June 26, 2007 6:58 PM To: Thomas Hardjono; Stephen Kent Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org Subject: RE: Enterprise-only or more... At 3:02 PM -0700 6/26/07, Thomas Hardjono wrote: >Seems to me that we could have several issues/aspects pertaining to TAs: > >(1) Definition of a TA (ie. structure, syntax, semantics) >(2) Protocol(s) to "manage" TAs (and definition/scope of what we mean >by the term "manage") >(3) Authorization model (ie. authorization to manage TAs) >(4) Delegation model (i.e. authority-over-TA now delegates portions of >authority or entire authority) >(5) Others... > >The scope of the BOF/WG can easily become very wide, which is why I was >suggesting that the Enterprise use-case may be more manageable :) Fully disagree. #1 is obviously needed but quite tractable. #2 is our prime deliverable. #1 should be the introduction to #2. #3 seems like the kind of rathole that the IETF finds quite easily. #4 is just further down the hole. A simple way to avoid both of them, that hits the 90/10 rule just fine, is "end entities inherently trust TA admins, and no one else, to add and remove TAs from specified applications". Done. We only need to think about #5 when #1/2 is done, and only then if there is a business case for extensions and so on. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Wed Jun 27 07:33:59 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5REXwS1018821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 07:33:58 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5REXwsl018820; Wed, 27 Jun 2007 07:33:58 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5REXvZ6018809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Jun 2007 07:33:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <00c601c7b8bf$b5d66720$0301a8c0@Wylie> References: <00c601c7b8bf$b5d66720$0301a8c0@Wylie> Date: Wed, 27 Jun 2007 07:32:37 -0700 To: From: Paul Hoffman Subject: RE: Enterprise-only or more... Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: So, now we're in charter discussions. I would like to not even talk about #3 or #4 for the initial charter. At the end of the work on #1 and #2, those who want to do #3 and #4 can ask for a re-charter. Unless we make the main work un-extendable (which we won't), those later tasks should not need any thought during the initial work. It would nice to, just for once, have a security WG that finishes its main work before delving into ratholes. --Paul Hoffman At 9:33 AM -0400 6/27/07, Turner, Sean P. wrote: >I'd like to not completely give up on #3/4 but doing #1/2 should 1st order >of business. > >spt > >-----Original Message----- >From: owner-ietf-trust-anchor@mail.vpnc.org >[mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul Hoffman >Sent: Tuesday, June 26, 2007 6:58 PM >To: Thomas Hardjono; Stephen Kent >Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org >Subject: RE: Enterprise-only or more... > > >At 3:02 PM -0700 6/26/07, Thomas Hardjono wrote: >>Seems to me that we could have several issues/aspects pertaining to TAs: >> >>(1) Definition of a TA (ie. structure, syntax, semantics) >>(2) Protocol(s) to "manage" TAs (and definition/scope of what we mean >>by the term "manage") >>(3) Authorization model (ie. authorization to manage TAs) >>(4) Delegation model (i.e. authority-over-TA now delegates portions of >>authority or entire authority) > >(5) Others... From owner-ietf-trust-anchor Wed Jun 27 08:18:03 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5RFI3L1024160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 08:18:03 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5RFI3CJ024159; Wed, 27 Jun 2007 08:18:03 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5RFI1A6024143 for ; Wed, 27 Jun 2007 08:18:02 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 75216 invoked from network); 27 Jun 2007 15:17:57 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.33.73 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 27 Jun 2007 15:17:57 -0000 X-YMail-OSG: 4Ie6JlQVM1kU_q7oF1AV0ZNuNIJLKnWGWbs.vU0_3m3UsTlDlsCfnmJPkVxlc4IQ9aPHQjXSpg-- Reply-To: From: "Turner, Sean P." To: "'Paul Hoffman'" , References: <00c601c7b8bf$b5d66720$0301a8c0@Wylie> Subject: RE: Enterprise-only or more... Date: Wed, 27 Jun 2007 11:09:41 -0400 Organization: IECA, Inc. Message-ID: <013601c7b8cd$2fd8eae0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace4yH1jyrm+cWEWTNyRTn3y+XCCvQABLB1A Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Well I certainly didn't mean to jump the gun. spt -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul Hoffman Sent: Wednesday, June 27, 2007 10:33 AM To: ietf-trust-anchor@vpnc.org Subject: RE: Enterprise-only or more... So, now we're in charter discussions. I would like to not even talk about #3 or #4 for the initial charter. At the end of the work on #1 and #2, those who want to do #3 and #4 can ask for a re-charter. Unless we make the main work un-extendable (which we won't), those later tasks should not need any thought during the initial work. It would nice to, just for once, have a security WG that finishes its main work before delving into ratholes. --Paul Hoffman At 9:33 AM -0400 6/27/07, Turner, Sean P. wrote: >I'd like to not completely give up on #3/4 but doing #1/2 should 1st >order of business. > >spt > >-----Original Message----- >From: owner-ietf-trust-anchor@mail.vpnc.org >[mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul >Hoffman >Sent: Tuesday, June 26, 2007 6:58 PM >To: Thomas Hardjono; Stephen Kent >Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org >Subject: RE: Enterprise-only or more... > > >At 3:02 PM -0700 6/26/07, Thomas Hardjono wrote: >>Seems to me that we could have several issues/aspects pertaining to TAs: >> >>(1) Definition of a TA (ie. structure, syntax, semantics) >>(2) Protocol(s) to "manage" TAs (and definition/scope of what we mean >>by the term "manage") >>(3) Authorization model (ie. authorization to manage TAs) >>(4) Delegation model (i.e. authority-over-TA now delegates portions of >>authority or entire authority) > >(5) Others... From owner-ietf-trust-anchor Wed Jun 27 08:27:24 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5RFROgk025304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 08:27:24 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5RFROrj025303; Wed, 27 Jun 2007 08:27:24 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5RFRMbj025296 for ; Wed, 27 Jun 2007 08:27:23 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 23712 invoked from network); 27 Jun 2007 15:25:33 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;27 Jun 2007 15:25:33 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 27 Jun 2007 15:25:33 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Wed, 27 Jun 2007 11:27:20 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D0E6F@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: Enterprise-only or more... Date: Wed, 27 Jun 2007 11:27:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B8CF.A6393982" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C7B8CF.A6393982 Content-Type: text/plain > So, now we're in charter discussions. I would like to not > even talk about #3 or #4 for the initial charter. At the end > of the work on #1 and #2, those who want to do #3 and #4 can > ask for a re-charter. > Unless we make the main work un-extendable (which we won't), > those later tasks should not need any thought during the initial work. > > It would nice to, just for once, have a security WG that > finishes its main work before delving into ratholes. > > --Paul Hoffman > #3 seems like the kind of rathole that the IETF finds quite easily. > #4 is just further down the hole. A simple way to avoid both > of them, that hits the 90/10 rule just fine, is "end entities > inherently trust TA admins, and no one else, to add and > remove TAs from specified applications". Done. Why are authorization and delegation tasks for later? There's some authorization mechanism under your example that allows TA admins to be distinguished from others and there must be some delegation mechanism that allows them to be created. In earlier discussions, name constraints and certificate policies have been discussed as means to avoid making addition of TAs an all or nothing deal. We'll need to make sure #3 and #4 don't become ratholes, but I don't see how we can avoid the topics completely. ------_=_NextPart_001_01C7B8CF.A6393982 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Enterprise-only or more...
> So, now we're in charter discussions. I would = like to not
> even talk about #3 or #4 for the initial = charter. At the end
> of the work on #1 and #2, those who want to do = #3 and #4 can
> ask for a re-charter.
> Unless we make the main work un-extendable = (which we won't),
> those later tasks should not need any thought = during the initial work.
>
> It would nice to, just for once, have a = security WG that
> finishes its main work before delving into = ratholes.
>
> --Paul Hoffman

> #3 seems like the kind of rathole that the IETF = finds quite easily.
> #4 is just further down the hole. A simple way = to avoid both
> of them, that hits the 90/10 rule just fine, is = "end entities
> inherently trust TA admins, and no one else, to = add and
> remove TAs from specified applications". = Done.

Why are authorization and delegation tasks for = later? There's some authorization mechanism under your example = that allows TA admins to be distinguished from others and there must be = some delegation mechanism that allows them to be created. In = earlier discussions, name constraints and certificate policies have = been discussed as means to avoid making addition of TAs an all or = nothing deal. We'll need to make sure #3 and #4 don't become = ratholes, but I don't see how we can avoid the topics = completely.
------_=_NextPart_001_01C7B8CF.A6393982-- From owner-ietf-trust-anchor Wed Jun 27 09:16:03 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5RGG2IB029364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 09:16:02 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5RGG2HJ029363; Wed, 27 Jun 2007 09:16:02 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5RGG01P029354 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 27 Jun 2007 09:16:01 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.122.1; Wed, 27 Jun 2007 17:15:59 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Wed, 27 Jun 2007 17:15:58 +0100 From: Stefan Santesson To: Santosh Chokhani , "ietf-trust-anchor@vpnc.org" Date: Wed, 27 Jun 2007 17:15:54 +0100 Subject: RE: Does the problem need solving? Thread-Topic: Does the problem need solving? Thread-Index: Ace3MovAqvxvPpp9QpGwFA1GdpMVCAALYuOAAF1PqVA= Message-ID: References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> In-Reply-To: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5RGG21O029358 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Just have in mind that TA management and certificate policies are controlled by, and serve, different entities. TA management is the relying party's means to control trust in keys. By configuring the scope of trust in each TA key, the RL can control its use within his environment. Certificate Policy management is the CA's means to define and limit the use of a particular certificate. The result may be the same but when the RL has no influence over the content of certificates, TA management and local cross certification are the only means available. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust- > anchor@mail.vpnc.org] On Behalf Of Santosh Chokhani > Sent: den 26 juni 2007 02:03 > To: ietf-trust-anchor@vpnc.org > Subject: RE: Does the problem need solving? > > > Steve, > > In addition to name constraints, we should permit to associate policy > related extensions to constrain a TA. Here is the rationale: > > Certificate policies will be used if a relying party does not want to > trust a trust anchor for all the policies trust anchor operates under. > > Policy mapping will be used when the relying party acceptable policy > set > does not include a TA domain (oops) policy set. The relying party will > need to map its policies to TA domain policies. The relying party > could > simply use the policies from the TA domain if the relying party is > using > that single TA for the application. But, when more than one TA are > used > by a single application and some of the TAs have different policies, > this facility is useful. The relying party could take the union of the > policies used by the various TAs as its acceptable policy set, but the > policy mapping approach is cleaner and more flexible. > > Inhibit policy mapping will be used when the relying party wants to > permit some TAs, but not all TAs to map policies to other domains. > Naturally, this is only needed if TAs cross certify with other domains > and the application wants to accept some cross certifications and not > others. > > In summary, certificate policies should be required. Policy mapping > and > policy constraints one could do without; its feature and complexity > trade-off. > > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen > Kent > Sent: Monday, June 25, 2007 10:01 AM > To: Thomas Hardjono > Cc: ietf-trust-anchor@vpnc.org > Subject: RE: Does the problem need solving? > > > At 2:44 PM -0700 6/22/07, Thomas Hardjono wrote: > > > > > >... > > > >Agree, Steve. When I hear "TA" I immediately think X.509. I was > >thinking that this BOF/WG would (i) define a minimal X.509 TA (ie. one > >that is not over-burdened with so many extensions and policy-related > >information), and (ii) define a *protocol* to manage TA blobs > >(regardless of what the TA structure finally looks like). > > > >/thomas/ > > I think we do need to include support in a TA for name constraints, > to address the sort of problem that Henry Hotz raised. I am less > enthusiastic about the policy mapping stuff, but I could be convinced > otherwise if enough folks say that the policy extension is, pardon > the pun, critical for them. > > Steve > From owner-ietf-trust-anchor Wed Jun 27 09:25:26 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5RGPQth030398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 09:25:26 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5RGPQ9I030397; Wed, 27 Jun 2007 09:25:26 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5RGPNkh030386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 09:25:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D1D0E6F@scygmxs1.cygnacom.com> References: <886F5D4C78AFB14D87261206BFB9612E1D1D0E6F@scygmxs1.cygnacom.com> Date: Wed, 27 Jun 2007 09:25:00 -0700 To: Carl Wallace , ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: RE: Enterprise-only or more... Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:02 PM -0700 6/26/07, Thomas Hardjono wrote: >(3) Authorization model (ie. authorization to manage TAs) >(4) Delegation model (i.e. authority-over-TA now delegates portions of >authority or entire authority) At 11:27 AM -0400 6/27/07, Carl Wallace wrote: > > So, now we're in charter discussions. I would like to not >> even talk about #3 or #4 for the initial charter. At the end >> of the work on #1 and #2, those who want to do #3 and #4 can >> ask for a re-charter. >> Unless we make the main work un-extendable (which we won't), >> those later tasks should not need any thought during the initial work. >> >> It would nice to, just for once, have a security WG that >> finishes its main work before delving into ratholes. >> >> --Paul Hoffman > > > #3 seems like the kind of rathole that the IETF finds quite easily. >> #4 is just further down the hole. A simple way to avoid both >> of them, that hits the 90/10 rule just fine, is "end entities >> inherently trust TA admins, and no one else, to add and >> remove TAs from specified applications". Done. > >Why are authorization and delegation tasks for later? There's some >authorization mechanism under your example that allows TA admins to >be distinguished from others and there must be some delegation >mechanism that allows them to be created. Sorry, I wasn't clear earlier. TA admins (TAAs for brevity) are indeed distinguished from others in that a TAAs are inherently allowed to change the set of TAs for particular applications. We don't need to define an authentication mechanism for that in our work: that's a UI issue for the application or application environment (the OS). Thomas talked about "authorization to manage TAs", not the authorization of the TA to change the TA store for an application. >In earlier discussions, name constraints and certificate policies >have been discussed as means to avoid making addition of TAs an all >or nothing deal. Right, but those are assigned by the all-powerful TAA, I believe. I don't think that is a delegation model of the type that Thomas brought up where the TAA "delegates portions of authority or entire authority". Rather, policies are set by the TAA themselves. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Wed Jun 27 10:29:38 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5RHTcAZ036440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 10:29:38 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5RHTcGC036439; Wed, 27 Jun 2007 10:29:38 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5RHTbYZ036432 for ; Wed, 27 Jun 2007 10:29:38 -0700 (MST) (envelope-from chokhani@orionsec.com) 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" Subject: RE: Does the problem need solving? Date: Wed, 27 Jun 2007 10:28:55 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace3MovAqvxvPpp9QpGwFA1GdpMVCAALYuOAAF1PqVAAAsFAsA== References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> From: "Santosh Chokhani" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5RHTcYZ036434 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stefan, I am talking about associating certificate policies with a TA. I am not talking about managing the certificate policies for a CA or PKI. Associating certificate policies with a TA is very much relying party decision. The relying party can choose to trust a TA for subset of the policies for a PKI domain. -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Wednesday, June 27, 2007 12:16 PM To: Santosh Chokhani; ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? Just have in mind that TA management and certificate policies are controlled by, and serve, different entities. TA management is the relying party's means to control trust in keys. By configuring the scope of trust in each TA key, the RL can control its use within his environment. Certificate Policy management is the CA's means to define and limit the use of a particular certificate. The result may be the same but when the RL has no influence over the content of certificates, TA management and local cross certification are the only means available. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust- > anchor@mail.vpnc.org] On Behalf Of Santosh Chokhani > Sent: den 26 juni 2007 02:03 > To: ietf-trust-anchor@vpnc.org > Subject: RE: Does the problem need solving? > > > Steve, > > In addition to name constraints, we should permit to associate policy > related extensions to constrain a TA. Here is the rationale: > > Certificate policies will be used if a relying party does not want to > trust a trust anchor for all the policies trust anchor operates under. > > Policy mapping will be used when the relying party acceptable policy > set > does not include a TA domain (oops) policy set. The relying party will > need to map its policies to TA domain policies. The relying party > could > simply use the policies from the TA domain if the relying party is > using > that single TA for the application. But, when more than one TA are > used > by a single application and some of the TAs have different policies, > this facility is useful. The relying party could take the union of the > policies used by the various TAs as its acceptable policy set, but the > policy mapping approach is cleaner and more flexible. > > Inhibit policy mapping will be used when the relying party wants to > permit some TAs, but not all TAs to map policies to other domains. > Naturally, this is only needed if TAs cross certify with other domains > and the application wants to accept some cross certifications and not > others. > > In summary, certificate policies should be required. Policy mapping > and > policy constraints one could do without; its feature and complexity > trade-off. > > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen > Kent > Sent: Monday, June 25, 2007 10:01 AM > To: Thomas Hardjono > Cc: ietf-trust-anchor@vpnc.org > Subject: RE: Does the problem need solving? > > > At 2:44 PM -0700 6/22/07, Thomas Hardjono wrote: > > > > > >... > > > >Agree, Steve. When I hear "TA" I immediately think X.509. I was > >thinking that this BOF/WG would (i) define a minimal X.509 TA (ie. one > >that is not over-burdened with so many extensions and policy-related > >information), and (ii) define a *protocol* to manage TA blobs > >(regardless of what the TA structure finally looks like). > > > >/thomas/ > > I think we do need to include support in a TA for name constraints, > to address the sort of problem that Henry Hotz raised. I am less > enthusiastic about the policy mapping stuff, but I could be convinced > otherwise if enough folks say that the policy extension is, pardon > the pun, critical for them. > > Steve > From owner-ietf-trust-anchor Wed Jun 27 10:46:25 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5RHkPYE037860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 10:46:25 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5RHkPF0037859; Wed, 27 Jun 2007 10:46:25 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5RHkMqv037849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 10:46:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> Date: Wed, 27 Jun 2007 10:46:02 -0700 To: "Santosh Chokhani" , From: Paul Hoffman Subject: RE: Does the problem need solving? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote: >I am talking about associating certificate policies with a TA. I am not >talking about managing the certificate policies for a CA or PKI. > >Associating certificate policies with a TA is very much relying party >decision. The relying party can choose to trust a TA for subset of the >policies for a PKI domain. Quite right. It's hard for those of us who have been swimming in the PKIX waters for so long to remember that the relying party gets to make his/her own decisions and don't have to rely only on what is in a certificate. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Wed Jun 27 17:01:17 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5S01HVi077400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 17:01:17 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5S01Hgd077399; Wed, 27 Jun 2007 17:01:17 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5S01Fhl077384; Wed, 27 Jun 2007 17:01:16 -0700 (MST) (envelope-from mcr@marajade.sandelman.ca) Received: from sandelman.ottawa.on.ca (wlan199.sandelman.ca [205.150.200.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marajade.sandelman.ca.", Issuer "Michael Richardson" (verified OK)) by cod.sandelman.ca (Postfix) with ESMTP id B63761239C; Wed, 27 Jun 2007 20:01:14 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 960D44E789; Wed, 27 Jun 2007 20:01:13 -0400 (EDT) From: Michael Richardson To: Paul Hoffman cc: "Santosh Chokhani" , ietf-trust-anchor@vpnc.org Subject: Re: Does the problem need solving? In-Reply-To: Message from Paul Hoffman of "Wed, 27 Jun 2007 10:46:02 PDT." References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) Date: Wed, 27 Jun 2007 20:01:13 -0400 Message-ID: <9381.1182988873@marajade.sandelman.ca> Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Paul" == Paul Hoffman writes: >> I am talking about associating certificate policies with a TA. I >> am not talking about managing the certificate policies for a CA >> or PKI. >> >> Associating certificate policies with a TA is very much relying >> party decision. The relying party can choose to trust a TA for >> subset of the policies for a PKI domain. Paul> Quite right. It's hard for those of us who have been swimming Paul> in the PKIX waters for so long to remember that the relying Paul> party gets to make his/her own decisions and don't have to Paul> rely only on what is in a certificate. That's why reviewing the SPKI stuff is important. SPKI is about this realization. Only the relying party can make this decision. - -- ] Bear: "Me, I'm just the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRoL6RoCLcPvd0N1lAQJ33gf9GY2N8VBQTrWlY0LTztp3iaMpRTo0bX3Q +PFdUk1IxwkNiExYhW30QvSpiM3QZ2OfEo4Raf1d0fdn+m39OzPd8Z/irzrhUGWb wZN4Fx0j+tClKdFAsBKKbnv7U5G1AmjL8n779NHMA2ovkssxq3L69EnOZgnFBUYU ao7bzcO2c7F7gpSe3PeKxHHYD+SxdP9hVcK4FuA4y+BDIGqjShvgwDDMuRZzaEgF Y3Z9Yr9SF6EDCHoJytk+RP7P4W1+LJKxI7QwpKd9xsCoJgazpEAjxCVp59rwG3cM lEr5GxopRFbyyx0wZ5DRs0HeVNdkbp6futjudM5JBgpcoDp5ucv+8w== =KCm2 -----END PGP SIGNATURE----- From owner-ietf-trust-anchor Thu Jun 28 06:47:48 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SDlmdO047761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 06:47:48 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5SDlmlX047760; Thu, 28 Jun 2007 06:47:48 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SDlkX8047747; Thu, 28 Jun 2007 06:47:47 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.31.40.73]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I3uLW-00057l-69; Thu, 28 Jun 2007 09:47:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> Date: Thu, 28 Jun 2007 09:45:38 -0400 To: Paul Hoffman From: Stephen Kent Subject: RE: Does the problem need solving? Cc: "Santosh Chokhani" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:46 AM -0700 6/27/07, Paul Hoffman wrote: >At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote: >>I am talking about associating certificate policies with a TA. I am not >>talking about managing the certificate policies for a CA or PKI. >> >>Associating certificate policies with a TA is very much relying party >>decision. The relying party can choose to trust a TA for subset of the >>policies for a PKI domain. > >Quite right. It's hard for those of us who have been swimming in the >PKIX waters for so long to remember that the relying party gets to >make his/her own decisions and don't have to rely only on what is in >a certificate. > >--Paul Hoffman, Director >--VPN Consortium I'm surprised to hear you say that. PKIX has always operated in the space where RPs select TAs, and initialize the path validation parameters. What aspects of PKIX standards do you believe leads folks to think otherwise? Steve From owner-ietf-trust-anchor Thu Jun 28 06:47:54 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SDlsFC047779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 06:47:54 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5SDlsat047778; Thu, 28 Jun 2007 06:47:54 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SDlm0f047763; Thu, 28 Jun 2007 06:47:53 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.31.40.73]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I3uLY-00057l-69; Thu, 28 Jun 2007 09:47:45 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <9381.1182988873@marajade.sandelman.ca> References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> <9381.1182988873@marajade.sandelman.ca> Date: Thu, 28 Jun 2007 09:47:48 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: Does the problem need solving? Cc: Paul Hoffman , "Santosh Chokhani" , ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:01 PM -0400 6/27/07, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>>>>> "Paul" == Paul Hoffman writes: > >> I am talking about associating certificate policies with a TA. I > >> am not talking about managing the certificate policies for a CA > >> or PKI. > >> > >> Associating certificate policies with a TA is very much relying > >> party decision. The relying party can choose to trust a TA for > >> subset of the policies for a PKI domain. > > Paul> Quite right. It's hard for those of us who have been swimming > Paul> in the PKIX waters for so long to remember that the relying > Paul> party gets to make his/her own decisions and don't have to > Paul> rely only on what is in a certificate. > > That's why reviewing the SPKI stuff is important. > SPKI is about this realization. > Only the relying party can make this decision. Sorry, Michael, but I believe Paul wrong in his assertion. Maybe folks who have been brainwashed by VeriSign think differently, but PKIX has always operated in a space where configuration of a TA is up to the RP. Steve From owner-ietf-trust-anchor Thu Jun 28 07:47:00 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SEl0er054262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 07:47:00 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5SEl0L3054261; Thu, 28 Jun 2007 07:47:00 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SEkkVC054245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 07:46:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> Date: Thu, 28 Jun 2007 07:46:25 -0700 To: Stephen Kent From: Paul Hoffman Subject: RE: Does the problem need solving? Cc: "Santosh Chokhani" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:45 AM -0400 6/28/07, Stephen Kent wrote: >At 10:46 AM -0700 6/27/07, Paul Hoffman wrote: >>At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote: >>>I am talking about associating certificate policies with a TA. I am not >>>talking about managing the certificate policies for a CA or PKI. >>> >>>Associating certificate policies with a TA is very much relying party >>>decision. The relying party can choose to trust a TA for subset of the >>>policies for a PKI domain. >> >>Quite right. It's hard for those of us who have been swimming in >>the PKIX waters for so long to remember that the relying party gets >>to make his/her own decisions and don't have to rely only on what >>is in a certificate. > >I'm surprised to hear you say that. > >PKIX has always operated in the space where RPs select TAs, and >initialize the path validation parameters. What aspects of PKIX >standards do you believe leads folks to think otherwise? There is a large difference between "initialize the path validation parameters" and "can initialize the path validation parameters". I know of no popularly-used system that relies on PKIX certs that allows any initialization of the path validation parameters. I assume that you may know of one or two, but that does not negate what I said above. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 28 07:52:44 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SEqhNZ054808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 07:52:44 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5SEqhDE054807; Thu, 28 Jun 2007 07:52:43 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5SEqfI4054798 for ; Thu, 28 Jun 2007 07:52:42 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: (qmail 9030 invoked from network); 28 Jun 2007 14:52:38 -0000 Received: from sharon.boeyen@entrust.com by sottccs1.entrust.com with EntrustECS-Server-8.0;28 Jun 2007 14:52:38 -0000 Received: from sottexch1.corp.ad.entrust.com (10.4.51.28) by sottccs1.entrust.com with SMTP; 28 Jun 2007 14:52:37 -0000 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" Subject: RE: Does the problem need solving? Date: Thu, 28 Jun 2007 10:52:39 -0400 Message-ID: <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace5k154/HhHU4TTSWqKlMDOYMIJFAAAHRlA References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> From: "Sharon Boeyen" To: "Paul Hoffman" , "Stephen Kent" Cc: "Santosh Chokhani" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5SEqhI4054802 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul, fyi there are several such systems in wide deployment today that DO initialize path validation variables as cited in RFC 3280. -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul Hoffman Sent: Thursday, June 28, 2007 10:46 AM To: Stephen Kent Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? At 9:45 AM -0400 6/28/07, Stephen Kent wrote: >At 10:46 AM -0700 6/27/07, Paul Hoffman wrote: >>At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote: >>>I am talking about associating certificate policies with a TA. I am >>>not talking about managing the certificate policies for a CA or PKI. >>> >>>Associating certificate policies with a TA is very much relying party >>>decision. The relying party can choose to trust a TA for subset of >>>the policies for a PKI domain. >> >>Quite right. It's hard for those of us who have been swimming in the >>PKIX waters for so long to remember that the relying party gets to >>make his/her own decisions and don't have to rely only on what is in a >>certificate. > >I'm surprised to hear you say that. > >PKIX has always operated in the space where RPs select TAs, and >initialize the path validation parameters. What aspects of PKIX >standards do you believe leads folks to think otherwise? There is a large difference between "initialize the path validation parameters" and "can initialize the path validation parameters". I know of no popularly-used system that relies on PKIX certs that allows any initialization of the path validation parameters. I assume that you may know of one or two, but that does not negate what I said above. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 28 08:23:27 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SFNRNj057839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 08:23:27 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5SFNR6F057838; Thu, 28 Jun 2007 08:23:27 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5SFNPr5057823 for ; Thu, 28 Jun 2007 08:23:26 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 5373 invoked from network); 28 Jun 2007 15:23:21 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.32.186 with login) by smtp108.biz.mail.re2.yahoo.com with SMTP; 28 Jun 2007 15:23:20 -0000 X-YMail-OSG: SXRxtDYVM1m0KDO2HzSZMfzGMl6N.uU4ZKIbuTotd8.tJWBTk5ivBELlmjHxzgUO4wJMnWtAzg-- Reply-To: From: "Turner, Sean P." To: "'Sharon Boeyen'" , "'Paul Hoffman'" , "'Stephen Kent'" Cc: "'Santosh Chokhani'" , References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> Subject: RE: Does the problem need solving? Date: Thu, 28 Jun 2007 11:14:59 -0400 Organization: IECA, Inc. Message-ID: <018a01c7b997$17c8e2f0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace5k154/HhHU4TTSWqKlMDOYMIJFAAAHRlAAADH4eA= Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As long as we make the different part of the initialization "stuff" optional then we can allow different implementations to initialize different "stuff". spt -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Sharon Boeyen Sent: Thursday, June 28, 2007 10:53 AM To: Paul Hoffman; Stephen Kent Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? Paul, fyi there are several such systems in wide deployment today that DO initialize path validation variables as cited in RFC 3280. -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul Hoffman Sent: Thursday, June 28, 2007 10:46 AM To: Stephen Kent Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? At 9:45 AM -0400 6/28/07, Stephen Kent wrote: >At 10:46 AM -0700 6/27/07, Paul Hoffman wrote: >>At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote: >>>I am talking about associating certificate policies with a TA. I am >>>not talking about managing the certificate policies for a CA or PKI. >>> >>>Associating certificate policies with a TA is very much relying party >>>decision. The relying party can choose to trust a TA for subset of >>>the policies for a PKI domain. >> >>Quite right. It's hard for those of us who have been swimming in the >>PKIX waters for so long to remember that the relying party gets to >>make his/her own decisions and don't have to rely only on what is in a >>certificate. > >I'm surprised to hear you say that. > >PKIX has always operated in the space where RPs select TAs, and >initialize the path validation parameters. What aspects of PKIX >standards do you believe leads folks to think otherwise? There is a large difference between "initialize the path validation parameters" and "can initialize the path validation parameters". I know of no popularly-used system that relies on PKIX certs that allows any initialization of the path validation parameters. I assume that you may know of one or two, but that does not negate what I said above. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 28 09:09:22 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SG9MGF063168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 09:09:22 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5SG9MX7063167; Thu, 28 Jun 2007 09:09:22 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SG9JD1063154 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 28 Jun 2007 09:09:20 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.122.1; Thu, 28 Jun 2007 17:09:18 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 28 Jun 2007 17:09:18 +0100 From: Stefan Santesson To: "turners@ieca.com" , "'Sharon Boeyen'" , "'Paul Hoffman'" , "'Stephen Kent'" CC: "'Santosh Chokhani'" , "ietf-trust-anchor@vpnc.org" Date: Thu, 28 Jun 2007 17:09:16 +0100 Subject: RE: Does the problem need solving? Thread-Topic: Does the problem need solving? Thread-Index: Ace5k154/HhHU4TTSWqKlMDOYMIJFAAAHRlAAADH4eAAAVIJMA== Message-ID: References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> <018a01c7b997$17c8e2f0$0301a8c0@Wylie> In-Reply-To: <018a01c7b997$17c8e2f0$0301a8c0@Wylie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5SG9LD0063155 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm not sure I get the technical disagreement here, if there in fact is any. The RL makes its own decision to trust anything, unless there is any law preventing that. In most cases there are no such laws (if there exist any). However we have a standardized process to determine if a certificate is valid as an important common measure that support uniform applications and security policies. A RL is likely to take own steps in limiting reliance on a certificate beyond RFC3280 path validation. To a great extent this comes from configuring trust in TAs - Part of this is if and when the RL can make use of extension data from a root certificate as input to path validation to further constrain it. - Part of this is how an RL can apply additional constraints that cannot be added to the existing root certificate without re-signing it. This aspect is highly vendor specific and will typically rely on a separate security infrastructure or manual procedures. When a RL do this local trust configuration the RA can: - Create its own root and cross certify existing TAs, creating CA certificates for the TAs with additional constraints embedded in extensions. - Assign external parameters to each TA and store them with the TA using some external protection mechanism for integrity. What I'm curious about this is exactly where we think a new standard is needed. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust- > anchor@mail.vpnc.org] On Behalf Of Turner, Sean P. > Sent: den 28 juni 2007 17:15 > To: 'Sharon Boeyen'; 'Paul Hoffman'; 'Stephen Kent' > Cc: 'Santosh Chokhani'; ietf-trust-anchor@vpnc.org > Subject: RE: Does the problem need solving? > > > As long as we make the different part of the initialization "stuff" > optional > then we can allow different implementations to initialize different > "stuff". > > spt > > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Sharon > Boeyen > Sent: Thursday, June 28, 2007 10:53 AM > To: Paul Hoffman; Stephen Kent > Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org > Subject: RE: Does the problem need solving? > > > Paul, fyi there are several such systems in wide deployment today that > DO > initialize path validation variables as cited in RFC 3280. > > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul > Hoffman > Sent: Thursday, June 28, 2007 10:46 AM > To: Stephen Kent > Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org > Subject: RE: Does the problem need solving? > > > At 9:45 AM -0400 6/28/07, Stephen Kent wrote: > >At 10:46 AM -0700 6/27/07, Paul Hoffman wrote: > >>At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote: > >>>I am talking about associating certificate policies with a TA. I am > >>>not talking about managing the certificate policies for a CA or PKI. > >>> > >>>Associating certificate policies with a TA is very much relying > party > > >>>decision. The relying party can choose to trust a TA for subset of > >>>the policies for a PKI domain. > >> > >>Quite right. It's hard for those of us who have been swimming in the > >>PKIX waters for so long to remember that the relying party gets to > >>make his/her own decisions and don't have to rely only on what is in > a > > >>certificate. > > > >I'm surprised to hear you say that. > > > >PKIX has always operated in the space where RPs select TAs, and > >initialize the path validation parameters. What aspects of PKIX > >standards do you believe leads folks to think otherwise? > > There is a large difference between "initialize the path validation > parameters" and "can initialize the path validation parameters". I know > of > no popularly-used system that relies on PKIX certs that allows any > initialization of the path validation parameters. I assume that you may > know > of one or two, but that does not negate what I said above. > > --Paul Hoffman, Director > --VPN Consortium > > > From owner-ietf-trust-anchor Thu Jun 28 09:53:33 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SGrX7v067791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 09:53:33 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5SGrXTk067790; Thu, 28 Jun 2007 09:53:33 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SGrVK0067780; Thu, 28 Jun 2007 09:53:32 -0700 (MST) (envelope-from chokhani@orionsec.com) 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" Subject: RE: Does the problem need solving? Date: Thu, 28 Jun 2007 09:51:58 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C8790841084B@EXVS01.ex.dslextreme.net> In-Reply-To: <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace5k154/HhHU4TTSWqKlMDOYMIJFAAAHRlAAAQfQEA= References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> From: "Santosh Chokhani" To: "Sharon Boeyen" , "Paul Hoffman" , "Stephen Kent" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5SGrWK0067781 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steve and Sharon, I am firmly with Paul. 3280 does not require (albeit does not prohibit) to associate initial values with a trust anchor which is different from associating these with a path validation process. It is one thing to initialize path validation based on application need and another to associated shades of gray with different TAs used by the RP. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Thursday, June 28, 2007 10:53 AM To: Paul Hoffman; Stephen Kent Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? Paul, fyi there are several such systems in wide deployment today that DO initialize path validation variables as cited in RFC 3280. -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul Hoffman Sent: Thursday, June 28, 2007 10:46 AM To: Stephen Kent Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? At 9:45 AM -0400 6/28/07, Stephen Kent wrote: >At 10:46 AM -0700 6/27/07, Paul Hoffman wrote: >>At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote: >>>I am talking about associating certificate policies with a TA. I am >>>not talking about managing the certificate policies for a CA or PKI. >>> >>>Associating certificate policies with a TA is very much relying party >>>decision. The relying party can choose to trust a TA for subset of >>>the policies for a PKI domain. >> >>Quite right. It's hard for those of us who have been swimming in the >>PKIX waters for so long to remember that the relying party gets to >>make his/her own decisions and don't have to rely only on what is in a >>certificate. > >I'm surprised to hear you say that. > >PKIX has always operated in the space where RPs select TAs, and >initialize the path validation parameters. What aspects of PKIX >standards do you believe leads folks to think otherwise? There is a large difference between "initialize the path validation parameters" and "can initialize the path validation parameters". I know of no popularly-used system that relies on PKIX certs that allows any initialization of the path validation parameters. I assume that you may know of one or two, but that does not negate what I said above. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 28 11:31:53 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SIVrkG079567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 11:31:53 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5SIVrev079566; Thu, 28 Jun 2007 11:31:53 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5SIVodH079540 for ; Thu, 28 Jun 2007 11:31:51 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: (qmail 9295 invoked from network); 28 Jun 2007 18:31:47 -0000 Received: from sharon.boeyen@entrust.com by sottccs1.entrust.com with EntrustECS-Server-8.0;28 Jun 2007 18:31:47 -0000 Received: from sottexch1.corp.ad.entrust.com (10.4.51.28) by sottccs1.entrust.com with SMTP; 28 Jun 2007 18:31:46 -0000 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" Subject: RE: Does the problem need solving? Date: Thu, 28 Jun 2007 14:31:49 -0400 Message-ID: <04398A2C9F306C4690265C144089972D01BE75BB@sottexch1.corp.ad.entrust.com> In-Reply-To: <82D5657AE1F54347A734BDD33637C8790841084B@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace5k154/HhHU4TTSWqKlMDOYMIJFAAAHRlAAAQfQEAAAiAPoA== References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> <82D5657AE1F54347A734BDD33637C8790841084B@EXVS01.ex.dslextreme.net> From: "Sharon Boeyen" To: "Santosh Chokhani" , "Paul Hoffman" , "Stephen Kent" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5SIVpdH079544 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think there is some confusion in interpreting what I "thought" I said because I agree with you. I guess it all depends on your definition of a TA (historically I've considered it a trusted public key and DN that are used as the root for trust decisions). Using that definition, the TA and the initialized path validation variables are both inputs to the path validation process. The comment I sent was only that there are environments out there today that do configure those path validation variables. It was meant as a response to the last point Paul made in his message: ----------- Paul's point: "There is a large difference between "initialize the path validation parameters" and "can initialize the path validation parameters". I know of no popularly-used system that relies on PKIX certs that allows any initialization of the path validation parameters. I assume that you may know of one or two, but that does not negate what I said above." --------------------- I was not trying to tie them to the trusted public key - in fact I believe it makes more sense to enable them to be tailored on a per user or a per application basis regardless of the trusted key (or at least allow variations on the set of variable settings for the same key for different users/apps. I thought others wanted to tie them to the key, not me. Sorry if I confused folks with what I tried to say (I really hate email as a communication tool!). Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Thursday, June 28, 2007 12:52 PM To: Sharon Boeyen; Paul Hoffman; Stephen Kent Cc: ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? Steve and Sharon, I am firmly with Paul. 3280 does not require (albeit does not prohibit) to associate initial values with a trust anchor which is different from associating these with a path validation process. It is one thing to initialize path validation based on application need and another to associated shades of gray with different TAs used by the RP. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Thursday, June 28, 2007 10:53 AM To: Paul Hoffman; Stephen Kent Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? Paul, fyi there are several such systems in wide deployment today that DO initialize path validation variables as cited in RFC 3280. -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul Hoffman Sent: Thursday, June 28, 2007 10:46 AM To: Stephen Kent Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? At 9:45 AM -0400 6/28/07, Stephen Kent wrote: >At 10:46 AM -0700 6/27/07, Paul Hoffman wrote: >>At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote: >>>I am talking about associating certificate policies with a TA. I am >>>not talking about managing the certificate policies for a CA or PKI. >>> >>>Associating certificate policies with a TA is very much relying party >>>decision. The relying party can choose to trust a TA for subset of >>>the policies for a PKI domain. >> >>Quite right. It's hard for those of us who have been swimming in the >>PKIX waters for so long to remember that the relying party gets to >>make his/her own decisions and don't have to rely only on what is in a >>certificate. > >I'm surprised to hear you say that. > >PKIX has always operated in the space where RPs select TAs, and >initialize the path validation parameters. What aspects of PKIX >standards do you believe leads folks to think otherwise? There is a large difference between "initialize the path validation parameters" and "can initialize the path validation parameters". I know of no popularly-used system that relies on PKIX certs that allows any initialization of the path validation parameters. I assume that you may know of one or two, but that does not negate what I said above. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 28 11:31:55 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SIVtsf079586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 11:31:55 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5SIVtwu079585; Thu, 28 Jun 2007 11:31:55 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from ca-server2.wavx.wavesys.com (ca-server2.wavx.wavesys.com [65.197.200.86] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SIVr1H079570; Thu, 28 Jun 2007 11:31:54 -0700 (MST) (envelope-from thardjono@wavesys.com) 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" Subject: RE: Does the problem need solving? Date: Thu, 28 Jun 2007 11:32:12 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace5k154/HhHU4TTSWqKlMDOYMIJFAAAHRlAAADH4eAAAVIJMAAE8K+g From: "Thomas Hardjono" To: "Stefan Santesson" , , "Sharon Boeyen" , "Paul Hoffman" , "Stephen Kent" Cc: "Santosh Chokhani" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5SIVs1H079572 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of > Stefan Santesson > Sent: Thursday, June 28, 2007 9:09 AM > To: turners@ieca.com; 'Sharon Boeyen'; 'Paul Hoffman'; 'Stephen Kent' > Cc: 'Santosh Chokhani'; ietf-trust-anchor@vpnc.org > Subject: RE: Does the problem need solving? > > > [cut] > > What I'm curious about this is exactly where we think a new > standard is needed. > > > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > Stefan, In order to answer your last question, here is the Enterprise scenario that came to my mind when I read draft-00: - The Enterprise IT Admin is "god" in the Enterprise. He/she determines which machines/devices, OS, softwares, middlewares, applications etc. than can exist in the Enterprise. - The IT Admin runs the network security infrastructure, and operates the PKI infrastructure in the Enterprise (including the CA(s), RA(s), etc..). - The IT Admin creates the TAs, install them (remotely) to all Enterprise client machines, and configures (remotely) each application (on each client machine) to accept the TA(s) that the IT Admin has determined. - The IT Admin performs TA management as per Enterprise security policy (ie. delete TAs, replaces TAs, install new TAs, etc). - For B2B cases (eg. Ford Motor sharing resources with its 1000 component suppliers), the IT Admin may create further TA(s) for that engagement and configures it in the appropriate client machines. The IT Admin needs trust infrastructure *management tools* that can perform all the above (and more), without being locked-in to proprietary vendor solutions. Which is why standard(s) are needed :) /thomas/ From owner-ietf-trust-anchor Thu Jun 28 12:10:41 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SJAfZu083014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 12:10:41 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5SJAf6D083013; Thu, 28 Jun 2007 12:10:41 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5SJAcUg082990 for ; Thu, 28 Jun 2007 12:10:40 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200706281910.l5SJAcUg082990@balder-227.proper.com> Received: (qmail 13812 invoked by uid 0); 28 Jun 2007 19:10:28 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.247) by woodstock.binhost.com with SMTP; 28 Jun 2007 19:10:28 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jun 2007 14:56:12 -0400 To: "Sharon Boeyen" From: Russ Housley Subject: RE: Does the problem need solving? Cc: In-Reply-To: <04398A2C9F306C4690265C144089972D01BE75BB@sottexch1.corp.ad .entrust.com> References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> <82D5657AE1F54347A734BDD33637C8790841084B@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75BB@sottexch1.corp.ad.entrust.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sharon: I see situations where I would like to be able to tie them to a key. For example, name constraints is some think that I would like to enforce on one key but not another. Similarly, I can imagine wanting to require explicit policy on one key but not another. Russ At 02:31 PM 6/28/2007, Sharon Boeyen wrote: >I think there is some confusion in interpreting what I "thought" I said >because I agree with you. I guess it all depends on your definition of a >TA (historically I've considered it a trusted public key and DN that are >used as the root for trust decisions). Using that definition, the TA and >the initialized path validation variables are both inputs to the path >validation process. The comment I sent was only that there are >environments out there today that do configure those path validation >variables. It was meant as a response to the last point Paul made in his >message: > >----------- >Paul's point: "There is a large difference between "initialize the path >validation parameters" and "can initialize the path validation >parameters". I know of no popularly-used system that relies on PKIX >certs that allows any initialization of the path validation parameters. >I assume that you may know of one or two, but that does not negate what >I said above." >--------------------- > >I was not trying to tie them to the trusted public key - in fact I >believe it makes more sense to enable them to be tailored on a per user >or a per application basis regardless of the trusted key (or at least >allow variations on the set of variable settings for the same key for >different users/apps. I thought others wanted to tie them to the key, >not me. Sorry if I confused folks with what I tried to say (I really >hate email as a communication tool!). > >Cheers, >Sharon > >-----Original Message----- >From: Santosh Chokhani [mailto:chokhani@orionsec.com] >Sent: Thursday, June 28, 2007 12:52 PM >To: Sharon Boeyen; Paul Hoffman; Stephen Kent >Cc: ietf-trust-anchor@vpnc.org >Subject: RE: Does the problem need solving? > >Steve and Sharon, > >I am firmly with Paul. 3280 does not require (albeit does not prohibit) >to associate initial values with a trust anchor which is different from >associating these with a path validation process. > >It is one thing to initialize path validation based on application need >and another to associated shades of gray with different TAs used by the >RP. > >-----Original Message----- >From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] >Sent: Thursday, June 28, 2007 10:53 AM >To: Paul Hoffman; Stephen Kent >Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org >Subject: RE: Does the problem need solving? > >Paul, fyi there are several such systems in wide deployment today that >DO initialize path validation variables as cited in RFC 3280. > >-----Original Message----- >From: owner-ietf-trust-anchor@mail.vpnc.org >[mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul Hoffman >Sent: Thursday, June 28, 2007 10:46 AM >To: Stephen Kent >Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org >Subject: RE: Does the problem need solving? > > >At 9:45 AM -0400 6/28/07, Stephen Kent wrote: > >At 10:46 AM -0700 6/27/07, Paul Hoffman wrote: > >>At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote: > >>>I am talking about associating certificate policies with a TA. I am > >>>not talking about managing the certificate policies for a CA or PKI. > >>> > >>>Associating certificate policies with a TA is very much relying party > > >>>decision. The relying party can choose to trust a TA for subset of > >>>the policies for a PKI domain. > >> > >>Quite right. It's hard for those of us who have been swimming in the > >>PKIX waters for so long to remember that the relying party gets to > >>make his/her own decisions and don't have to rely only on what is in a > > >>certificate. > > > >I'm surprised to hear you say that. > > > >PKIX has always operated in the space where RPs select TAs, and > >initialize the path validation parameters. What aspects of PKIX > >standards do you believe leads folks to think otherwise? > >There is a large difference between "initialize the path validation >parameters" and "can initialize the path validation parameters". I know >of no popularly-used system that relies on PKIX certs that allows any >initialization of the path validation parameters. I assume that you may >know of one or two, but that does not negate what I said above. > >--Paul Hoffman, Director >--VPN Consortium From owner-ietf-trust-anchor Thu Jun 28 12:19:22 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SJJMx1083711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 12:19:22 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5SJJMD7083710; Thu, 28 Jun 2007 12:19:22 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5SJJJ3I083695 for ; Thu, 28 Jun 2007 12:19:21 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: (qmail 12339 invoked from network); 28 Jun 2007 19:19:16 -0000 Received: from sharon.boeyen@entrust.com by sottccs1.entrust.com with EntrustECS-Server-8.0;28 Jun 2007 19:19:16 -0000 Received: from sottexch1.corp.ad.entrust.com (10.4.51.28) by sottccs1.entrust.com with SMTP; 28 Jun 2007 19:19:15 -0000 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" Subject: RE: Does the problem need solving? Date: Thu, 28 Jun 2007 15:19:18 -0400 Message-ID: <04398A2C9F306C4690265C144089972D01BE75BD@sottexch1.corp.ad.entrust.com> In-Reply-To: <20070628191034.5A9033E0034@sottsym1.entrust.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace5uAGuMwiV5a12T0ibpxUeu7QGlwAABgvQ References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> <82D5657AE1F54347A734BDD33637C8790841084B@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75BB@sottexch1.corp.ad.entrust.com> <20070628191034.5A9033E0034@sottsym1.entrust.com> From: "Sharon Boeyen" To: "Russ Housley" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5SJJL3I083705 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think the question is how the "tie" is made. I agree that in some environments let's say enterprise A, you may want to tie such a name constraint to all uses of that public key by all users and for all apps. However there are also requirements where the same key may need to have a name constraint applied to it for the email app but no name constraint applied to it for a particular web app or a particular set of users may require one policy (eg high assurance) but another set is ok with medium or high assurance policy. Its that type of flexibility I'm trying to retain. How that actually gets achieved is a different question. If, for example, we end up defining a single structure that includes the key and all associated restrictions I'd want to ensure that there could be multiple instances of that same structure for the same key within a single environment. If we ended up defining a structure for the key and a separate structure for the restrictions that then get associated with given users or apps you can still achieve both. I'm not pushing for any particular mechanism at this point. I just want to ensure the flexibility is permitted and the requirements make it clear that the flexibility is needed (as well, of course, as the ability in a given environment to restrict that flexibility). Cheers, Sharon -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Thursday, June 28, 2007 2:56 PM To: Sharon Boeyen Cc: ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? Sharon: I see situations where I would like to be able to tie them to a key. For example, name constraints is some think that I would like to enforce on one key but not another. Similarly, I can imagine wanting to require explicit policy on one key but not another. Russ At 02:31 PM 6/28/2007, Sharon Boeyen wrote: >I think there is some confusion in interpreting what I "thought" I said >because I agree with you. I guess it all depends on your definition of >a TA (historically I've considered it a trusted public key and DN that >are used as the root for trust decisions). Using that definition, the >TA and the initialized path validation variables are both inputs to the >path validation process. The comment I sent was only that there are >environments out there today that do configure those path validation >variables. It was meant as a response to the last point Paul made in >his >message: > >----------- >Paul's point: "There is a large difference between "initialize the path >validation parameters" and "can initialize the path validation >parameters". I know of no popularly-used system that relies on PKIX >certs that allows any initialization of the path validation parameters. >I assume that you may know of one or two, but that does not negate what >I said above." >--------------------- > >I was not trying to tie them to the trusted public key - in fact I >believe it makes more sense to enable them to be tailored on a per user >or a per application basis regardless of the trusted key (or at least >allow variations on the set of variable settings for the same key for >different users/apps. I thought others wanted to tie them to the key, >not me. Sorry if I confused folks with what I tried to say (I really >hate email as a communication tool!). > >Cheers, >Sharon > >-----Original Message----- >From: Santosh Chokhani [mailto:chokhani@orionsec.com] >Sent: Thursday, June 28, 2007 12:52 PM >To: Sharon Boeyen; Paul Hoffman; Stephen Kent >Cc: ietf-trust-anchor@vpnc.org >Subject: RE: Does the problem need solving? > >Steve and Sharon, > >I am firmly with Paul. 3280 does not require (albeit does not >prohibit) to associate initial values with a trust anchor which is >different from associating these with a path validation process. > >It is one thing to initialize path validation based on application need >and another to associated shades of gray with different TAs used by the >RP. > >-----Original Message----- >From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] >Sent: Thursday, June 28, 2007 10:53 AM >To: Paul Hoffman; Stephen Kent >Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org >Subject: RE: Does the problem need solving? > >Paul, fyi there are several such systems in wide deployment today that >DO initialize path validation variables as cited in RFC 3280. > >-----Original Message----- >From: owner-ietf-trust-anchor@mail.vpnc.org >[mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul >Hoffman >Sent: Thursday, June 28, 2007 10:46 AM >To: Stephen Kent >Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org >Subject: RE: Does the problem need solving? > > >At 9:45 AM -0400 6/28/07, Stephen Kent wrote: > >At 10:46 AM -0700 6/27/07, Paul Hoffman wrote: > >>At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote: > >>>I am talking about associating certificate policies with a TA. I > >>>am not talking about managing the certificate policies for a CA or PKI. > >>> > >>>Associating certificate policies with a TA is very much relying > >>>party > > >>>decision. The relying party can choose to trust a TA for subset of > >>>the policies for a PKI domain. > >> > >>Quite right. It's hard for those of us who have been swimming in the > >>PKIX waters for so long to remember that the relying party gets to > >>make his/her own decisions and don't have to rely only on what is in > >>a > > >>certificate. > > > >I'm surprised to hear you say that. > > > >PKIX has always operated in the space where RPs select TAs, and > >initialize the path validation parameters. What aspects of PKIX > >standards do you believe leads folks to think otherwise? > >There is a large difference between "initialize the path validation >parameters" and "can initialize the path validation parameters". I know >of no popularly-used system that relies on PKIX certs that allows any >initialization of the path validation parameters. I assume that you may >know of one or two, but that does not negate what I said above. > >--Paul Hoffman, Director >--VPN Consortium From owner-ietf-trust-anchor Thu Jun 28 16:32:17 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SNWHRf006136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 16:32:17 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5SNWHGC006135; Thu, 28 Jun 2007 16:32:17 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mailbox.reptiles.org (mail.reptiles.org [198.96.210.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SNWFef006121; Thu, 28 Jun 2007 16:32:16 -0700 (MST) (envelope-from cat@reptiles.org) Received: from mail.reptiles.org ([198.96.210.227] port=58563) by mailbox.reptiles.org([198.96.210.227] port=25) via TCP with esmtp (4449 bytes) (sender: ) (ident using UNIX) id for ; Thu, 28 Jun 2007 19:31:55 -0400 (EDT) (Smail-3.2.0.121 2005-Nov-17 #4 built 2006-Nov-28) Date: Thu, 28 Jun 2007 19:31:53 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@gecko.reptiles.org Reply-To: Cat Okita To: Thomas Hardjono cc: Stefan Santesson , turners@ieca.com, Sharon Boeyen , Paul Hoffman , Stephen Kent , Santosh Chokhani , ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? In-Reply-To: Message-ID: <20070628192209.G37986@gecko.reptiles.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 28 Jun 2007, Thomas Hardjono wrote: > In order to answer your last question, here is the Enterprise scenario > that came to my mind when I read draft-00: I'm going to quibble with this right up front. This sounds like a monolithic IT Admin - and I can't say that I can think of many enterprises that actually match this model. Systems are usually separate from networks which are separate from security which is separate from databases and applications - and very often, they 'talk' only at the end of completely extended 10' poles. Taking your description, and tweaking it towards what I've seen over and over and over again... > - The Enterprise IT Admin is "god" in the Enterprise. He/she determines > which machines/devices, OS, softwares, middlewares, applications etc. > than can exist in the Enterprise. There's a group that's responsible for applications, another group that's responsible for OS/system hardware - and that extra group-or-ten that seem to be off doing their own thing... > - The IT Admin runs the network security infrastructure, and operates > the PKI infrastructure in the Enterprise (including the CA(s), RA(s), > etc..). The group running the external web servers have their own PKI, separate from the group that does enterprise authentication, and separate yet again from the group that deals with things like VPNs or internal applications. > - The IT Admin creates the TAs, install them (remotely) to all > Enterprise client machines, and configures (remotely) each application > (on each client machine) to accept the TA(s) that the IT Admin has > determined. There's a bunch of TAs floating around the enterprise, some that are installed remotely, to 'managed' client desktops - others are installed manually with different applications or services - and are maintained and given out by different groups. > - The IT Admin performs TA management as per Enterprise security policy > (ie. delete TAs, replaces TAs, install new TAs, etc). Management (and tracking) of TAs varies dramatically by group, and TAs are regularly orphaned... > - For B2B cases (eg. Ford Motor sharing resources with its 1000 > component suppliers), the IT Admin may create further TA(s) for that > engagement and configures it in the appropriate client machines. The myriad business partners all have slightly different requirements and configurations, resulting in something close to a 1:1 mapping of TA to business partner, and a management headache. > The IT Admin needs trust infrastructure *management tools* that can > perform all the above (and more), without being locked-in to proprietary > vendor solutions. Which is why standard(s) are needed :) The IT groups need trust infrastructure management tools that don't presume a single central source of authority, and can cooperate, delegate and inform between peers. I think we generally agree - but I'm somewhat more pessimistic about the state of the 'nation'. cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From owner-ietf-trust-anchor Thu Jun 28 18:08:31 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5T18Vh5013174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 18:08:31 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5T18V7l013173; Thu, 28 Jun 2007 18:08:31 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from nmta2.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.215]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5T18TD6013160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 18:08:30 -0700 (MST) (envelope-from hotz@jpl.nasa.gov) Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l5T17qJN006857; Thu, 28 Jun 2007 18:07:52 -0700 Received: from [137.78.61.96] (laphotz.jpl.nasa.gov [137.78.61.96]) by xmta3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l5T17a08001239; Thu, 28 Jun 2007 18:07:36 -0700 In-Reply-To: <20070628192209.G37986@gecko.reptiles.org> References: <20070628192209.G37986@gecko.reptiles.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8579AA9D-C6A6-4312-AA23-22C6BDC3C167@jpl.nasa.gov> Cc: Thomas Hardjono , Stefan Santesson , turners@ieca.com, Sharon Boeyen , Paul Hoffman , Stephen Kent , Santosh Chokhani , ietf-trust-anchor@vpnc.org Content-Transfer-Encoding: 7bit From: "Henry B. Hotz" Subject: Re: Does the problem need solving? Date: Thu, 28 Jun 2007 18:07:27 -0700 To: Cat Okita X-Mailer: Apple Mail (2.752.3) X-Source-IP: laphotz.jpl.nasa.gov [137.78.61.96] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Should I trim the CC list to just the list itself? Anyway. . . What I think *might* work would be independent TA's for each client application (Kerberos/PKINIT, Jabber, Web, etc.), AND a generic TA that each client app could optionally reference. The generic institutional one might work for Jabber, LDAP, and email. Web probably is broader, but references the generic institutional one as a subset. Kerberos/PKINIT is tighter and independent of the generic one. On Jun 28, 2007, at 4:31 PM, Cat Okita wrote: > On Thu, 28 Jun 2007, Thomas Hardjono wrote: >> In order to answer your last question, here is the Enterprise >> scenario >> that came to my mind when I read draft-00: > > I'm going to quibble with this right up front. This sounds like a > monolithic IT Admin - and I can't say that I can think of many > enterprises > that actually match this model. Systems are usually separate from > networks > which are separate from security which is separate from databases and > applications - and very often, they 'talk' only at the end of > completely > extended 10' poles. > > Taking your description, and tweaking it towards what I've seen over > and over and over again... > >> - The Enterprise IT Admin is "god" in the Enterprise. He/she >> determines >> which machines/devices, OS, softwares, middlewares, applications etc. >> than can exist in the Enterprise. > > There's a group that's responsible for applications, another group > that's > responsible for OS/system hardware - and that extra group-or-ten > that seem > to be off doing their own thing... > >> - The IT Admin runs the network security infrastructure, and operates >> the PKI infrastructure in the Enterprise (including the CA(s), RA(s), >> etc..). > > The group running the external web servers have their own PKI, > separate > from the group that does enterprise authentication, and separate > yet again > from the group that deals with things like VPNs or internal > applications. > >> - The IT Admin creates the TAs, install them (remotely) to all >> Enterprise client machines, and configures (remotely) each >> application >> (on each client machine) to accept the TA(s) that the IT Admin has >> determined. > > There's a bunch of TAs floating around the enterprise, some that are > installed remotely, to 'managed' client desktops - others are > installed > manually with different applications or services - and are > maintained and > given out by different groups. > >> - The IT Admin performs TA management as per Enterprise security >> policy >> (ie. delete TAs, replaces TAs, install new TAs, etc). > > Management (and tracking) of TAs varies dramatically by group, and TAs > are regularly orphaned... > >> - For B2B cases (eg. Ford Motor sharing resources with its 1000 >> component suppliers), the IT Admin may create further TA(s) for that >> engagement and configures it in the appropriate client machines. > > The myriad business partners all have slightly different > requirements and > configurations, resulting in something close to a 1:1 mapping of TA > to business partner, and a management headache. > >> The IT Admin needs trust infrastructure *management tools* that can >> perform all the above (and more), without being locked-in to >> proprietary >> vendor solutions. Which is why standard(s) are needed :) > > The IT groups need trust infrastructure management tools that don't > presume a single central source of authority, and can cooperate, > delegate > and inform between peers. > > I think we generally agree - but I'm somewhat more pessimistic > about the > state of the 'nation'. ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From owner-ietf-trust-anchor Thu Jun 28 18:31:06 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5T1V6UY014622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 18:31:06 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5T1V6PB014621; Thu, 28 Jun 2007 18:31:06 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5T1V54a014614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Jun 2007 18:31:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <8579AA9D-C6A6-4312-AA23-22C6BDC3C167@jpl.nasa.gov> References: <20070628192209.G37986@gecko.reptiles.org> <8579AA9D-C6A6-4312-AA23-22C6BDC3C167@jpl.nasa.gov> Date: Thu, 28 Jun 2007 18:30:42 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Re: Does the problem need solving? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 6:07 PM -0700 6/28/07, Henry B. Hotz wrote: >Should I trim the CC list to just the list itself? Yes. :-) >What I think *might* work would be independent TA's for each client >application (Kerberos/PKINIT, Jabber, Web, etc.), AND a generic TA >that each client app could optionally reference. The generic >institutional one might work for Jabber, LDAP, and email. Web >probably is broader, but references the generic institutional one as >a subset. Kerberos/PKINIT is tighter and independent of the generic >one. All of this might work, but it is irrelevant. We are proposing to design a useful protocol, not the end-all-be-all implementation. In fact, at the moment, we are supposed to be discussing the *requirements* for the protocol. If our requirements can produce a protocol that can be the basis of multile useful implementations, we have succeeded. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 28 20:50:14 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5T3oE1x026522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 20:50:14 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5T3oEpu026521; Thu, 28 Jun 2007 20:50:14 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5T3oDtV026508; Thu, 28 Jun 2007 20:50:13 -0700 (MST) (envelope-from pritikin@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 28 Jun 2007 20:50:11 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFgdhEarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,473,1175497200"; d="scan'208"; a="498707174:sNHT56786412" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5T3o8c4031247; Thu, 28 Jun 2007 20:50:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l5T3o4GW025774; Fri, 29 Jun 2007 03:50:08 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); Thu, 28 Jun 2007 20:50:04 -0700 Received: from [10.32.244.68] ([10.32.244.68]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 20:50:03 -0700 In-Reply-To: References: <20070628192209.G37986@gecko.reptiles.org> <8579AA9D-C6A6-4312-AA23-22C6BDC3C167@jpl.nasa.gov> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ietf-trust-anchor@vpnc.org Content-Transfer-Encoding: 7bit From: Max Pritikin Subject: Re: Does the problem need solving? Date: Thu, 28 Jun 2007 22:49:59 -0500 To: Paul Hoffman X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Jun 2007 03:50:04.0042 (UTC) FILETIME=[937AE6A0:01C7BA00] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1357; t=1183089008; x=1183953008; c=relaxed/simple; s=sjdkim1004; 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=20Does=20the=20problem=20need=20solving? |Sender:=20; bh=lE+fv7L49d0VG2R9d4cCw7eD/m8G0adYyzcSUYpdzKQ=; b=IuSMv0ittHCGzf4uquWlPBESFn2hDmNTJHm8MbbIXxsKjlBVrKXhtVZpmm3WfYPEq7HCS1qz 3OdxTSkLUzUuvw6SGHuH4c4wpZqNPfBX+fh7DSCdRvHQKxMlEHlc0hiM+Aglhxsyz3r7K6uc3X q9mZ+hB7d7s6qQg08VzOqtCcQ=; Authentication-Results: sj-dkim-1; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In terms of requirements: is it better for the protocol to manage multiple independent trust anchors, or one trust anchor. I tend to lean toward one trust anchor as there can easily be multiple instances of the communication ongoing and that simplifies the rest of the requirements. - max On Jun 28, 2007, at 8:30 PM, Paul Hoffman wrote: > > At 6:07 PM -0700 6/28/07, Henry B. Hotz wrote: >> Should I trim the CC list to just the list itself? > > Yes. :-) > >> What I think *might* work would be independent TA's for each >> client application (Kerberos/PKINIT, Jabber, Web, etc.), AND a >> generic TA that each client app could optionally reference. The >> generic institutional one might work for Jabber, LDAP, and email. >> Web probably is broader, but references the generic institutional >> one as a subset. Kerberos/PKINIT is tighter and independent of >> the generic one. > > All of this might work, but it is irrelevant. We are proposing to > design a useful protocol, not the end-all-be-all implementation. In > fact, at the moment, we are supposed to be discussing the > *requirements* for the protocol. If our requirements can produce a > protocol that can be the basis of multile useful implementations, > we have succeeded. > > --Paul Hoffman, Director > --VPN Consortium From owner-ietf-trust-anchor Fri Jun 29 03:54:06 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TAs5hU069802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 03:54:06 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5TAs5K4069801; Fri, 29 Jun 2007 03:54:05 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TAs49Y069786; Fri, 29 Jun 2007 03:54:05 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.31.40.57]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I4E70-0005WP-5U; Fri, 29 Jun 2007 06:54:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <82D5657AE1F54347A734BDD33637C8790841084B@EXVS01.ex.dslextreme.net> References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> <82D5657AE1F54347A734BDD33637C8790841084B@EXVS01.ex.dslextreme.net> Date: Fri, 29 Jun 2007 06:49:12 -0400 To: "Santosh Chokhani" From: Stephen Kent Subject: RE: Does the problem need solving? Cc: "Sharon Boeyen" , "Paul Hoffman" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:51 AM -0700 6/28/07, Santosh Chokhani wrote: >Steve and Sharon, > >I am firmly with Paul. 3280 does not require (albeit does not prohibit) >to associate initial values with a trust anchor which is different from >associating these with a path validation process. > >It is one thing to initialize path validation based on application need >and another to associated shades of gray with different TAs used by the >RP. > Yo are right that 3280 does not say explicitly that one initializes path validation parameters from a TA. But, these values have to come from somewhere, and I think we agree that in general, these parameters may differ for different TAs. That strongly argues for a capability to bundle the basic TA data wit these parameters. The fact that one usually is not provided with a management interface that allows that is a problem we should try to address under the heading of TA management, Steve From owner-ietf-trust-anchor Fri Jun 29 03:54:08 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TAs8ba069820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 03:54:08 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5TAs89b069819; Fri, 29 Jun 2007 03:54:08 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TAs7e8069806; Fri, 29 Jun 2007 03:54:08 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.31.40.57]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I4E75-0005WP-4P; Fri, 29 Jun 2007 06:54:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> Date: Fri, 29 Jun 2007 06:53:56 -0400 To: Paul Hoffman From: Stephen Kent Subject: RE: Does the problem need solving? Cc: "Santosh Chokhani" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>... > >There is a large difference between "initialize the path validation >parameters" and "can initialize the path validation parameters". I >know of no popularly-used system that relies on PKIX certs that >allows any initialization of the path validation parameters. I >assume that you may know of one or two, but that does not negate >what I said above. What you cite here is evidence of implementations that lack an important management interface component. No disagreement on that. But that does not make PKIX responsible for this missing component. As an analogy I note that despite the fact the 4301 and 2401 included an explicit requirement for an SPD management capability, the most widely distributed IPsec implementation did not (and still may not) include that capability. Surely you don't blame IPsec for that, do you :-)? Steve From owner-ietf-trust-anchor Fri Jun 29 04:35:28 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TBZSP0073656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 04:35:28 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5TBZSaR073655; Fri, 29 Jun 2007 04:35:28 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TBZP8q073640 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 29 Jun 2007 04:35:26 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.122.1; Fri, 29 Jun 2007 12:35:20 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 29 Jun 2007 12:35:20 +0100 From: Stefan Santesson To: Thomas Hardjono , Stephen Kent , Paul Hoffman CC: Stephen Farrell , "ietf-trust-anchor@vpnc.org" Date: Fri, 29 Jun 2007 12:34:54 +0100 Subject: RE: Enterprise-only or more... Thread-Topic: Enterprise-only or more... Thread-Index: Ace4LOCnWo+Ufun7SDSBsW9Du4HjqQAD6KawAH+WH0A= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5TBZR8p073643 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would like to be slightly more pragmatic. 1) Definition of TA. This is something we need before a BOF. A TA is obviously a public key that is the highest source of trust. The question is for whom and within what context. I think the only reasonable answer is that a TA is always a TA within a local context. What is TA for me may not be a TA for you. We also have different level of trust infrastructures serving each others. We may have a trust management infrastructure based on a trusted directory that uses one TA. This infrastructure may then used to distribute TAs for local applications through a directory based infrastructure. In other cases the security infrastructure is flat (i.e. for some devices) where we resort to manual procedures. Attempt at definition: Trust Anchor: A public key that acts as a highest source of trust within a local context. A TA may also include parameters that constrain the context of trust it is intended to serve. 2) What protocols to standardize In the Enterprise environment a local system using TAs is often subordinate to one ore more management systems with its own security model. This might be a directory centric solution distributing information over a secured network. Example: I bring my device/computer on the physical corporate network where it is initialized through admin passwords or tokens and in that process an number of TAs are imported that makes it possible to communicate remotely in the future with the enterprise network and update TAs for local applications. In the flat device scenario which I assume can be mobile devices, network routers, domain name servers etc, which are not tied to a common database or directory, TA management needs to cover the complete sets of security needs on its own. Common for all scenarios seems to be the potential need for a common format for the TA object itself and the parameters it is associated with. Therefore one candidate for a standard could be a TA object format including: - A public key (in the form of key + key parameters, or a self signed certificate - Optional additional parameters constraining trust in the public key, and - An optional signature There are situations when a self signed certificate is not desired. This is the case when I pick a public key from a trusted CA that I do not control and which self signed root I don't have. What more can we reasonably do? Currently I can't see it. I doubt we can define a generic exchange protocol. - For the device scenario I would suspect that any exchange protocol if necessary need to be defined in a more local application context. E.g. DNS SEC has its own solution and mobile devices have another while wireless access points a third. - For the Enterprise model I would think that the means of exchange will be defined by local directory schemas or databases having their own security model that would be hard to standardize. Is there anything else? Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust- > anchor@mail.vpnc.org] On Behalf Of Thomas Hardjono > Sent: den 27 juni 2007 00:02 > To: Stephen Kent; Paul Hoffman > Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org > Subject: RE: Enterprise-only or more... > > > > > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen > Kent > Sent: Tuesday, June 26, 2007 12:57 PM > To: Paul Hoffman > Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org > Subject: Re: Enterprise-only or more... > > > At 12:40 PM -0700 6/26/07, Paul Hoffman wrote: > >At 1:30 PM +0100 6/22/07, Stephen Farrell wrote: > >>... > > > >If there is one TA admin, and that person is someone other than me, > >then your model does not work. That is, the bank needs to get the > >single TA admin to bless the bank's TA. > > > >If there is more than one TA admin (say, a real TA admin plus the user > >controlling the application), then the bank only needs to convince one > >of the (probably the user) to install the bank's TA. > > > >I think a reasonable requirement is that the protocol allow the client > >to specify more than one TA admins. If that requirement is met, a > >system where the user really does control the system can simply name > >the user as a TA admin. > > There are multiple reasonable models. > > For example, a device may be "owned" by a vendor who delegates to a > user > or local admin the authority to install TAs with certain scope, but not > all TAs. This might be a model for desk top boxes or cell phones. > > In an enterprise context, a local admin may want a similar capability > for himself, delegating some control to individual users, but retaining > ultimate control over TA management for a desktop or laptop. > > Steve > > > Seems to me that we could have several issues/aspects pertaining to > TAs: > > (1) Definition of a TA (ie. structure, syntax, semantics) > (2) Protocol(s) to "manage" TAs (and definition/scope of what we mean > by > the term "manage") > (3) Authorization model (ie. authorization to manage TAs) > (4) Delegation model (i.e. authority-over-TA now delegates portions of > authority or entire authority) > (5) Others... > > The scope of the BOF/WG can easily become very wide, which is why I was > suggesting that the Enterprise use-case may be more manageable :) > > /thomas/ > > > > > > From owner-ietf-trust-anchor Fri Jun 29 08:20:32 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TFKWn2096180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 08:20:32 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5TFKWeE096179; Fri, 29 Jun 2007 08:20:32 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5TFKVFt096167 for ; Fri, 29 Jun 2007 08:20:31 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200706291520.l5TFKVFt096167@balder-227.proper.com> Received: (qmail 3941 invoked by uid 0); 29 Jun 2007 15:20:27 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.247) by woodstock.binhost.com with SMTP; 29 Jun 2007 15:20:27 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 29 Jun 2007 11:08:47 -0400 To: "Sharon Boeyen" From: Russ Housley Subject: RE: Does the problem need solving? Cc: ietf-trust-anchor@vpnc.org In-Reply-To: <04398A2C9F306C4690265C144089972D01BE75BD@sottexch1.corp.ad .entrust.com> References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> <82D5657AE1F54347A734BDD33637C8790841084B@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75BB@sottexch1.corp.ad.entrust.com> <20070628191034.5A9033E0034@sottsym1.entrust.com> <04398A2C9F306C4690265C144089972D01BE75BD@sottexch1.corp.ad.entrust.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sharon: I am not saying that different applications do not need different path validation input parameters, I was simply trying to illustrate some cases where different trust anchor public keys need different path validation input parameters. That is, we need both. Russ At 03:19 PM 6/28/2007, Sharon Boeyen wrote: >I think the question is how the "tie" is made. I agree that in some >environments let's say enterprise A, you may want to tie such a name >constraint to all uses of that public key by all users and for all apps. >However there are also requirements where the same key may need to have >a name constraint applied to it for the email app but no name constraint >applied to it for a particular web app or a particular set of users may >require one policy (eg high assurance) but another set is ok with medium >or high assurance policy. Its that type of flexibility I'm trying to >retain. How that actually gets achieved is a different question. If, for >example, we end up defining a single structure that includes the key and >all associated restrictions I'd want to ensure that there could be >multiple instances of that same structure for the same key within a >single environment. If we ended up defining a structure for the key and >a separate structure for the restrictions that then get associated with >given users or apps you can still achieve both. I'm not pushing for any >particular mechanism at this point. I just want to ensure the >flexibility is permitted and the requirements make it clear that the >flexibility is needed (as well, of course, as the ability in a given >environment to restrict that flexibility). > >Cheers, >Sharon > >-----Original Message----- >From: Russ Housley [mailto:housley@vigilsec.com] >Sent: Thursday, June 28, 2007 2:56 PM >To: Sharon Boeyen >Cc: ietf-trust-anchor@vpnc.org >Subject: RE: Does the problem need solving? > >Sharon: > >I see situations where I would like to be able to tie them to a key. >For example, name constraints is some think that I would like to enforce >on one key but not another. Similarly, I can imagine wanting to require >explicit policy on one key but not another. > >Russ > >At 02:31 PM 6/28/2007, Sharon Boeyen wrote: > > >I think there is some confusion in interpreting what I "thought" I said > > >because I agree with you. I guess it all depends on your definition of > >a TA (historically I've considered it a trusted public key and DN that > >are used as the root for trust decisions). Using that definition, the > >TA and the initialized path validation variables are both inputs to the > > >path validation process. The comment I sent was only that there are > >environments out there today that do configure those path validation > >variables. It was meant as a response to the last point Paul made in > >his > >message: > > > >----------- > >Paul's point: "There is a large difference between "initialize the path > > >validation parameters" and "can initialize the path validation > >parameters". I know of no popularly-used system that relies on PKIX > >certs that allows any initialization of the path validation parameters. > >I assume that you may know of one or two, but that does not negate what > > >I said above." > >--------------------- > > > >I was not trying to tie them to the trusted public key - in fact I > >believe it makes more sense to enable them to be tailored on a per user > > >or a per application basis regardless of the trusted key (or at least > >allow variations on the set of variable settings for the same key for > >different users/apps. I thought others wanted to tie them to the key, > >not me. Sorry if I confused folks with what I tried to say (I really > >hate email as a communication tool!). > > > >Cheers, > >Sharon > > > >-----Original Message----- > >From: Santosh Chokhani [mailto:chokhani@orionsec.com] > >Sent: Thursday, June 28, 2007 12:52 PM > >To: Sharon Boeyen; Paul Hoffman; Stephen Kent > >Cc: ietf-trust-anchor@vpnc.org > >Subject: RE: Does the problem need solving? > > > >Steve and Sharon, > > > >I am firmly with Paul. 3280 does not require (albeit does not > >prohibit) to associate initial values with a trust anchor which is > >different from associating these with a path validation process. > > > >It is one thing to initialize path validation based on application need > > >and another to associated shades of gray with different TAs used by the > > >RP. > > > >-----Original Message----- > >From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] > >Sent: Thursday, June 28, 2007 10:53 AM > >To: Paul Hoffman; Stephen Kent > >Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org > >Subject: RE: Does the problem need solving? > > > >Paul, fyi there are several such systems in wide deployment today that > >DO initialize path validation variables as cited in RFC 3280. > > > >-----Original Message----- > >From: owner-ietf-trust-anchor@mail.vpnc.org > >[mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul > >Hoffman > >Sent: Thursday, June 28, 2007 10:46 AM > >To: Stephen Kent > >Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org > >Subject: RE: Does the problem need solving? > > > > > >At 9:45 AM -0400 6/28/07, Stephen Kent wrote: > > >At 10:46 AM -0700 6/27/07, Paul Hoffman wrote: > > >>At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote: > > >>>I am talking about associating certificate policies with a TA. I > > >>>am not talking about managing the certificate policies for a CA or >PKI. > > >>> > > >>>Associating certificate policies with a TA is very much relying > > >>>party > > > > >>>decision. The relying party can choose to trust a TA for subset of > > > >>>the policies for a PKI domain. > > >> > > >>Quite right. It's hard for those of us who have been swimming in the > > > >>PKIX waters for so long to remember that the relying party gets to > > >>make his/her own decisions and don't have to rely only on what is in > > > >>a > > > > >>certificate. > > > > > >I'm surprised to hear you say that. > > > > > >PKIX has always operated in the space where RPs select TAs, and > > >initialize the path validation parameters. What aspects of PKIX > > >standards do you believe leads folks to think otherwise? > > > >There is a large difference between "initialize the path validation > >parameters" and "can initialize the path validation parameters". I know > > >of no popularly-used system that relies on PKIX certs that allows any > >initialization of the path validation parameters. I assume that you may > > >know of one or two, but that does not negate what I said above. > > > >--Paul Hoffman, Director > >--VPN Consortium From owner-ietf-trust-anchor Fri Jun 29 08:40:10 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TFeAb5097909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 08:40:10 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5TFeAr7097908; Fri, 29 Jun 2007 08:40:10 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5TFe71K097900 for ; Fri, 29 Jun 2007 08:40:08 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: (qmail 21110 invoked from network); 29 Jun 2007 15:40:04 -0000 Received: from sharon.boeyen@entrust.com by sottccs1.entrust.com with EntrustECS-Server-8.0;29 Jun 2007 15:40:04 -0000 Received: from unknown (HELO sottexch1.corp.ad.entrust.com) (10.4.51.28) by sottccs1.entrust.com with SMTP; 29 Jun 2007 15:40:03 -0000 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" Subject: RE: Does the problem need solving? Date: Fri, 29 Jun 2007 11:40:05 -0400 Message-ID: <04398A2C9F306C4690265C144089972D01BE75C3@sottexch1.corp.ad.entrust.com> In-Reply-To: <200706291520.l5TFKVFt096167@balder-227.proper.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace6YTb9CNcCv8bgTCOb5tVSMJacyQAAnsrg References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> <82D5657AE1F54347A734BDD33637C8790841084B@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75BB@sottexch1.corp.ad.entrust.com> <20070628191034.5A9033E0034@sottsym1.entrust.com> <04398A2C9F306C4690265C144089972D01BE75BD@sottexch1.corp.ad.entrust.com> <200706291520.l5TFKVFt096167@balder-227.proper.com> From: "Sharon Boeyen" To: "Russ Housley" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5TFe91K097903 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think we're in violent agreement and let's blame email for the confusion :-) -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Russ Housley Sent: Friday, June 29, 2007 11:09 AM To: Sharon Boeyen Cc: ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? Sharon: I am not saying that different applications do not need different path validation input parameters, I was simply trying to illustrate some cases where different trust anchor public keys need different path validation input parameters. That is, we need both. Russ At 03:19 PM 6/28/2007, Sharon Boeyen wrote: >I think the question is how the "tie" is made. I agree that in some >environments let's say enterprise A, you may want to tie such a name >constraint to all uses of that public key by all users and for all apps. >However there are also requirements where the same key may need to have >a name constraint applied to it for the email app but no name >constraint applied to it for a particular web app or a particular set >of users may require one policy (eg high assurance) but another set is >ok with medium or high assurance policy. Its that type of flexibility >I'm trying to retain. How that actually gets achieved is a different >question. If, for example, we end up defining a single structure that >includes the key and all associated restrictions I'd want to ensure >that there could be multiple instances of that same structure for the >same key within a single environment. If we ended up defining a >structure for the key and a separate structure for the restrictions >that then get associated with given users or apps you can still achieve >both. I'm not pushing for any particular mechanism at this point. I >just want to ensure the flexibility is permitted and the requirements >make it clear that the flexibility is needed (as well, of course, as >the ability in a given environment to restrict that flexibility). > >Cheers, >Sharon > >-----Original Message----- >From: Russ Housley [mailto:housley@vigilsec.com] >Sent: Thursday, June 28, 2007 2:56 PM >To: Sharon Boeyen >Cc: ietf-trust-anchor@vpnc.org >Subject: RE: Does the problem need solving? > >Sharon: > >I see situations where I would like to be able to tie them to a key. >For example, name constraints is some think that I would like to >enforce on one key but not another. Similarly, I can imagine wanting >to require explicit policy on one key but not another. > >Russ > >At 02:31 PM 6/28/2007, Sharon Boeyen wrote: > > >I think there is some confusion in interpreting what I "thought" I > >said > > >because I agree with you. I guess it all depends on your definition > >of a TA (historically I've considered it a trusted public key and DN > >that are used as the root for trust decisions). Using that > >definition, the TA and the initialized path validation variables are > >both inputs to the > > >path validation process. The comment I sent was only that there are > >environments out there today that do configure those path validation > >variables. It was meant as a response to the last point Paul made in > >his > >message: > > > >----------- > >Paul's point: "There is a large difference between "initialize the > >path > > >validation parameters" and "can initialize the path validation > >parameters". I know of no popularly-used system that relies on PKIX > >certs that allows any initialization of the path validation parameters. > >I assume that you may know of one or two, but that does not negate > >what > > >I said above." > >--------------------- > > > >I was not trying to tie them to the trusted public key - in fact I > >believe it makes more sense to enable them to be tailored on a per > >user > > >or a per application basis regardless of the trusted key (or at least > >allow variations on the set of variable settings for the same key for > >different users/apps. I thought others wanted to tie them to the key, > >not me. Sorry if I confused folks with what I tried to say (I really > >hate email as a communication tool!). > > > >Cheers, > >Sharon > > > >-----Original Message----- > >From: Santosh Chokhani [mailto:chokhani@orionsec.com] > >Sent: Thursday, June 28, 2007 12:52 PM > >To: Sharon Boeyen; Paul Hoffman; Stephen Kent > >Cc: ietf-trust-anchor@vpnc.org > >Subject: RE: Does the problem need solving? > > > >Steve and Sharon, > > > >I am firmly with Paul. 3280 does not require (albeit does not > >prohibit) to associate initial values with a trust anchor which is > >different from associating these with a path validation process. > > > >It is one thing to initialize path validation based on application > >need > > >and another to associated shades of gray with different TAs used by > >the > > >RP. > > > >-----Original Message----- > >From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] > >Sent: Thursday, June 28, 2007 10:53 AM > >To: Paul Hoffman; Stephen Kent > >Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org > >Subject: RE: Does the problem need solving? > > > >Paul, fyi there are several such systems in wide deployment today > >that DO initialize path validation variables as cited in RFC 3280. > > > >-----Original Message----- > >From: owner-ietf-trust-anchor@mail.vpnc.org > >[mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Paul > >Hoffman > >Sent: Thursday, June 28, 2007 10:46 AM > >To: Stephen Kent > >Cc: Santosh Chokhani; ietf-trust-anchor@vpnc.org > >Subject: RE: Does the problem need solving? > > > > > >At 9:45 AM -0400 6/28/07, Stephen Kent wrote: > > >At 10:46 AM -0700 6/27/07, Paul Hoffman wrote: > > >>At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote: > > >>>I am talking about associating certificate policies with a TA. I > > >>>am not talking about managing the certificate policies for a CA > > >>>or >PKI. > > >>> > > >>>Associating certificate policies with a TA is very much relying > > >>>party > > > > >>>decision. The relying party can choose to trust a TA for subset > > >>>of > > > >>>the policies for a PKI domain. > > >> > > >>Quite right. It's hard for those of us who have been swimming in > > >>the > > > >>PKIX waters for so long to remember that the relying party gets to > > >>make his/her own decisions and don't have to rely only on what is > > >>in > > > >>a > > > > >>certificate. > > > > > >I'm surprised to hear you say that. > > > > > >PKIX has always operated in the space where RPs select TAs, and > > >initialize the path validation parameters. What aspects of PKIX > > >standards do you believe leads folks to think otherwise? > > > >There is a large difference between "initialize the path validation > >parameters" and "can initialize the path validation parameters". I > >know > > >of no popularly-used system that relies on PKIX certs that allows any > >initialization of the path validation parameters. I assume that you > >may > > >know of one or two, but that does not negate what I said above. > > > >--Paul Hoffman, Director > >--VPN Consortium From owner-ietf-trust-anchor Fri Jun 29 11:48:31 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TImVoH021709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 11:48:31 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5TImVZS021707; Fri, 29 Jun 2007 11:48:31 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TImSKT021690; Fri, 29 Jun 2007 11:48:31 -0700 (MST) (envelope-from chokhani@orionsec.com) 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" Subject: RE: Does the problem need solving? Date: Fri, 29 Jun 2007 11:47:40 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87908470541@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does the problem need solving? Thread-Index: Ace6O+prz2l1GzjfRCu/ofKY3X0xEAAQglSw References: <82D5657AE1F54347A734BDD33637C87908383C65@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879083CA7BF@EXVS01.ex.dslextreme.net> <04398A2C9F306C4690265C144089972D01BE75B4@sottexch1.corp.ad.entrust.com> <82D5657AE1F54347A734BDD33637C8790841084B@EXVS01.ex.dslextreme.net> From: "Santosh Chokhani" To: "Stephen Kent" Cc: "Sharon Boeyen" , "Paul Hoffman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5TImVKT021696 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steve, I agree. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, June 29, 2007 6:49 AM To: Santosh Chokhani Cc: Sharon Boeyen; Paul Hoffman; ietf-trust-anchor@vpnc.org Subject: RE: Does the problem need solving? At 9:51 AM -0700 6/28/07, Santosh Chokhani wrote: >Steve and Sharon, > >I am firmly with Paul. 3280 does not require (albeit does not prohibit) >to associate initial values with a trust anchor which is different from >associating these with a path validation process. > >It is one thing to initialize path validation based on application need >and another to associated shades of gray with different TAs used by the >RP. > Yo are right that 3280 does not say explicitly that one initializes path validation parameters from a TA. But, these values have to come from somewhere, and I think we agree that in general, these parameters may differ for different TAs. That strongly argues for a capability to bundle the basic TA data wit these parameters. The fact that one usually is not provided with a management interface that allows that is a problem we should try to address under the heading of TA management, Steve From owner-ietf-trust-anchor Fri Jun 29 12:36:01 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TJa1kW026601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 12:36:01 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5TJa1iE026600; Fri, 29 Jun 2007 12:36:01 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TJa09k026588 for ; Fri, 29 Jun 2007 12:36:01 -0700 (MST) (envelope-from chokhani@orionsec.com) 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" Subject: RE: Enterprise-only or more... Date: Fri, 29 Jun 2007 12:35:16 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879084705F8@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise-only or more... Thread-Index: Ace4LOCnWo+Ufun7SDSBsW9Du4HjqQAD6KawAH+WH0AAEf0qYA== References: From: "Santosh Chokhani" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5TJa19k026592 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry for butting in (cutting in). The definition of the Trust Anchor is problematic. The phrase "highest source of trust within a local context" is not clear. More importantly, the meaning I assign to it contradicts the discussion on this list. I would say that a Trust Anchor is a Public key and (optionally or always) an associated name that a relying party trusts for an unlimited scope or a defined scope. Examples of scope are name spaces, certificate policies, application/usage types, and any combination of the above. I also think there is a simpler way to specify the protocol requirements at the top level. We need to define a protocol that can manage these potentially multiple trust anchors that a relying party depends on. By manage, we mean the ability to add, remove or update the trust anchors in the relying party system. The security requirements for the protocol are that the relying party must be able to authenticate the source of trust anchor management information, must be able to ascertain the authority of the authenticated source to update the trust anchor information, and must be able to ascertain that the information has not been changed from what the authenticated source intended. We would also like the protocol so that once the relying party system is initialized with trust anchor information, the protocol can update the trust anchor management information in-band (i.e., without assuming any security beyond that afforded by the protocol itself) securely when one or more (including all) trust anchors have been compromised and hence need to be replaced. -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stefan Santesson Sent: Friday, June 29, 2007 7:35 AM To: Thomas Hardjono; Stephen Kent; Paul Hoffman Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org Subject: RE: Enterprise-only or more... I would like to be slightly more pragmatic. 1) Definition of TA. This is something we need before a BOF. A TA is obviously a public key that is the highest source of trust. The question is for whom and within what context. I think the only reasonable answer is that a TA is always a TA within a local context. What is TA for me may not be a TA for you. We also have different level of trust infrastructures serving each others. We may have a trust management infrastructure based on a trusted directory that uses one TA. This infrastructure may then used to distribute TAs for local applications through a directory based infrastructure. In other cases the security infrastructure is flat (i.e. for some devices) where we resort to manual procedures. Attempt at definition: Trust Anchor: A public key that acts as a highest source of trust within a local context. A TA may also include parameters that constrain the context of trust it is intended to serve. 2) What protocols to standardize In the Enterprise environment a local system using TAs is often subordinate to one ore more management systems with its own security model. This might be a directory centric solution distributing information over a secured network. Example: I bring my device/computer on the physical corporate network where it is initialized through admin passwords or tokens and in that process an number of TAs are imported that makes it possible to communicate remotely in the future with the enterprise network and update TAs for local applications. In the flat device scenario which I assume can be mobile devices, network routers, domain name servers etc, which are not tied to a common database or directory, TA management needs to cover the complete sets of security needs on its own. Common for all scenarios seems to be the potential need for a common format for the TA object itself and the parameters it is associated with. Therefore one candidate for a standard could be a TA object format including: - A public key (in the form of key + key parameters, or a self signed certificate - Optional additional parameters constraining trust in the public key, and - An optional signature There are situations when a self signed certificate is not desired. This is the case when I pick a public key from a trusted CA that I do not control and which self signed root I don't have. What more can we reasonably do? Currently I can't see it. I doubt we can define a generic exchange protocol. - For the device scenario I would suspect that any exchange protocol if necessary need to be defined in a more local application context. E.g. DNS SEC has its own solution and mobile devices have another while wireless access points a third. - For the Enterprise model I would think that the means of exchange will be defined by local directory schemas or databases having their own security model that would be hard to standardize. Is there anything else? Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust- > anchor@mail.vpnc.org] On Behalf Of Thomas Hardjono > Sent: den 27 juni 2007 00:02 > To: Stephen Kent; Paul Hoffman > Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org > Subject: RE: Enterprise-only or more... > > > > > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen > Kent > Sent: Tuesday, June 26, 2007 12:57 PM > To: Paul Hoffman > Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org > Subject: Re: Enterprise-only or more... > > > At 12:40 PM -0700 6/26/07, Paul Hoffman wrote: > >At 1:30 PM +0100 6/22/07, Stephen Farrell wrote: > >>... > > > >If there is one TA admin, and that person is someone other than me, > >then your model does not work. That is, the bank needs to get the > >single TA admin to bless the bank's TA. > > > >If there is more than one TA admin (say, a real TA admin plus the user > >controlling the application), then the bank only needs to convince one > >of the (probably the user) to install the bank's TA. > > > >I think a reasonable requirement is that the protocol allow the client > >to specify more than one TA admins. If that requirement is met, a > >system where the user really does control the system can simply name > >the user as a TA admin. > > There are multiple reasonable models. > > For example, a device may be "owned" by a vendor who delegates to a > user > or local admin the authority to install TAs with certain scope, but not > all TAs. This might be a model for desk top boxes or cell phones. > > In an enterprise context, a local admin may want a similar capability > for himself, delegating some control to individual users, but retaining > ultimate control over TA management for a desktop or laptop. > > Steve > > > Seems to me that we could have several issues/aspects pertaining to > TAs: > > (1) Definition of a TA (ie. structure, syntax, semantics) > (2) Protocol(s) to "manage" TAs (and definition/scope of what we mean > by > the term "manage") > (3) Authorization model (ie. authorization to manage TAs) > (4) Delegation model (i.e. authority-over-TA now delegates portions of > authority or entire authority) > (5) Others... > > The scope of the BOF/WG can easily become very wide, which is why I was > suggesting that the Enterprise use-case may be more manageable :) > > /thomas/ > > > > > > From owner-ietf-trust-anchor Fri Jun 29 13:20:05 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TKK5uC031064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 13:20:05 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5TKK458031062; Fri, 29 Jun 2007 13:20:04 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from nmta3.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.108]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TKK3fC031041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jun 2007 13:20:04 -0700 (MST) (envelope-from hotz@jpl.nasa.gov) Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l5TKK1bK016101 for ; Fri, 29 Jun 2007 13:20:01 -0700 Received: from [137.78.61.96] (laphotz.jpl.nasa.gov [137.78.61.96]) by xmta1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l5TKK05Z024845 for ; Fri, 29 Jun 2007 13:20:00 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20070628192209.G37986@gecko.reptiles.org> <8579AA9D-C6A6-4312-AA23-22C6BDC3C167@jpl.nasa.gov> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Henry B. Hotz" Subject: Re: Does the problem need solving? Date: Fri, 29 Jun 2007 13:19:49 -0700 To: ietf-trust-anchor@vpnc.org X-Mailer: Apple Mail (2.752.3) X-Source-IP: laphotz.jpl.nasa.gov [137.78.61.96] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jun 28, 2007, at 6:30 PM, Paul Hoffman wrote: > At 6:07 PM -0700 6/28/07, Henry B. Hotz wrote: >> Should I trim the CC list to just the list itself? > > Yes. :-) > >> What I think *might* work would be independent TA's for each >> client application (Kerberos/PKINIT, Jabber, Web, etc.), AND a >> generic TA that each client app could optionally reference. The >> generic institutional one might work for Jabber, LDAP, and email. >> Web probably is broader, but references the generic institutional >> one as a subset. Kerberos/PKINIT is tighter and independent of >> the generic one. > > All of this might work, but it is irrelevant. We are proposing to > design a useful protocol, not the end-all-be-all implementation. In > fact, at the moment, we are supposed to be discussing the > *requirements* for the protocol. If our requirements can produce a > protocol that can be the basis of multile useful implementations, > we have succeeded. In the usual formal process you do use cases before requirements or design. I may be suggesting design features, but my real intent is to suggest usage scenarios. If the kind of fragmented, half- hierarchical usage that I describe isn't supported then you're not providing a useful solution IMO. As I implied earlier, I'm profoundly skeptical that a top-level authority as described in *any* current standards will be useful because what's needed is a meta-top level. We need a way to describe which "top"-level authorities (as described with which standards) are authoritative for which purposes, and we probably need some way to say "use this one unless he disqualifies himself, then you can try this one". I don't think you have any idea what protocols are needed (or their complexity) until you know what usage and deployment scenarios you're trying to support. The posted hierarchical list of goals is highly suspect if people are already saying they can't do enough of them to support a realistic deployment. If that's really the case, then we need to revisit the usage scenarios we're trying to address, and find something that's both useful and tractable. So does someone *else* want to propose a usage scenario? ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From owner-ietf-trust-anchor Sat Jun 30 05:15:53 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5UCFqZg006730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jun 2007 05:15:53 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5UCFqVa006729; Sat, 30 Jun 2007 05:15:52 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5UCFpGW006723 for ; Sat, 30 Jun 2007 05:15:52 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 33640 invoked from network); 30 Jun 2007 12:15:47 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.30.90 with login) by smtp108.biz.mail.re2.yahoo.com with SMTP; 30 Jun 2007 12:15:46 -0000 X-YMail-OSG: V4SOQ1gVM1nMwIoAISIU7ET7yUrEYR1Z_GEntwHqYrUrDaVhJHu4g2Tti3AvjpS7CS6PHBOWAnhVgSNqWXN6YEX99DTlX6Jd6G.kwAUT9rQy24JuPQ-- Reply-To: From: "Turner, Sean P." To: References: Subject: RE: Enterprise-only or more... Date: Sat, 30 Jun 2007 08:07:12 -0400 Organization: IECA, Inc. Message-ID: <00f201c7bb0f$31566e80$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace4LOCnWo+Ufun7SDSBsW9Du4HjqQAD6KawAH+WH0AANQxi0A== Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Check out: http://www.ietf.org/internet-drafts/draft-shirey-secgloss-v2-08.txt Page 289. spt -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stefan Santesson Sent: Friday, June 29, 2007 7:35 AM To: Thomas Hardjono; Stephen Kent; Paul Hoffman Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org Subject: RE: Enterprise-only or more... I would like to be slightly more pragmatic. 1) Definition of TA. This is something we need before a BOF. A TA is obviously a public key that is the highest source of trust. The question is for whom and within what context. I think the only reasonable answer is that a TA is always a TA within a local context. What is TA for me may not be a TA for you. We also have different level of trust infrastructures serving each others. We may have a trust management infrastructure based on a trusted directory that uses one TA. This infrastructure may then used to distribute TAs for local applications through a directory based infrastructure. In other cases the security infrastructure is flat (i.e. for some devices) where we resort to manual procedures. Attempt at definition: Trust Anchor: A public key that acts as a highest source of trust within a local context. A TA may also include parameters that constrain the context of trust it is intended to serve. 2) What protocols to standardize In the Enterprise environment a local system using TAs is often subordinate to one ore more management systems with its own security model. This might be a directory centric solution distributing information over a secured network. Example: I bring my device/computer on the physical corporate network where it is initialized through admin passwords or tokens and in that process an number of TAs are imported that makes it possible to communicate remotely in the future with the enterprise network and update TAs for local applications. In the flat device scenario which I assume can be mobile devices, network routers, domain name servers etc, which are not tied to a common database or directory, TA management needs to cover the complete sets of security needs on its own. Common for all scenarios seems to be the potential need for a common format for the TA object itself and the parameters it is associated with. Therefore one candidate for a standard could be a TA object format including: - A public key (in the form of key + key parameters, or a self signed certificate - Optional additional parameters constraining trust in the public key, and - An optional signature There are situations when a self signed certificate is not desired. This is the case when I pick a public key from a trusted CA that I do not control and which self signed root I don't have. What more can we reasonably do? Currently I can't see it. I doubt we can define a generic exchange protocol. - For the device scenario I would suspect that any exchange protocol if necessary need to be defined in a more local application context. E.g. DNS SEC has its own solution and mobile devices have another while wireless access points a third. - For the Enterprise model I would think that the means of exchange will be defined by local directory schemas or databases having their own security model that would be hard to standardize. Is there anything else? Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust- > anchor@mail.vpnc.org] On Behalf Of Thomas Hardjono > Sent: den 27 juni 2007 00:02 > To: Stephen Kent; Paul Hoffman > Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org > Subject: RE: Enterprise-only or more... > > > > > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen > Kent > Sent: Tuesday, June 26, 2007 12:57 PM > To: Paul Hoffman > Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org > Subject: Re: Enterprise-only or more... > > > At 12:40 PM -0700 6/26/07, Paul Hoffman wrote: > >At 1:30 PM +0100 6/22/07, Stephen Farrell wrote: > >>... > > > >If there is one TA admin, and that person is someone other than me, > >then your model does not work. That is, the bank needs to get the > >single TA admin to bless the bank's TA. > > > >If there is more than one TA admin (say, a real TA admin plus the > >user controlling the application), then the bank only needs to > >convince one of the (probably the user) to install the bank's TA. > > > >I think a reasonable requirement is that the protocol allow the > >client to specify more than one TA admins. If that requirement is > >met, a system where the user really does control the system can > >simply name the user as a TA admin. > > There are multiple reasonable models. > > For example, a device may be "owned" by a vendor who delegates to a > user or local admin the authority to install TAs with certain scope, > but not all TAs. This might be a model for desk top boxes or cell > phones. > > In an enterprise context, a local admin may want a similar capability > for himself, delegating some control to individual users, but > retaining ultimate control over TA management for a desktop or laptop. > > Steve > > > Seems to me that we could have several issues/aspects pertaining to > TAs: > > (1) Definition of a TA (ie. structure, syntax, semantics) > (2) Protocol(s) to "manage" TAs (and definition/scope of what we mean > by the term "manage") > (3) Authorization model (ie. authorization to manage TAs) > (4) Delegation model (i.e. authority-over-TA now delegates portions of > authority or entire authority) > (5) Others... > > The scope of the BOF/WG can easily become very wide, which is why I > was suggesting that the Enterprise use-case may be more manageable :) > > /thomas/ > > > > > > From owner-ietf-trust-anchor Sat Jun 30 13:04:13 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5UK4DNo046036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jun 2007 13:04:13 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5UK4DVF046035; Sat, 30 Jun 2007 13:04:13 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mailbox.reptiles.org (mail.reptiles.org [198.96.210.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5UK4CGx045929 for ; Sat, 30 Jun 2007 13:04:12 -0700 (MST) (envelope-from cat@reptiles.org) Received: from mail.reptiles.org ([198.96.210.227] port=62864) by mailbox.reptiles.org([198.96.210.227] port=25) via TCP with esmtp (8323 bytes) (sender: ) (ident using UNIX) id for ; Sat, 30 Jun 2007 16:03:48 -0400 (EDT) (Smail-3.2.0.121 2005-Nov-17 #4 built 2006-Nov-28) Date: Sat, 30 Jun 2007 16:03:45 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@gecko.reptiles.org Reply-To: Cat Okita To: "Turner, Sean P." cc: ietf-trust-anchor@vpnc.org Subject: RE: Enterprise-only or more... In-Reply-To: <00f201c7bb0f$31566e80$0301a8c0@Wylie> Message-ID: <20070630160145.O37986@gecko.reptiles.org> References: <00f201c7bb0f$31566e80$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 30 Jun 2007, Turner, Sean P. wrote: > Check out: > http://www.ietf.org/internet-drafts/draft-shirey-secgloss-v2-08.txt Page To quote: Trust anchor (I) /PKI/ An established point of trust (usually based on the authority of some person, office, or organization) from which a certificate user begins the validation of a certification path. (See: apex trust anchor, path validation, trust anchor CA, trust anchor certificate, trust anchor key.) Usage: IDOCs that use this term SHOULD state a definition for it because it is used in various ways in existing IDOCs and other PKI literature. The literature almost always uses this term in a sense that is equivalent to this definition, but usage often differs with regard to what constitutes the point of trust. I'll grant that it's only a SHOULD to have IDOCs state a definition for TA, but given the discussion on the list, combined with the SHOULD, it seems to me that we SHOULD ;) The quoted definition seems reasonable to me, however. cheers! > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stefan Santesson > Sent: Friday, June 29, 2007 7:35 AM > To: Thomas Hardjono; Stephen Kent; Paul Hoffman > Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org > Subject: RE: Enterprise-only or more... > > > I would like to be slightly more pragmatic. > > 1) Definition of TA. > This is something we need before a BOF. A TA is obviously a public key that > is the highest source of trust. The question is for whom and within what > context. I think the only reasonable answer is that a TA is always a TA > within a local context. What is TA for me may not be a TA for you. > > We also have different level of trust infrastructures serving each others. > We may have a trust management infrastructure based on a trusted directory > that uses one TA. This infrastructure may then used to distribute TAs for > local applications through a directory based infrastructure. In other cases > the security infrastructure is flat (i.e. for some devices) where we resort > to manual procedures. > > Attempt at definition: > Trust Anchor: A public key that acts as a highest source of trust within a > local context. A TA may also include parameters that constrain the context > of trust it is intended to serve. > > > 2) What protocols to standardize > In the Enterprise environment a local system using TAs is often subordinate > to one ore more management systems with its own security model. This might > be a directory centric solution distributing information over a secured > network. Example: I bring my device/computer on the physical corporate > network where it is initialized through admin passwords or tokens and in > that process an number of TAs are imported that makes it possible to > communicate remotely in the future with the enterprise network and update > TAs for local applications. > > In the flat device scenario which I assume can be mobile devices, network > routers, domain name servers etc, which are not tied to a common database or > directory, TA management needs to cover the complete sets of security needs > on its own. > > Common for all scenarios seems to be the potential need for a common format > for the TA object itself and the parameters it is associated with. > > Therefore one candidate for a standard could be a TA object format > including: > - A public key (in the form of key + key parameters, or a self signed > certificate > - Optional additional parameters constraining trust in the public key, and > - An optional signature > > There are situations when a self signed certificate is not desired. This is > the case when I pick a public key from a trusted CA that I do not control > and which self signed root I don't have. > > > What more can we reasonably do? Currently I can't see it. > I doubt we can define a generic exchange protocol. > - For the device scenario I would suspect that any exchange protocol if > necessary need to be defined in a more local application context. E.g. DNS > SEC has its own solution and mobile devices have another while wireless > access points a third. > > - For the Enterprise model I would think that the means of exchange will be > defined by local directory schemas or databases having their own security > model that would be hard to standardize. > > > Is there anything else? > > > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > >> -----Original Message----- >> From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust- >> anchor@mail.vpnc.org] On Behalf Of Thomas Hardjono >> Sent: den 27 juni 2007 00:02 >> To: Stephen Kent; Paul Hoffman >> Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org >> Subject: RE: Enterprise-only or more... >> >> >> >> >> -----Original Message----- >> From: owner-ietf-trust-anchor@mail.vpnc.org >> [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen >> Kent >> Sent: Tuesday, June 26, 2007 12:57 PM >> To: Paul Hoffman >> Cc: Stephen Farrell; ietf-trust-anchor@vpnc.org >> Subject: Re: Enterprise-only or more... >> >> >> At 12:40 PM -0700 6/26/07, Paul Hoffman wrote: >>> At 1:30 PM +0100 6/22/07, Stephen Farrell wrote: >>>> ... >>> >>> If there is one TA admin, and that person is someone other than me, >>> then your model does not work. That is, the bank needs to get the >>> single TA admin to bless the bank's TA. >>> >>> If there is more than one TA admin (say, a real TA admin plus the >>> user controlling the application), then the bank only needs to >>> convince one of the (probably the user) to install the bank's TA. >>> >>> I think a reasonable requirement is that the protocol allow the >>> client to specify more than one TA admins. If that requirement is >>> met, a system where the user really does control the system can >>> simply name the user as a TA admin. >> >> There are multiple reasonable models. >> >> For example, a device may be "owned" by a vendor who delegates to a >> user or local admin the authority to install TAs with certain scope, >> but not all TAs. This might be a model for desk top boxes or cell >> phones. >> >> In an enterprise context, a local admin may want a similar capability >> for himself, delegating some control to individual users, but >> retaining ultimate control over TA management for a desktop or laptop. >> >> Steve >> >> >> Seems to me that we could have several issues/aspects pertaining to >> TAs: >> >> (1) Definition of a TA (ie. structure, syntax, semantics) >> (2) Protocol(s) to "manage" TAs (and definition/scope of what we mean >> by the term "manage") >> (3) Authorization model (ie. authorization to manage TAs) >> (4) Delegation model (i.e. authority-over-TA now delegates portions of >> authority or entire authority) >> (5) Others... >> >> The scope of the BOF/WG can easily become very wide, which is why I >> was suggesting that the Enterprise use-case may be more manageable :) >> >> /thomas/ >> >> >> >> >> >> > > > > ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From owner-ietf-trust-anchor Mon Jul 2 10:55:43 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l62Htg2n071346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 10:55:42 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l62HtgHZ071345; Mon, 2 Jul 2007 10:55:42 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l62HtcPp071329; Mon, 2 Jul 2007 10:55:39 -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 1I5Q7d-0006IZ-58; Mon, 02 Jul 2007 13:55:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 2 Jul 2007 13:55:49 -0400 To: Stefan Santesson From: Stephen Kent Subject: RE: Enterprise-only or more... Cc: Thomas Hardjono , Paul Hoffman , Stephen Farrell , "ietf-trust-anchor@vpnc.org" Content-Type: multipart/alternative; boundary="============_-1028723544==_ma============" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --============_-1028723544==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 12:34 PM +0100 6/29/07, Stefan Santesson wrote: >I would like to be slightly more pragmatic. > >1) Definition of TA. >This is something we need before a BOF. A TA is obviously a public >key that is the highest source of trust. The question is for whom >and within what context. I think the only reasonable answer is that >a TA is always a TA within a local context. What is TA for me may >not be a TA for you. TAs are clearly local. I'd also vote for including more than just the public key, e.g., other path validation initialization parameters, so that one can control path validation relative to each TA. >We also have different level of trust infrastructures serving each >others. We may have a trust management infrastructure based on a >trusted directory that uses one TA. This infrastructure may then >used to distribute TAs for local applications through a directory >based infrastructure. In other cases the security infrastructure is >flat (i.e. for some devices) where we resort to manual procedures. I think folks generally view TAs a peers (that's certainly the browser model), not an ordered list. However, if one wants to use TAs recursively, as part of TA management, one might impose ordering on those TAs. I'd not like to make references to directories at this stage of the discussion, as that may unduly constrain the model for TA distribution. >Attempt at definition: >Trust Anchor: A public key that acts as a highest source of trust >within a local context. A TA may also include parameters that >constrain the context of trust it is intended to serve. I think the path validation parameters are essential, and possibly separate from the scope constraints you note above. >2) What protocols to standardize >In the Enterprise environment a local system using TAs is often >subordinate to one ore more management systems with its own security >model. This might be a directory centric solution distributing >information over a secured network. Example: I bring my >device/computer on the physical corporate network where it is >initialized through admin passwords or tokens and in that process an >number of TAs are imported that makes it possible to communicate >remotely in the future with the enterprise network and update TAs >for local applications. > >In the flat device scenario which I assume can be mobile devices, >network routers, domain name servers etc, which are not tied to a >common database or directory, TA management needs to cover the >complete sets of security needs on its own. In some mobile environments the TA structure probably is not flat. For example, for mobile phones, a vendor may insert a TA, then a service provider might insert a TA to represent its interests, and a user may be allowed to manage TAs for various services (e.g., music download vs. ring tones vs. games, ...) >Common for all scenarios seems to be the potential need for a common >format for the TA object itself and the parameters it is associated >with. agreed. >Therefore one candidate for a standard could be a TA object format including: >- A public key (in the form of key + key parameters, or a self >signed certificate the self-signed cert, while a common format, has several limitations. Specifically, if I want to include cert extensions that might be extracted to initialize path validation, I can't do that with a SS cert. >- Optional additional parameters constraining trust in the public key, and even though the name is trust anchor, I'd like to characterize these parameters in terms of authorization, vs. trust, if folks will let me :-). >- An optional signature > >There are situations when a self signed certificate is not desired. >This is the case when I pick a public key from a trusted CA that I >do not control and which self signed root I don't have. right! >What more can we reasonably do? Currently I can't see it. >I doubt we can define a generic exchange protocol. we could define a signed format for the data, and allow it to be carried via various transports, as we have done for some PKIX protocols. Steve --============_-1028723544==_ma============ Content-Type: text/html; charset="us-ascii" RE: Enterprise-only or more...
At 12:34 PM +0100 6/29/07, Stefan Santesson wrote: