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:
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============-- From owner-ietf-trust-anchor Mon Jul 2 11:46: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 l62Ik3XF077233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 11:46: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 l62Ik3ea077232; Mon, 2 Jul 2007 11:46: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l62IjwlT077222 for ; Mon, 2 Jul 2007 11:46:00 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 13795 invoked from network); 2 Jul 2007 18:44:02 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;02 Jul 2007 18:44:02 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 2 Jul 2007 18:44:02 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Jul 2007 14:45:55 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D100C@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: Enterprise-only or more... Date: Mon, 2 Jul 2007 14:45:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BCD9.392D4C52" 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_01C7BCD9.392D4C52 Content-Type: text/plain > 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. I think we should avoid a definition that focuses on path validation since TAs won't always be used in a path validation context. How about "trust anchors are trusted public keys with associated information"? The associated information could be format-specific. For PKIX purposes, the associated data would include a name and path validation parameters. ------_=_NextPart_001_01C7BCD9.392D4C52 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Enterprise-only or more...

> 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.

I think we should avoid a definition that focuses on = path validation since TAs won't always be used in a path validation = context.  How about "trust anchors are trusted public keys = with associated information"?  The associated information = could be format-specific.  For PKIX purposes, the associated data = would include a name and path validation = parameters.    

------_=_NextPart_001_01C7BCD9.392D4C52-- From owner-ietf-trust-anchor Mon Jul 2 12:36: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 l62JafT6083104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 12:36: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 l62JafjU083103; Mon, 2 Jul 2007 12:36: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 [10.20.30.106] (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 l62JaeJ6083094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Jul 2007 12:36:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D1D100C@scygmxs1.cygnacom.com> References: <886F5D4C78AFB14D87261206BFB9612E1D1D100C@scygmxs1.cygnacom.com> Date: Mon, 2 Jul 2007 12:36:13 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Definition of "trust anchor" 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:45 PM -0400 7/2/07, Carl Wallace wrote: >I think we should avoid a definition that focuses on path validation >since TAs won't always be used in a path validation context. Fully agree. TAs might be used even when there is no authentication of identity associated with a public key, just authorization based on the key being signed by a trust anchor or an intermediate CA. >How about "trust anchors are trusted public keys with associated >information"? The associated information could be format-specific. >For PKIX purposes, the associated data would include a name and path >validation parameters. That's a bit weak. In a chain of TAa <- TAb <- EE, TAb is "trusted", but it is not an anchor. How about: A trust anchor is a public key and associated information that is fully trusted by an application or system to validate other public keys that are signed by the trust anchor. This purposely leaves undefined how chains of length greater than 1 are formed; that should be protocol-specific. It also purposely leaves undefined what one does with the validation information. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Mon Jul 2 12:45:58 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 l62Jjwhw085103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 12:45: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 l62Jjwef085102; Mon, 2 Jul 2007 12:45: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l62JjsBe085090 for ; Mon, 2 Jul 2007 12:45:56 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 14204 invoked from network); 2 Jul 2007 19:43:58 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;02 Jul 2007 19:43:58 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 2 Jul 2007 19:43:58 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Jul 2007 15:45:51 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: Definition of "trust anchor" Date: Mon, 2 Jul 2007 15:45:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BCE1.97F706D6" 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_01C7BCE1.97F706D6 Content-Type: text/plain > >How about "trust anchors are trusted public keys with associated > >information"? The associated information could be format-specific. > >For PKIX purposes, the associated data would include a name and path > >validation parameters. > > That's a bit weak. In a chain of TAa <- TAb <- EE, TAb is > "trusted", but it is not an anchor. OK. > How about: > > A trust anchor is a public key and associated information > that is fully trusted by an application or system to validate > other public keys that are signed by the trust anchor. > > This purposely leaves undefined how chains of length greater > than 1 are formed; that should be protocol-specific. It also > purposely leaves undefined what one does with the validation > information. This doesn't leave open the direct usage of the key to validate signatures that don't cover public keys. Also, I'd prefer "directly" to "fully". A minor edit to your definition: A trust anchor is a public key and associated information that is directly trusted by an application or system to validate digital signatures, including signatures covering other public keys that are signed by the trust anchor. ------_=_NextPart_001_01C7BCE1.97F706D6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Definition of "trust anchor"

> >How about "trust anchors are trusted = public keys with associated
> >information"?  The associated = information could be format-specific.
> >For PKIX purposes, the associated data = would include a name and path
> >validation parameters.
>
> That's a bit weak. In a chain of TAa <- TAb = <- EE, TAb is
> "trusted", but it is not an = anchor.

OK.
 
> How about:
>
> A trust anchor is a public key and associated = information
> that is fully trusted by an application or = system to validate
> other public keys that are signed by the trust = anchor.
>
> This purposely leaves undefined how chains of = length greater
> than 1 are formed; that should be = protocol-specific. It also
> purposely leaves undefined what one does with = the validation
> information.

This doesn't leave open the direct usage of the key = to validate signatures that don't cover public keys.  Also, I'd = prefer "directly" to "fully".  A minor edit to = your definition: A trust anchor is a public key and associated = information that is directly trusted by an application or system to = validate digital signatures, including signatures covering other public = keys that are signed by the trust anchor.

------_=_NextPart_001_01C7BCE1.97F706D6-- From owner-ietf-trust-anchor Mon Jul 2 13:13: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 l62KDZYx088743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 13:13: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 l62KDZ03088742; Mon, 2 Jul 2007 13:13: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.106] (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 l62KDSju088728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 13:13:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> Date: Mon, 2 Jul 2007 13:13:01 -0700 To: Carl Wallace , ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: RE: Definition of "trust anchor" 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:45 PM -0400 7/2/07, Carl Wallace wrote: > > How about: >> >> A trust anchor is a public key and associated information >> that is fully trusted by an application or system to validate >> other public keys that are signed by the trust anchor. >> >> This purposely leaves undefined how chains of length greater >> than 1 are formed; that should be protocol-specific. It also >> purposely leaves undefined what one does with the validation >> information. > >This doesn't leave open the direct usage of the key to validate >signatures that don't cover public keys. Also, I'd prefer >"directly" to "fully". A minor edit to your definition: A trust >anchor is a public key and associated information that is directly >trusted by an application or system to validate digital signatures, >including signatures covering other public keys that are signed by >the trust anchor. Yes, definitely better. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Mon Jul 2 13:52: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 l62Kq638092053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 13:52: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 l62Kq6UZ092052; Mon, 2 Jul 2007 13:52: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l62Kq5M5092046 for ; Mon, 2 Jul 2007 13:52:05 -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 1I5SsM-0003ML-3S; Mon, 02 Jul 2007 16:52:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D1D100C@scygmxs1.cygnacom.com> References: <886F5D4C78AFB14D87261206BFB9612E1D1D100C@scygmxs1.cygnacom.com> Date: Mon, 2 Jul 2007 15:00:18 -0400 To: Carl Wallace 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: At 2:45 PM -0400 7/2/07, Carl Wallace wrote: > > 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. > >I think we should avoid a definition that focuses on path validation >since TAs won't always be used in a path validation context. How >about "trust anchors are trusted public keys with associated >information"? The associated information could be format-specific. >For PKIX purposes, the associated data would include a name and path >validation parameters. If we refine the definition to explicitly include the X.509/PKIX-centric path validation text, I'm OK with that. However, I am curious to hear what non-path validation examples motivate your suggested broadening of the definition. Steve From owner-ietf-trust-anchor Mon Jul 2 14:22: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 l62LMLgC094623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 14:22: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 l62LMLTY094622; Mon, 2 Jul 2007 14:22: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l62LMGdn094613 for ; Mon, 2 Jul 2007 14:22:19 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 14874 invoked from network); 2 Jul 2007 21:20:19 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;02 Jul 2007 21:20:19 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 2 Jul 2007 21:20:19 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Jul 2007 17:22:13 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> From: Carl Wallace To: Stephen Kent Cc: ietf-trust-anchor@vpnc.org Subject: RE: Enterprise-only or more... Date: Mon, 2 Jul 2007 17:22:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BCEF.0DDAA4BC" 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_01C7BCEF.0DDAA4BC Content-Type: text/plain > >I think we should avoid a definition that focuses on path validation > >since TAs won't always be used in a path validation context. > How about > >"trust anchors are trusted public keys with associated > information"? > >The associated information could be format-specific. > >For PKIX purposes, the associated data would include a name and path > >validation parameters. > > If we refine the definition to explicitly include the > X.509/PKIX-centric path validation text, I'm OK with that. > > However, I am curious to hear what non-path validation > examples motivate your suggested broadening of the definition. Timestamps may be signed by a TSA that's directly trusted. Code signing could be performed as a TA instead of as a certificate holder. OCSP response signatures may be validated using a key that's not from a certificate chain. These types of keys should not be used to validate certification paths and don't require certification path validation parameters but it may be good to manage them using a TA mgmt. protocol. ------_=_NextPart_001_01C7BCEF.0DDAA4BC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Enterprise-only or more...

> >I think we should avoid a definition that = focuses on path validation
> >since TAs won't always be used in a path = validation context.
>  How about
> >"trust anchors are trusted public keys = with associated
> information"? 
> >The associated information could be = format-specific.
> >For PKIX purposes, the associated data = would include a name and path
> >validation parameters.    =
>
> If we refine the definition to explicitly = include the
> X.509/PKIX-centric path validation text, I'm OK = with that.
>
> However, I am curious to hear what non-path = validation
> examples motivate your suggested broadening of = the definition.

Timestamps may be signed by a TSA that's directly = trusted.  Code signing could be performed as a TA instead of as a = certificate holder.  OCSP response signatures may be validated = using a key that's not from a certificate chain.  These types of = keys should not be used to validate certification paths and don't = require certification path validation parameters but it may be good to = manage them using a TA mgmt. protocol.

------_=_NextPart_001_01C7BCEF.0DDAA4BC-- From owner-ietf-trust-anchor Mon Jul 2 14:59:29 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 l62LxTHR097739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 14:59:29 -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 l62LxTTY097738; Mon, 2 Jul 2007 14:59: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 l62LxQq8097721; Mon, 2 Jul 2007 14:59:28 -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 1I5TvZ-00041n-4L; Mon, 02 Jul 2007 17:59:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D1D100C@scygmxs1.cygnacom.com> Date: Mon, 2 Jul 2007 17:05:14 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: Definition of "trust anchor" 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 12:36 PM -0700 7/2/07, Paul Hoffman wrote: >At 2:45 PM -0400 7/2/07, Carl Wallace wrote: >>I think we should avoid a definition that focuses on path >>validation since TAs won't always be used in a path validation >>context. > >Fully agree. TAs might be used even when there is no authentication >of identity associated with a public key, just authorization based >on the key being signed by a trust anchor or an intermediate CA. Path validation is relevant to authorization as well as for authentication. For example, the resource PKI that is the current focus of SIDR WG I-Ds is an authorization PKI, not an authentication PKI. The use of the RFC 3779 extension to constrain paths is central to this PKI, and 3779 says that the path validation algorithm must be initialized with the extension value from a TA. > >>How about "trust anchors are trusted public keys with associated >>information"? The associated information could be format-specific. >>For PKIX purposes, the associated data would include a name and >>path validation parameters. > >That's a bit weak. In a chain of TAa <- TAb <- EE, TAb is "trusted", >but it is not an anchor. if TAb is a trust anchor, as the name suggests, then path validation stops there. The arrows you used suggest path discovery to me, not path validation, but maybe I misunderstood your intent. Steve From owner-ietf-trust-anchor Mon Jul 2 15:06: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 l62M6RfB098394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 15:06: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 l62M6Rc5098393; Mon, 2 Jul 2007 15:06: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 l62M6QOL098386 for ; Mon, 2 Jul 2007 15:06:27 -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 1I5U2M-00048Q-4Q; Mon, 02 Jul 2007 18:06:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> References: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> Date: Mon, 2 Jul 2007 18:05:33 -0400 To: Carl Wallace 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: At 5:22 PM -0400 7/2/07, Carl Wallace wrote: > > >I think we should avoid a definition that focuses on path validation >> >since TAs won't always be used in a path validation context. >> How about >> >"trust anchors are trusted public keys with associated >> information"? >> >The associated information could be format-specific. >> >For PKIX purposes, the associated data would include a name and path >> >validation parameters. >> >> If we refine the definition to explicitly include the >> X.509/PKIX-centric path validation text, I'm OK with that. >> >> However, I am curious to hear what non-path validation >> examples motivate your suggested broadening of the definition. > >Timestamps may be signed by a TSA that's directly trusted. Code >signing could be performed as a TA instead of as a certificate >holder. OCSP response signatures may be validated using a key >that's not from a certificate chain. These types of keys should not >be used to validate certification paths and don't require >certification path validation parameters but it may be good to >manage them using a TA mgmt. protocol. Carl, Thanks for the examples from existing standards. These provide a good rationale for needing constraints on how the TAs are used, even though they are not path validation constraints. Steve From owner-ietf-trust-anchor Mon Jul 2 15:17: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 l62MHDn5099602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 15:17: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 l62MHDJf099601; Mon, 2 Jul 2007 15:17: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 [10.20.30.106] (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 l62MH1JT099581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 15:17:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D1D100C@scygmxs1.cygnacom.com> Date: Mon, 2 Jul 2007 15:16:33 -0700 To: Stephen Kent From: Paul Hoffman Subject: Re: Definition of "trust anchor" 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 5:05 PM -0400 7/2/07, Stephen Kent wrote: >At 12:36 PM -0700 7/2/07, Paul Hoffman wrote: >>At 2:45 PM -0400 7/2/07, Carl Wallace wrote: >>>I think we should avoid a definition that focuses on path >>>validation since TAs won't always be used in a path validation >>>context. >> >>Fully agree. TAs might be used even when there is no authentication >>of identity associated with a public key, just authorization based >>on the key being signed by a trust anchor or an intermediate CA. > >Path validation is relevant to authorization as well as for >authentication. For example, the resource PKI that is the current >focus of SIDR WG I-Ds is an authorization PKI, not an authentication >PKI. The use of the RFC 3779 extension to constrain paths is >central to this PKI, and 3779 says that the path validation >algorithm must be initialized with the extension value from a TA. The point is that you do not need path validation with a trust anchor. There are scenarios that use trust anchors that do not use path validation. Path validation should not be part of the definition. >>>How about "trust anchors are trusted public keys with associated >>>information"? The associated information could be >>>format-specific. For PKIX purposes, the associated data would >>>include a name and path validation parameters. >> >>That's a bit weak. In a chain of TAa <- TAb <- EE, TAb is >>"trusted", but it is not an anchor. > >if TAb is a trust anchor, as the name suggests, then path validation >stops there. The arrows you used suggest path discovery to me, not >path validation, but maybe I misunderstood your intent. Erps, yes. The chain should have been TAa <- CAb <- EE. CAb is "trusted", but it is not an anchor. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Mon Jul 2 15:20: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 l62MKixB099970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 15:20: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 l62MKi3G099969; Mon, 2 Jul 2007 15:20: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 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 l62MKhrM099960 for ; Mon, 2 Jul 2007 15:20:43 -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: Mon, 2 Jul 2007 15:20:02 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879084EFB8B@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise-only or more... Thread-Index: Ace89cxLwOnZAnd0TSWND+TvEurchAAAS9ag References: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> From: "Santosh Chokhani" To: "Stephen Kent" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l62MKhrM099964 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steve, I am resending the text I posted to the list over the weekend. I wonder if any one read it or found it useful. "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 Stephen Kent Sent: Monday, July 02, 2007 6:06 PM To: Carl Wallace Cc: ietf-trust-anchor@vpnc.org Subject: RE: Enterprise-only or more... At 5:22 PM -0400 7/2/07, Carl Wallace wrote: > > >I think we should avoid a definition that focuses on path validation >> >since TAs won't always be used in a path validation context. >> How about >> >"trust anchors are trusted public keys with associated >> information"? >> >The associated information could be format-specific. >> >For PKIX purposes, the associated data would include a name and path >> >validation parameters. >> >> If we refine the definition to explicitly include the >> X.509/PKIX-centric path validation text, I'm OK with that. >> >> However, I am curious to hear what non-path validation >> examples motivate your suggested broadening of the definition. > >Timestamps may be signed by a TSA that's directly trusted. Code >signing could be performed as a TA instead of as a certificate >holder. OCSP response signatures may be validated using a key >that's not from a certificate chain. These types of keys should not >be used to validate certification paths and don't require >certification path validation parameters but it may be good to >manage them using a TA mgmt. protocol. Carl, Thanks for the examples from existing standards. These provide a good rationale for needing constraints on how the TAs are used, even though they are not path validation constraints. Steve From owner-ietf-trust-anchor Mon Jul 2 15:22:50 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 l62MMoDS000283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 15:22:50 -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 l62MMoTc000282; Mon, 2 Jul 2007 15:22:50 -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 l62MMlgY000266; Mon, 2 Jul 2007 15:22:49 -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 1I5UIA-0004Im-5i; Mon, 02 Jul 2007 18:22:46 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D1D100C@scygmxs1.cygnacom.com> Date: Mon, 2 Jul 2007 18:22:53 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: Definition of "trust anchor" 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:16 PM -0700 7/2/07, Paul Hoffman wrote: >>... > >The point is that you do not need path validation with a trust >anchor. There are scenarios that use trust anchors that do not use >path validation. Path validation should not be part of the >definition. I agree with the point, just not the rationale you provided in the message. Done. > >>>>How about "trust anchors are trusted public keys with associated >>>>information"? The associated information could be >>>>format-specific. For PKIX purposes, the associated data would >>>>include a name and path validation parameters. >>> >>>That's a bit weak. In a chain of TAa <- TAb <- EE, TAb is >>>"trusted", but it is not an anchor. >> >>if TAb is a trust anchor, as the name suggests, then path >>validation stops there. The arrows you used suggest path discovery >>to me, not path validation, but maybe I misunderstood your intent. > >Erps, yes. The chain should have been TAa <- CAb <- EE. CAb is >"trusted", but it is not an anchor. Thanks for the nomenclature clarification. Still, the arrows seem to go "up" and path validation (vs. discovery) goes "down." Why did you choose to use up vs. down arrows in the example. Steve From owner-ietf-trust-anchor Mon Jul 2 15:56: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 l62MuqNj002510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 15:56: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 l62Muq2u002509; Mon, 2 Jul 2007 15:56: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 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 l62Mupxo002503 for ; Mon, 2 Jul 2007 15:56:51 -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: multipart/alternative; boundary="----_=_NextPart_001_01C7BCFC.53B6EB5D" Subject: RE: Enterprise-only or more... Date: Mon, 2 Jul 2007 15:57:11 -0700 Message-ID: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise-only or more... Thread-Index: Ace88A1I9hjS/va0SGiiOg3Fs9ImugAC6pJA From: "Thomas Hardjono" To: "Carl Wallace" , "Stephen Kent" Cc: 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_01C7BCFC.53B6EB5D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Carl Wallace Sent: Monday, July 02, 2007 2:22 PM To: Stephen Kent Cc: ietf-trust-anchor@vpnc.org Subject: RE: Enterprise-only or more... =09 =09 > >I think we should avoid a definition that focuses on path validation=20 > >since TAs won't always be used in a path validation context.=20 > How about=20 > >"trust anchors are trusted public keys with associated=20 > information"? =20 > >The associated information could be format-specific.=20 > >For PKIX purposes, the associated data would include a name and path=20 > >validation parameters. =20 >=20 > If we refine the definition to explicitly include the=20 > X.509/PKIX-centric path validation text, I'm OK with that.=20 >=20 > However, I am curious to hear what non-path validation=20 > examples motivate your suggested broadening of the definition. Timestamps may be signed by a TSA that's directly trusted. Code signing could be performed as a TA instead of as a certificate holder. OCSP response signatures may be validated using a key that's not from a certificate chain. These types of keys should not be used to validate certification paths and don't require certification path validation parameters but it may be good to manage them using a TA mgmt. protocol. =20 Carl, =20 I have a question about managing TAs. =20 What kind of proof is needed to show:=20 (i) that a TA has been correctly installed (at some=20 secure cert store on a client/end-point), and=20 (ii) that an Application (configured to accept that TA) is now truly operating on the basis of that installed=20 TA (and not on some unauthorized TAs)? =20 /thomas/ =20 =20 =20 =20 =20 ------_=_NextPart_001_01C7BCFC.53B6EB5D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Enterprise-only or more...

From: = owner-ietf-trust-anchor@mail.vpnc.org=20 [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of = Carl=20 Wallace
Sent: Monday, July 02, 2007 2:22 PM
To: = Stephen=20 Kent
Cc: ietf-trust-anchor@vpnc.org
Subject: RE:=20 Enterprise-only or more...

> >I think we should avoid a definition that = focuses on=20 path validation
> >since TAs won't = always be=20 used in a path validation context.
>  How=20 about
> >"trust anchors are trusted = public keys=20 with associated
> information"? =20
> >The associated information could be = format-specific.
> >For PKIX purposes, = the=20 associated data would include a name and path
>=20 >validation parameters.   
>=20
> If we refine the definition to = explicitly include=20 the
> X.509/PKIX-centric path validation = text, I'm=20 OK with that.
>
>=20 However, I am curious to hear what non-path validation =
> examples motivate your suggested broadening of the=20 definition.

Timestamps may be signed by a TSA that's directly=20 trusted.  Code signing could be performed as a TA instead of as a = certificate holder.  OCSP response signatures may be validated = using a=20 key that's not from a certificate chain.  These types of keys = should not=20 be used to validate certification paths and don't require = certification path=20 validation parameters but it may be good to manage them using a TA = mgmt.=20 protocol.  

=
 
Carl,
 
I have a question about managing=20 TAs.
 
What kind of proof is needed to show:=20
   (i) that a TA has been correctly = installed=20 (at some
       secure cert store on a = client/end-point), and
   (ii) that an Application = (configured to=20 accept that TA) is
       now = truly=20 operating on the basis of that installed
       TA (and = not on=20 some unauthorized TAs)?
 
/thomas/
 
 
 
 
 
------_=_NextPart_001_01C7BCFC.53B6EB5D-- From owner-ietf-trust-anchor Mon Jul 2 16:03: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 l62N3hhr002994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 16:03: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 l62N3hWu002993; Mon, 2 Jul 2007 16:03: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 [10.20.30.106] (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 l62N3U7F002965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 16:03:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D1D100C@scygmxs1.cygnacom.com> Date: Mon, 2 Jul 2007 16:03:02 -0700 To: Stephen Kent From: Paul Hoffman Subject: Re: Definition of "trust anchor" 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:22 PM -0400 7/2/07, Stephen Kent wrote: >>Erps, yes. The chain should have been TAa <- CAb <- EE. CAb is >>"trusted", but it is not an anchor. > >Thanks for the nomenclature clarification. > >Still, the arrows seem to go "up" and path validation (vs. >discovery) goes "down." Why did you choose to use up vs. down >arrows in the example. I think in terms of the relying party trying to validate a signature. You might think in terms of a CA/TA trying to help the relying party. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jul 3 07:49: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 l63EnWDJ089686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 07:49: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 l63EnWdt089685; Tue, 3 Jul 2007 07:49: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l63EnULY089669 for ; Tue, 3 Jul 2007 07:49:30 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 22507 invoked from network); 3 Jul 2007 14:47:33 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;03 Jul 2007 14:47:33 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 3 Jul 2007 14:47:33 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Jul 2007 10:49:29 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D106D@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org, Thomas Hardjono Subject: RE: Enterprise-only or more... Date: Tue, 3 Jul 2007 10:49:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BD81.566CE24A" 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_01C7BD81.566CE24A Content-Type: text/plain Carl, I have a question about managing TAs. What kind of proof is needed to show: (i) that a TA has been correctly installed (at some secure cert store on a client/end-point), and This is to-be-determined by the BOF/working group. I assume digital signatures verified using a previously installed key will play a role to ensure the integrity of the TA received by the client. To confirm the key was installed correctly, a report generated by the client could be generated. (ii) that an Application (configured to accept that TA) is now truly operating on the basis of that installed TA (and not on some unauthorized TAs)? Beyond report generation, this is probably beyond our scope. /thomas/ ------_=_NextPart_001_01C7BD81.566CE24A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Enterprise-only or more...

        Carl,
         =
        I have a = question about managing TAs.
         =
        What kind = of proof is needed to show:
           (i) that a TA has been correctly installed (at = some
               secure cert store on a = client/end-point), and

This is to-be-determined by the BOF/working = group.  I assume digital signatures verified using a previously = installed key will play a role to ensure the integrity of the TA = received by the client.  To confirm the key was installed = correctly, a report generated by the client could be generated.  =

           (ii) that an Application (configured to accept = that TA) is
               now truly operating on = the basis of that installed
               TA (and not on some = unauthorized TAs)?

Beyond report generation, this is probably beyond our = scope. 
         =
        /thomas/
         =
         =
         =
         =

------_=_NextPart_001_01C7BD81.566CE24A-- From owner-ietf-trust-anchor Tue Jul 3 09:25:29 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 l63GPTbY098616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 09:25:29 -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 l63GPTJV098615; Tue, 3 Jul 2007 09:25: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 [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 l63GPRM2098608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Jul 2007 09:25:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 3 Jul 2007 09:24:59 -0700 To: From: Paul Hoffman Subject: Correct operation with TAs 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:57 PM -0700 7/2/07, Thomas Hardjono wrote: >What kind of proof is needed to show: > (i) that a TA has been correctly installed (at some > secure cert store on a client/end-point), and > (ii) that an Application (configured to accept that TA) is > now truly operating on the basis of that installed > TA (and not on some unauthorized TAs)? Why is any proof needed? It seems pretty intractable to show "correctly" installed and "truly" operating. I could see some way for an application to say "here are the TAs I am using currently", but proving that they are using them in some prescribed way seems well outside of protocol land. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jul 3 10:49: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 l63HnQsb007522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 10:49: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 l63HnQh8007519; Tue, 3 Jul 2007 10:49: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l63HnO2g007497 for ; Tue, 3 Jul 2007 10:49:24 -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 1I5mV8-0000Ux-6F; Tue, 03 Jul 2007 13:49:23 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <00f201c7bb0f$31566e80$0301a8c0@Wylie> References: <00f201c7bb0f$31566e80$0301a8c0@Wylie> Date: Tue, 3 Jul 2007 13:39:25 -0400 To: Stefan Santesson From: Stephen Kent Subject: RE: Enterprise-only or more... 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: Stefan, >... >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. I'd like to minimize the use of the term trust in our definition, if possible. The term refers a fuzzy, non-quantifiable, human value judgement. We are developing standards that have discrete outputs, usually binary, i.e., valid or not. So, if we can talk about validation of a signature of a signed object, that's preferable. So, for example, we might say: Trust Anchor: A public key and associated data used by a relying party to validate a signature on a signed object where the object is either - a cert that begins a cert validation path - a non-cert object that cannot be validated via use of a cert path Trust anchors have local significance, i.e., each RP is configured with a set of trust anchors, either by the RP or by an entity that manages TAs in the context on which the RP operates. Each TA also has a defined scope, that constraints the set of signed objects verifiable under the TA. >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 I'd prefer to use a term like "scope of the TA" rather than "trust." >- 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. the words here are confusing to me. I assume the intent is to say that a self-signed cert is not always the preferred format for a TA, because the public key may be associated with an entity that either did not create a self-signed cert, or the contents of that cert are inconsistent with the parameters that the RP wishes to bind to the public key (for use as a TA). Steve From owner-ietf-trust-anchor Tue Jul 3 11:49: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 l63InfHg012886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 11:49: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 l63InfS6012885; Tue, 3 Jul 2007 11:49: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l63IndIB012878 for ; Tue, 3 Jul 2007 11:49:40 -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 1I5nRS-0001eL-3q; Tue, 03 Jul 2007 14:49:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <82D5657AE1F54347A734BDD33637C879084EFB8B@EXVS01.ex.dslextreme.net> References: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879084EFB8B@EXVS01.ex.dslextreme.net> Date: Tue, 3 Jul 2007 14:49:45 -0400 To: "Santosh Chokhani" From: Stephen Kent Subject: RE: Enterprise-only or more... 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 3:20 PM -0700 7/2/07, Santosh Chokhani wrote: >Steve, > >I am resending the text I posted to the list over the weekend. I wonder >if any one read it or found it useful. > > >"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 agree, hence my revised definition in a message earlier today. >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 don't even like using the word "trust" here. Lety me know if you think my suggested definition is a step in the right direction. >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. agreed. >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. all reasonable requirements. There may be more that folks will want, but this is certainly a solid starting set. >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." agreed. Steve From owner-ietf-trust-anchor Tue Jul 3 14:18: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 l63LIKKs027807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 14:18: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 l63LIKaI027806; Tue, 3 Jul 2007 14:18:20 -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 l63LIIdc027797 for ; Tue, 3 Jul 2007 14:18:20 -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: Tue, 3 Jul 2007 14:17:37 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879084F05D7@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise-only or more... Thread-Index: Ace9owaQEmDxM+LET0unu12kWisqpgAFDdqg References: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879084EFB8B@EXVS01.ex.dslextreme.net> From: "Santosh Chokhani" To: "Stephen Kent" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l63LIKdc027801 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steve, How about the following for a Trust Anchor Definition. A Trust Anchor is a Public key and associated information that a relying party uses for signature verification. If the trust anchor is limited in scope, the associated information includes the scope. Examples of scope are name spaces, certificate policies, application/usage types, and any combination of the above. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, July 03, 2007 2:50 PM To: Santosh Chokhani Cc: ietf-trust-anchor@vpnc.org Subject: RE: Enterprise-only or more... At 3:20 PM -0700 7/2/07, Santosh Chokhani wrote: >Steve, > >I am resending the text I posted to the list over the weekend. I wonder >if any one read it or found it useful. > > >"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 agree, hence my revised definition in a message earlier today. >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 don't even like using the word "trust" here. Lety me know if you think my suggested definition is a step in the right direction. >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. agreed. >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. all reasonable requirements. There may be more that folks will want, but this is certainly a solid starting set. >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." agreed. Steve From owner-ietf-trust-anchor Tue Jul 3 14:32: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 l63LWc22030743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 14:32: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 l63LWcGm030742; Tue, 3 Jul 2007 14:32: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 sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l63LWbIQ030722 for ; Tue, 3 Jul 2007 14:32:37 -0700 (MST) (envelope-from pritikin@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 03 Jul 2007 14:32:35 -0700 X-IronPort-AV: i="4.16,494,1175497200"; d="scan'208"; a="6449510:sNHT23883714" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l63LWZjF032094; Tue, 3 Jul 2007 14:32:35 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l63LWSkc010540; Tue, 3 Jul 2007 21:32:28 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 14:32:22 -0700 Received: from [10.32.244.67] ([10.32.244.67]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 14:32:22 -0700 In-Reply-To: <82D5657AE1F54347A734BDD33637C879084F05D7@EXVS01.ex.dslextreme.net> References: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879084EFB8B@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879084F05D7@EXVS01.ex.dslextreme.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7908B207-A42A-4BE0-9EDD-E192B41C9C4A@cisco.com> Cc: "Stephen Kent" , Content-Transfer-Encoding: 7bit From: Max Pritikin Subject: Re: Enterprise-only or more... Date: Tue, 3 Jul 2007 16:32:20 -0500 To: "Santosh Chokhani" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Jul 2007 21:32:22.0460 (UTC) FILETIME=[A430A7C0:01C7BDB9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3299; t=1183498355; x=1184362355; 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=20Enterprise-only=20or=20more... |Sender:=20; bh=WkI6nremHJkuoN4nXFMV09yzGny6jsbDrbyxjsCrtFY=; b=SfTuZxrm4S36nCy5fQabGPZr540eF4zO4jBJQi5dRaCANzCThBFdxBMDM5Qv+LuQPvy18nb5 VsyoIbiNI4F496aJX28CL3D9AH0SpGorKr7nw/8bdVdphngP8LdDT3cbSiSbnAMtHz8ibNuT/y cnaZ5kvYoFQ/6dQxFQHrWWq3g=; 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: This is fine for defining the trust anchor as a (single) public key. The problem statement discusses "managing one or more sets of trust anchors" which leads me to wonder -- is the scope to manage a bundle/ list/set of these trust anchors or just one individual anchor? - max On Jul 3, 2007, at 4:17 PM, Santosh Chokhani wrote: > > Steve, > > How about the following for a Trust Anchor Definition. > > A Trust Anchor is a Public key and associated information that a > relying > party uses for signature verification. If the trust anchor is limited > in scope, the associated information includes the scope. Examples of > scope are name spaces, certificate policies, application/usage types, > and any combination of the above. > > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, July 03, 2007 2:50 PM > To: Santosh Chokhani > Cc: ietf-trust-anchor@vpnc.org > Subject: RE: Enterprise-only or more... > > At 3:20 PM -0700 7/2/07, Santosh Chokhani wrote: >> Steve, >> >> I am resending the text I posted to the list over the weekend. I > wonder >> if any one read it or found it useful. >> >> >> "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 agree, hence my revised definition in a message earlier today. > >> 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 don't even like using the word "trust" here. Lety me know if you > think my suggested definition is a step in the right direction. > >> 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. > > agreed. > >> 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. > > all reasonable requirements. There may be more that folks will want, > but this is certainly a solid starting set. > >> 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." > > agreed. > > Steve From owner-ietf-trust-anchor Tue Jul 3 16:18: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 l63NIO8D042589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 16:18: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 l63NIONb042588; Tue, 3 Jul 2007 16:18: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 mailbox.reptiles.org (mail.reptiles.org [198.96.210.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l63NIJZ4042569 for ; Tue, 3 Jul 2007 16:18:21 -0700 (MST) (envelope-from cat@reptiles.org) Received: from mail.reptiles.org ([198.96.210.227] port=64756) by mailbox.reptiles.org([198.96.210.227] port=25) via TCP with esmtp (4902 bytes) (sender: ) (ident using UNIX) id for ; Tue, 3 Jul 2007 19:18:00 -0400 (EDT) (Smail-3.2.0.121 2005-Nov-17 #4 built 2006-Nov-28) Date: Tue, 3 Jul 2007 19:17:59 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@gecko.reptiles.org Reply-To: Cat Okita To: Max Pritikin cc: Santosh Chokhani , Stephen Kent , ietf-trust-anchor@vpnc.org Subject: Re: Enterprise-only or more... In-Reply-To: <7908B207-A42A-4BE0-9EDD-E192B41C9C4A@cisco.com> Message-ID: <20070703191716.I37986@gecko.reptiles.org> References: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879084EFB8B@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879084F05D7@EXVS01.ex.dslextreme.net> <7908B207-A42A-4BE0-9EDD-E192B41C9C4A@cisco.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, 3 Jul 2007, Max Pritikin wrote: > This is fine for defining the trust anchor as a (single) public key. The > problem statement discusses "managing one or more sets of trust anchors" > which leads me to wonder -- is the scope to manage a bundle/list/set of these > trust anchors or just one individual anchor? I'd say that this endeavour is pointless if we aren't intending to have management of multiple sets of trust anchors be in scope. cheers! > On Jul 3, 2007, at 4:17 PM, Santosh Chokhani wrote: > >> >> Steve, >> >> How about the following for a Trust Anchor Definition. >> >> A Trust Anchor is a Public key and associated information that a relying >> party uses for signature verification. If the trust anchor is limited >> in scope, the associated information includes the scope. Examples of >> scope are name spaces, certificate policies, application/usage types, >> and any combination of the above. >> >> -----Original Message----- >> From: Stephen Kent [mailto:kent@bbn.com] >> Sent: Tuesday, July 03, 2007 2:50 PM >> To: Santosh Chokhani >> Cc: ietf-trust-anchor@vpnc.org >> Subject: RE: Enterprise-only or more... >> >> At 3:20 PM -0700 7/2/07, Santosh Chokhani wrote: >>> Steve, >>> >>> I am resending the text I posted to the list over the weekend. I >> wonder >>> if any one read it or found it useful. >>> >>> >>> "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 agree, hence my revised definition in a message earlier today. >> >>> 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 don't even like using the word "trust" here. Lety me know if you >> think my suggested definition is a step in the right direction. >> >>> 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. >> >> agreed. >> >>> 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. >> >> all reasonable requirements. There may be more that folks will want, >> but this is certainly a solid starting set. >> >>> 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." >> >> agreed. >> >> Steve ========================================================================== "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 Jul 3 16:42: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 l63NgmJ2045062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 16:42: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 l63NgmWD045061; Tue, 3 Jul 2007 16:42: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 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 l63Ngka2045054 for ; Tue, 3 Jul 2007 16:42:47 -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, 3 Jul 2007 16:43:07 -0700 Message-ID: In-Reply-To: <7908B207-A42A-4BE0-9EDD-E192B41C9C4A@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise-only or more... Thread-Index: Ace9umDXXhHoqSngSkWwCWNcc2QgCgAD21lg From: "Thomas Hardjono" To: "Max Pritikin" , "Santosh Chokhani" Cc: "Stephen Kent" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l63Ngla2045056 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think the definition of a TA should be for one (1) operational public key. Here "operational" means that it is used for/by applications. Maybe, for self-management purposes, a second limited-use public key could be added (eg. used by the management authority to (remotely) replace/update one TA with a new TA). But that 2nd key must not be readable by applications (ie. encrypted). If I need to install/delete multiple TAs, I should just run the same protocol multiple times. /thomas/ > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of > Max Pritikin > Sent: Tuesday, July 03, 2007 2:32 PM > To: Santosh Chokhani > Cc: Stephen Kent; ietf-trust-anchor@vpnc.org > Subject: Re: Enterprise-only or more... > > > > This is fine for defining the trust anchor as a (single) public key. > The problem statement discusses "managing one or more sets of > trust anchors" which leads me to wonder -- is the scope to > manage a bundle/ list/set of these trust anchors or just one > individual anchor? > > - max > > On Jul 3, 2007, at 4:17 PM, Santosh Chokhani wrote: > > > > > Steve, > > > > How about the following for a Trust Anchor Definition. > > > > A Trust Anchor is a Public key and associated information that a > > relying party uses for signature verification. If the > trust anchor is > > limited in scope, the associated information includes the scope. > > Examples of scope are name spaces, certificate policies, > > application/usage types, and any combination of the above. > > > > -----Original Message----- > > From: Stephen Kent [mailto:kent@bbn.com] > > Sent: Tuesday, July 03, 2007 2:50 PM > > To: Santosh Chokhani > > Cc: ietf-trust-anchor@vpnc.org > > Subject: RE: Enterprise-only or more... > > > > At 3:20 PM -0700 7/2/07, Santosh Chokhani wrote: > >> Steve, > >> > >> I am resending the text I posted to the list over the weekend. I > > wonder > >> if any one read it or found it useful. > >> > >> > >> "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 agree, hence my revised definition in a message earlier today. > > > >> 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 don't even like using the word "trust" here. Lety me know if you > > think my suggested definition is a step in the right direction. > > > >> 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. > > > > agreed. > > > >> 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. > > > > all reasonable requirements. There may be more that folks > will want, > > but this is certainly a solid starting set. > > > >> 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." > > > > agreed. > > > > Steve > > From owner-ietf-trust-anchor Tue Jul 3 16:47: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 l63Nlxkg045551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 16:47:59 -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 l63NlxRO045550; Tue, 3 Jul 2007 16:47:59 -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-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l63NlwtD045543 for ; Tue, 3 Jul 2007 16:47:58 -0700 (MST) (envelope-from pritikin@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Jul 2007 16:47:58 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEp9ikarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,494,1175497200"; d="scan'208"; a="176326684:sNHT30594438" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l63NlvFr028756; Tue, 3 Jul 2007 16:47:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l63Nlpvx027231; Tue, 3 Jul 2007 23:47:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 16:47:51 -0700 Received: from [10.32.244.67] ([10.32.244.67]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 16:47:50 -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: <781FEAFE-3D9C-4722-BBAE-8D968B9354AA@cisco.com> Cc: "Santosh Chokhani" , "Stephen Kent" , Content-Transfer-Encoding: 7bit From: Max Pritikin Subject: Re: Enterprise-only or more... Date: Tue, 3 Jul 2007 18:47:48 -0500 To: "Thomas Hardjono" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Jul 2007 23:47:50.0643 (UTC) FILETIME=[90F6F430:01C7BDCC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4914; t=1183506477; x=1184370477; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20Max=20Pritikin=20 |Subject:=20Re=3A=20Enterprise-only=20or=20more... |Sender:=20; bh=2rmuwkdRA5VV1/wu2Xl7NhsSGL/S9W+U6Egj1aqyjFo=; b=EF07WGxu7dMuCZHYDLpnycaxBU/pmBg9T8YJNwhy/i8YIFC4YQwYjuXTHTZE5AtDGV8wDoJk jH0+VTZktPcycFR4kyO0V8liu0neBI602QE428I3b0RXRjpZBF+CiSYf; Authentication-Results: sj-dkim-3; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: If we take a web browser as one sample application we see one set of multiple trust anchors that must be managed (together). I don't think it would be appropriate to have to run multiple instances of the management protocol to do this. Additionally, On Jul 3, 2007, at 6:43 PM, Thomas Hardjono wrote: > > I think the definition of a TA should be for one (1) operational > public > key. Here "operational" means that it is used for/by applications. > > Maybe, for self-management purposes, a second limited-use public key > could be added (eg. used by the management authority to (remotely) > replace/update one TA with a new TA). But that 2nd key must not be > readable by applications (ie. encrypted). What you describe here is very valid scenario -- but if we don't consider management of the entire set of TA's how are we different than any of the existing enrollment/certificate-management protocols that have already not taken off? - max > > If I need to install/delete multiple TAs, I should just run the same > protocol multiple times. > > /thomas/ > > > >> -----Original Message----- >> From: owner-ietf-trust-anchor@mail.vpnc.org >> [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of >> Max Pritikin >> Sent: Tuesday, July 03, 2007 2:32 PM >> To: Santosh Chokhani >> Cc: Stephen Kent; ietf-trust-anchor@vpnc.org >> Subject: Re: Enterprise-only or more... >> >> >> >> This is fine for defining the trust anchor as a (single) public key. >> The problem statement discusses "managing one or more sets of >> trust anchors" which leads me to wonder -- is the scope to >> manage a bundle/ list/set of these trust anchors or just one >> individual anchor? >> >> - max >> >> On Jul 3, 2007, at 4:17 PM, Santosh Chokhani wrote: >> >>> >>> Steve, >>> >>> How about the following for a Trust Anchor Definition. >>> >>> A Trust Anchor is a Public key and associated information that a >>> relying party uses for signature verification. If the >> trust anchor is >>> limited in scope, the associated information includes the scope. >>> Examples of scope are name spaces, certificate policies, >>> application/usage types, and any combination of the above. >>> >>> -----Original Message----- >>> From: Stephen Kent [mailto:kent@bbn.com] >>> Sent: Tuesday, July 03, 2007 2:50 PM >>> To: Santosh Chokhani >>> Cc: ietf-trust-anchor@vpnc.org >>> Subject: RE: Enterprise-only or more... >>> >>> At 3:20 PM -0700 7/2/07, Santosh Chokhani wrote: >>>> Steve, >>>> >>>> I am resending the text I posted to the list over the weekend. I >>> wonder >>>> if any one read it or found it useful. >>>> >>>> >>>> "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 agree, hence my revised definition in a message earlier today. >>> >>>> 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 don't even like using the word "trust" here. Lety me know if you >>> think my suggested definition is a step in the right direction. >>> >>>> 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. >>> >>> agreed. >>> >>>> 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. >>> >>> all reasonable requirements. There may be more that folks >> will want, >>> but this is certainly a solid starting set. >>> >>>> 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." >>> >>> agreed. >>> >>> Steve >> >> From owner-ietf-trust-anchor Tue Jul 3 17:35: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 l640ZvZc049637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 17:35: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 l640ZvTf049636; Tue, 3 Jul 2007 17:35: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 keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l640Zqcw049625 for ; Tue, 3 Jul 2007 17:35:56 -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 76D25F01E3 for ; Tue, 3 Jul 2007 17:35:52 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Tue, 03 Jul 2007 17:35:52 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Tue, 03 Jul 2007 17:35:52 -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 1864332 for ietf-trust-anchor@vpnc.org; Tue, 03 Jul 2007 17:35:51 -0700 Received: from [63.251.255.205] ([63.251.255.205]) by keys.pgpeng.com (PGP Universal service); Tue, 03 Jul 2007 17:35:52 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Tue, 03 Jul 2007 17:35:52 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> Message-Id: From: Jon Callas Subject: Re: Definition of "trust anchor" Date: Tue, 3 Jul 2007 17:35:51 -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 Jul 2, 2007, at 12:45 PM, Carl Wallace wrote: > A trust anchor is a public key and associated information that is > directly trusted by an application or system to validate digital > signatures, including signatures covering other public keys that > are signed by the trust anchor. > This is a great definition. 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 Jul 3 19:53: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 l642rvOR060483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 19:53: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 l642rv50060482; Tue, 3 Jul 2007 19:53: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 smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l642ruGG060476 for ; Tue, 3 Jul 2007 19:53:56 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 4165 invoked from network); 4 Jul 2007 02:53:47 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.18.135 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 4 Jul 2007 02:53:46 -0000 X-YMail-OSG: wQqwkr4VM1nvtu1vJPmXTWFFMqyfPGwWj5ecsLjn1okmKyMjJnIcdTG6ytMga4ACEddX3Gnc1g-- Reply-To: From: "Turner, Sean P." To: Subject: Agenda Bashing Date: Tue, 3 Jul 2007 22:44:56 -0400 Organization: IECA, Inc. Message-ID: <001001c7bde5$50089a50$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C7BDC3.C8F6FA50" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace95U6ZMCM5cBKyTU2XFOAsvFOILA== 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_000_0011_01C7BDC3.C8F6FA50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, At this point we've got two speakers lined up for sure, so the agenda looks like this: - Welcome: Stephan Farrell/Sean Turner - 2 Minutes - Agenda Bashing: All - 5 Minutes - Problem Statement Description - Carl Wallace - 25 Minutes - US Government Interest - Raksha Reddy - 10 Minutes Any others that are interested in presenting please send Stephan and myself a message that indicates the topic and approximate length. Thanks, spt ------=_NextPart_000_0011_01C7BDC3.C8F6FA50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda Bashing

All,

At this point we've got two speakers = lined up for sure, so the agenda looks like this:

- Welcome: Stephan Farrell/Sean Turner = - 2 Minutes
- Agenda Bashing: All - 5 = Minutes
- Problem Statement Description - Carl = Wallace - 25 Minutes
- US Government Interest - Raksha = Reddy - 10 Minutes

Any others that are interested in = presenting please send Stephan and myself a message that indicates the = topic and approximate length.

Thanks,

spt


------=_NextPart_000_0011_01C7BDC3.C8F6FA50-- From owner-ietf-trust-anchor Tue Jul 3 20:53: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 l643rvvS064394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 20:53: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 l643rvMI064393; Tue, 3 Jul 2007 20:53: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 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 l643rsdB064387 for ; Tue, 3 Jul 2007 20:53:56 -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: Tue, 3 Jul 2007 20:53:13 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879084F0784@EXVS01.ex.dslextreme.net> In-Reply-To: <20070703191716.I37986@gecko.reptiles.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise-only or more... Thread-Index: Ace9yIpdh/U2PcCUThKPHnSKGPwHagAJb1pQ References: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879084EFB8B@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879084F05D7@EXVS01.ex.dslextreme.net> <7908B207-A42A-4BE0-9EDD-E192B41C9C4A@cisco.com> <20070703191716.I37986@gecko.reptiles.org> From: "Santosh Chokhani" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l643rudB064388 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We do want to manage multiple trust anchors. I am mot sure when you get the impression that we are talking about a single TA. -----Original Message----- From: Cat Okita [mailto:cat@reptiles.org] Sent: Tuesday, July 03, 2007 7:18 PM To: Max Pritikin Cc: Santosh Chokhani; Stephen Kent; ietf-trust-anchor@vpnc.org Subject: Re: Enterprise-only or more... On Tue, 3 Jul 2007, Max Pritikin wrote: > This is fine for defining the trust anchor as a (single) public key. The > problem statement discusses "managing one or more sets of trust anchors" > which leads me to wonder -- is the scope to manage a bundle/list/set of these > trust anchors or just one individual anchor? I'd say that this endeavour is pointless if we aren't intending to have management of multiple sets of trust anchors be in scope. cheers! > On Jul 3, 2007, at 4:17 PM, Santosh Chokhani wrote: > >> >> Steve, >> >> How about the following for a Trust Anchor Definition. >> >> A Trust Anchor is a Public key and associated information that a relying >> party uses for signature verification. If the trust anchor is limited >> in scope, the associated information includes the scope. Examples of >> scope are name spaces, certificate policies, application/usage types, >> and any combination of the above. >> >> -----Original Message----- >> From: Stephen Kent [mailto:kent@bbn.com] >> Sent: Tuesday, July 03, 2007 2:50 PM >> To: Santosh Chokhani >> Cc: ietf-trust-anchor@vpnc.org >> Subject: RE: Enterprise-only or more... >> >> At 3:20 PM -0700 7/2/07, Santosh Chokhani wrote: >>> Steve, >>> >>> I am resending the text I posted to the list over the weekend. I >> wonder >>> if any one read it or found it useful. >>> >>> >>> "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 agree, hence my revised definition in a message earlier today. >> >>> 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 don't even like using the word "trust" here. Lety me know if you >> think my suggested definition is a step in the right direction. >> >>> 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. >> >> agreed. >> >>> 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. >> >> all reasonable requirements. There may be more that folks will want, >> but this is certainly a solid starting set. >> >>> 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." >> >> agreed. >> >> Steve ======================================================================== == "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 Wed Jul 4 15:20: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 l64MKItV083047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2007 15:20: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 l64MKIrh083046; Wed, 4 Jul 2007 15:20: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 [165.227.249.210] (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 l64MKGrn083038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Jul 2007 15:20:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <001001c7bde5$50089a50$0301a8c0@Wylie> References: <001001c7bde5$50089a50$0301a8c0@Wylie> Date: Wed, 4 Jul 2007 15:19:44 -0700 To: From: Paul Hoffman Subject: Re: Agenda Bashing 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:44 PM -0400 7/3/07, Turner, Sean P. wrote: >At this point we've got two speakers lined up for sure, so the >agenda looks like this: > >- Welcome: Stephan Farrell/Sean Turner - 2 Minutes >- Agenda Bashing: All - 5 Minutes >- Problem Statement Description - Carl Wallace - 25 Minutes >- US Government Interest - Raksha Reddy - 10 Minutes > >Any others that are interested in presenting please send Stephan and >myself a message that indicates the topic and approximate length. At this point, we have diverging definitions of "trust anchor", and even if we get some agreement on the list before Chicago, it seems likely it could diverge again with the the new people in the room. I suggest someone (the chairs?) have about 15 minutes of discussion based on the definitions we have going into the meeting. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jul 5 02:40: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 l659eM6x035296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 02:40: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 l659eMpD035295; Thu, 5 Jul 2007 02:40: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 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 l659eKfn035282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Jul 2007 02:40:21 -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 20A9A321D8; Thu, 5 Jul 2007 10:40:19 +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 l659eFnI030212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jul 2007 10:40:17 +0100 Message-ID: <468CBCEE.3060901@cs.tcd.ie> Date: Thu, 05 Jul 2007 10:42:06 +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: Agenda Bashing References: <001001c7bde5$50089a50$0301a8c0@Wylie> 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: 11205781 - d91f3e899362 (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: Paul Hoffman wrote: > > At 10:44 PM -0400 7/3/07, Turner, Sean P. wrote: >> At this point we've got two speakers lined up for sure, so the agenda >> looks like this: >> >> - Welcome: Stephan Farrell/Sean Turner - 2 Minutes >> - Agenda Bashing: All - 5 Minutes >> - Problem Statement Description - Carl Wallace - 25 Minutes >> - US Government Interest - Raksha Reddy - 10 Minutes >> >> Any others that are interested in presenting please send Stephan and >> myself a message that indicates the topic and approximate length. > > At this point, we have diverging definitions of "trust anchor", and even > if we get some agreement on the list before Chicago, it seems likely it > could diverge again with the the new people in the room. I suggest > someone (the chairs?) have about 15 minutes of discussion based on the > definitions we have going into the meeting. Sure. If people want that. OTOH, I'm not that exercised by the fact that we're able to quibble about a definition, and none of the offered definitions seemed that radically different to me that we need to tackle this up-front. S. From owner-ietf-trust-anchor Thu Jul 5 06:48: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 l65DmXeY063632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 06:48: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 l65DmWHk063631; Thu, 5 Jul 2007 06:48: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l65DmVgu063622 for ; Thu, 5 Jul 2007 06:48:32 -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 1I6Rh8-0006pM-3v; Thu, 05 Jul 2007 09:48:30 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <82D5657AE1F54347A734BDD33637C879084F05D7@EXVS01.ex.dslextreme.net> References: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879084EFB8B@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879084F05D7@EXVS01.ex.dslextreme.net> Date: Thu, 5 Jul 2007 09:48:44 -0400 To: "Santosh Chokhani" From: Stephen Kent Subject: RE: Enterprise-only or more... 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:17 PM -0700 7/3/07, Santosh Chokhani wrote: >Steve, > >How about the following for a Trust Anchor Definition. > >A Trust Anchor is a Public key and associated information that a relying >party uses for signature verification. If the trust anchor is limited >in scope, the associated information includes the scope. Examples of >scope are name spaces, certificate policies, application/usage types, >and any combination of the above. > I think every TA is nominally limited in scope. For example, there seems to be agreement that we intend to be able to manage more than one TA. If we have two or more TAs, and if there is no scope associated with each of them, we may get into ambiguous or non-deterministic situations. Even if a TA is authorized to do everything, I'd like to see that stated explicitly. So I'm not fond of the "If a TA is limited in scope" part of this definition. Your list of example scopes is a good start, but "any combination of the above" to be "tends to counter the notion of these as just examples. How about: A Trust Anchor is a Public key and associated information that a relying party uses for signature verification. The associated information often is used to define the scope of a trust anchor, by imposing constraints on the signatures it may be used to verify. For example, if a trust anchor is used to verify signatures on X.509 certificates, these constraints may include a combination of name spaces, certificate policies, or application/usage types. Steve From owner-ietf-trust-anchor Thu Jul 5 07:16: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 l65EGFaq066246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 07:16: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 l65EGFUh066245; Thu, 5 Jul 2007 07:16: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 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 l65EGE1S066235 for ; Thu, 5 Jul 2007 07:16:14 -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: Thu, 5 Jul 2007 07:15:32 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87908552E68@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise-only or more... Thread-Index: Ace/C0470maYn5vPQyibtLbD+m1pKwAA6GFA References: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879084EFB8B@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879084F05D7@EXVS01.ex.dslextreme.net> From: "Santosh Chokhani" To: "Stephen Kent" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l65EGE1S066240 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steve, OK -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, July 05, 2007 9:49 AM To: Santosh Chokhani Cc: ietf-trust-anchor@vpnc.org Subject: RE: Enterprise-only or more... At 2:17 PM -0700 7/3/07, Santosh Chokhani wrote: >Steve, > >How about the following for a Trust Anchor Definition. > >A Trust Anchor is a Public key and associated information that a relying >party uses for signature verification. If the trust anchor is limited >in scope, the associated information includes the scope. Examples of >scope are name spaces, certificate policies, application/usage types, >and any combination of the above. > I think every TA is nominally limited in scope. For example, there seems to be agreement that we intend to be able to manage more than one TA. If we have two or more TAs, and if there is no scope associated with each of them, we may get into ambiguous or non-deterministic situations. Even if a TA is authorized to do everything, I'd like to see that stated explicitly. So I'm not fond of the "If a TA is limited in scope" part of this definition. Your list of example scopes is a good start, but "any combination of the above" to be "tends to counter the notion of these as just examples. How about: A Trust Anchor is a Public key and associated information that a relying party uses for signature verification. The associated information often is used to define the scope of a trust anchor, by imposing constraints on the signatures it may be used to verify. For example, if a trust anchor is used to verify signatures on X.509 certificates, these constraints may include a combination of name spaces, certificate policies, or application/usage types. Steve From owner-ietf-trust-anchor Thu Jul 5 09:12: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 l65GCj3Y078116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 09:12: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 l65GCjgu078115; Thu, 5 Jul 2007 09:12: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 [165.227.249.210] (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 l65GCUNi078093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 09:12:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> Date: Thu, 5 Jul 2007 09:11:04 -0700 To: Stephen Kent , ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Re: Definition of "trust anchor" 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:48 AM -0400 7/5/07, Stephen Kent wrote: >How about: > >A Trust Anchor is a Public key and associated information that a relying >party uses for signature verification. The associated information >often is used to define the scope of a trust anchor, by imposing >constraints on the signatures it may be used to verify. For example, >if a trust anchor is used to verify signatures on X.509 >certificates, these constraints may include a combination of name >spaces, certificate policies, or application/usage types. I quite unhappy about "uses". If an S/MIME message contains an intermediate CA certificate, I "use" it for signature verification, but it is not a trust anchor. We need something that indicates that a trust anchor has a particular special property, namely that it is a key of highest authority. I know you don't like the word "trust", but "uses" is not specific enough. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jul 5 09:21: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 l65GLSK1079189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 09:21: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 l65GLSlx079188; Thu, 5 Jul 2007 09:21: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 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 l65GLP7R079173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Jul 2007 09:21:27 -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 9C3F532699; Thu, 5 Jul 2007 17:21:25 +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 l65GLNcc024488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jul 2007 17:21:24 +0100 Message-ID: <468D1AF2.9050708@cs.tcd.ie> Date: Thu, 05 Jul 2007 17:23:14 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Paul Hoffman CC: Stephen Kent , ietf-trust-anchor@vpnc.org Subject: Re: Definition of "trust anchor" References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.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: 11225310 - f918067aaf20 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: Folks, Isn't it a bit premature to be wordsmithing the definition of a TA? IMO that's something we can do after the BoF, after we get a charter and when we have a protocol spec at WG last call. (FWIW, I wouldn't personally object much to any of the offered definitions and would probably quibble with any of them.) We might be better off keeping the discussion a bit more open/ abstract at this stage, S. From owner-ietf-trust-anchor Thu Jul 5 10:07: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 l65H7uUI082815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 10: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 l65H7uHE082811; Thu, 5 Jul 2007 10: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 mailbox.reptiles.org (mail.reptiles.org [198.96.210.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l65H7sRN082798; Thu, 5 Jul 2007 10:07:56 -0700 (MST) (envelope-from cat@reptiles.org) Received: from mail.reptiles.org ([198.96.210.227] port=56620) by mailbox.reptiles.org([198.96.210.227] port=25) via TCP with esmtp (2136 bytes) (sender: ) (ident using UNIX) id for ; Thu, 5 Jul 2007 13:07:39 -0400 (EDT) (Smail-3.2.0.121 2005-Nov-17 #4 built 2006-Nov-28) Date: Thu, 5 Jul 2007 13:07:38 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@gecko.reptiles.org Reply-To: Cat Okita To: Stephen Farrell cc: Paul Hoffman , Stephen Kent , ietf-trust-anchor@vpnc.org Subject: Re: Definition of "trust anchor" In-Reply-To: <468D1AF2.9050708@cs.tcd.ie> Message-ID: <20070705130317.S37986@gecko.reptiles.org> References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> 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, 5 Jul 2007, Stephen Farrell wrote: > Isn't it a bit premature to be wordsmithing the definition of > a TA? IMO that's something we can do after the BoF, after we > get a charter and when we have a protocol spec at WG last call. > (FWIW, I wouldn't personally object much to any of the offered > definitions and would probably quibble with any of them.) > > We might be better off keeping the discussion a bit more open/ > abstract at this stage, I don't agree - if we've got (as has been demonstrated) different ideas of what a TA is (or should be) in this context, then we're going to be at cross-purposes trying to put together a charter, never mind a protocol spec. It's like saying "transportation maintenance", when I'm thinking about getting my soles re-soled, and you've got 737 ailerons in mind. 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 Jul 5 10:26: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 l65HQtgh084747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 10:26: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 l65HQtrC084746; Thu, 5 Jul 2007 10:26: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l65HQsH0084733; Thu, 5 Jul 2007 10:26:54 -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 1I6V6T-00078I-4Q; Thu, 05 Jul 2007 13:26:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <468D1AF2.9050708@cs.tcd.ie> References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> Date: Thu, 5 Jul 2007 13:04:46 -0400 To: Stephen Farrell From: Stephen Kent Subject: Re: Definition of "trust anchor" 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 5:23 PM +0100 7/5/07, Stephen Farrell wrote: >Folks, > >Isn't it a bit premature to be wordsmithing the definition of >a TA? IMO that's something we can do after the BoF, after we >get a charter and when we have a protocol spec at WG last call. >(FWIW, I wouldn't personally object much to any of the offered >definitions and would probably quibble with any of them.) > >We might be better off keeping the discussion a bit more open/ >abstract at this stage, > >S. Maybe, so long as our inability to agree on a definition is not an indication of a lack of consensus on the purpose of the proposed WG. Steve From owner-ietf-trust-anchor Thu Jul 5 10:32: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 l65HWkOd085137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 10:32: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 l65HWkfi085136; Thu, 5 Jul 2007 10:32: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 l65HWijt085121; Thu, 5 Jul 2007 10:32: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 1I6VC7-0007FC-5e; Thu, 05 Jul 2007 13:32:44 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> Date: Thu, 5 Jul 2007 13:32:58 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: Definition of "trust anchor" 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:11 AM -0700 7/5/07, Paul Hoffman wrote: >At 9:48 AM -0400 7/5/07, Stephen Kent wrote: >>How about: >> >>A Trust Anchor is a Public key and associated information that a relying >>party uses for signature verification. The associated information >>often is used to define the scope of a trust anchor, by imposing >>constraints on the signatures it may be used to verify. For >>example, if a trust anchor is used to verify signatures on X.509 >>certificates, these constraints may include a combination of name >>spaces, certificate policies, or application/usage types. > >I quite unhappy about "uses". If an S/MIME message contains an >intermediate CA certificate, I "use" it for signature verification, >but it is not a trust anchor. > >We need something that indicates that a trust anchor has a >particular special property, namely that it is a key of highest >authority. I know you don't like the word "trust", but "uses" is not >specific enough. You're right that "uses" is not specific enough to distinguish a TA from a CA. "Trust" is also not good enough to fix this problem; the usual interpretation is that a relying party trusts a TA and, transitively trusts the CAs below that TA. How about an amended version of the definition I suggested Tuesday, one in which I distinguished between the two cases for TA use: Trust Anchor: A public key and associated data used by a relying party to validate a signature on a signed object where the object is either - a cert that begins a cert validation path - a non-cert object that cannot be validated via use of a cert path Trust anchors have local significance, i.e., each RP is configured with a set of trust anchors, either by the RP or by an entity that manages TAs in the context on which the RP operates. The associated data often is used to define the scope of a trust anchor, by imposing constraints on the signatures it may be used to verify. For example, if a trust anchor is used to verify signatures on X.509 certificates, these constraints may include a combination of name spaces, certificate policies, or application/usage types. Steve From owner-ietf-trust-anchor Thu Jul 5 10:34: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 l65HYZ3f085516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 10:34: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 l65HYZjo085515; Thu, 5 Jul 2007 10:34: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 relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l65HYXqm085489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Jul 2007 10:34:34 -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 0AD423235B; Thu, 5 Jul 2007 18:34:32 +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 l65HYSkp004164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jul 2007 18:34:29 +0100 Message-ID: <468D2C13.30301@cs.tcd.ie> Date: Thu, 05 Jul 2007 18:36:19 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Cat Okita CC: Paul Hoffman , Stephen Kent , ietf-trust-anchor@vpnc.org Subject: Re: Definition of "trust anchor" References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> <20070705130317.S37986@gecko.reptiles.org> In-Reply-To: <20070705130317.S37986@gecko.reptiles.org> 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: 11228502 - e188582cc2c5 (trained as not-spam) 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: Cat Okita wrote: > On Thu, 5 Jul 2007, Stephen Farrell wrote: >> Isn't it a bit premature to be wordsmithing the definition of >> a TA? IMO that's something we can do after the BoF, after we >> get a charter and when we have a protocol spec at WG last call. >> (FWIW, I wouldn't personally object much to any of the offered >> definitions and would probably quibble with any of them.) >> >> We might be better off keeping the discussion a bit more open/ >> abstract at this stage, > > I don't agree - if we've got (as has been demonstrated) different ideas > of what a TA is (or should be) I didn't see that. I saw different words, not really different ideas, S. From owner-ietf-trust-anchor Thu Jul 5 10:40: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 l65HedWq085873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 10:40: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 l65HedCA085872; Thu, 5 Jul 2007 10:40: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 [165.227.249.210] (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 l65Hebn8085866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jul 2007 10:40:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <468D2C13.30301@cs.tcd.ie> References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> <20070705130317.S37986@gecko.reptiles.org> <468D2C13.30301@cs.tcd.ie> <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> Date: Thu, 5 Jul 2007 10:40:06 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Re: Definition of "trust anchor" 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:04 PM -0400 7/5/07, Stephen Kent wrote: >At 5:23 PM +0100 7/5/07, Stephen Farrell wrote: >>We might be better off keeping the discussion a bit more open/ >>abstract at this stage, > >Maybe, so long as our inability to agree on a definition is not an >indication of a lack of consensus on the purpose of the proposed WG. At 6:36 PM +0100 7/5/07, Stephen Farrell wrote: >Cat Okita wrote: >>I don't agree - if we've got (as has been demonstrated) different ideas >>of what a TA is (or should be) > >I didn't see that. I saw different words, not really different >ideas, I agree with both Steves. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jul 5 11:13: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 l65IDcZT089104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 11:13: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 l65IDcId089103; Thu, 5 Jul 2007 11:13: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 sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l65IDbRh089096 for ; Thu, 5 Jul 2007 11:13:38 -0700 (MST) (envelope-from pritikin@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 05 Jul 2007 11:13:37 -0700 X-IronPort-AV: i="4.16,504,1175497200"; d="scan'208"; a="6806683:sNHT19611432" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l65IDbOL003135; Thu, 5 Jul 2007 11:13:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l65IDJko009425; Thu, 5 Jul 2007 18:13:37 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 11:13:27 -0700 Received: from [10.32.244.67] ([10.32.244.67]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 11:13:27 -0700 In-Reply-To: <82D5657AE1F54347A734BDD33637C879084F0784@EXVS01.ex.dslextreme.net> References: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879084EFB8B@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879084F05D7@EXVS01.ex.dslextreme.net> <7908B207-A42A-4BE0-9EDD-E192B41C9C4A@cisco.com> <20070703191716.I37986@gecko.reptiles.org> <82D5657AE1F54347A734BDD33637C879084F0784@EXVS01.ex.dslextreme.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Content-Transfer-Encoding: 7bit From: Max Pritikin Subject: Re: Enterprise-only or more... Date: Thu, 5 Jul 2007 13:13:22 -0500 To: Santosh Chokhani X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Jul 2007 18:13:27.0741 (UTC) FILETIME=[2F5E8ED0:01C7BF30] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=383; t=1183659217; x=1184523217; c=relaxed/simple; s=sjdkim4002; 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=20Enterprise-only=20or=20more... |Sender:=20; bh=OnA+IcdH7N7emz/C2O7tI1WsQHt9BngvD478NI9ffiA=; b=W4OgsYfFud11JGpXwdyNveAAfAX/arq8ITjbWxGRYsJh7YZqLhnmiptXBpJgf/qlE1iWOBaX DYhrmouqbk3vsxiaV28Opjk9SwVQ1ufofC9aSwQMANIRKttxMtkACyid; Authentication-Results: sj-dkim-4; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jul 3, 2007, at 10:53 PM, Santosh Chokhani wrote: > > We do want to manage multiple trust anchors. I am mot sure when > you get > the impression that we are talking about a single TA. > From statements like: > If I need to install/delete multiple TAs, I should just run the same > protocol multiple times. which I don't think is a sufficient answer. - max From owner-ietf-trust-anchor Thu Jul 5 11:53: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 l65IrcPs083688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 11:53: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 l65IrciB083687; Thu, 5 Jul 2007 11:53: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 keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l65IrbNL083679 for ; Thu, 5 Jul 2007 11:53:37 -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 1EAB0F01EA for ; Thu, 5 Jul 2007 11:53:37 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Thu, 05 Jul 2007 11:53:37 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 05 Jul 2007 11:53:37 -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 1866168 for ietf-trust-anchor@vpnc.org; Thu, 05 Jul 2007 11:53:36 -0700 Received: from [63.251.255.205] ([63.251.255.205]) by keys.pgpeng.com (PGP Universal service); Thu, 05 Jul 2007 11:53:36 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 05 Jul 2007 11:53:36 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <468D1AF2.9050708@cs.tcd.ie> References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> Message-Id: From: Jon Callas Subject: Re: Definition of "trust anchor" Date: Thu, 5 Jul 2007 11:53:35 -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 Jul 5, 2007, at 9:23 AM, Stephen Farrell wrote: > Isn't it a bit premature to be wordsmithing the definition of > a TA? IMO that's something we can do after the BoF, after we > get a charter and when we have a protocol spec at WG last call. > (FWIW, I wouldn't personally object much to any of the offered > definitions and would probably quibble with any of them.) > > We might be better off keeping the discussion a bit more open/ > abstract at this stage, I don't think it's premature. In fact, I think that a criticism of "this group can't agree on a definition of Trust Anchor" not only means that there shouldn't be a working group, but there shouldn't be a BOF (or shouldn't be a second BOF). If we find that many people think this is a good idea, but there is more than one camp, then it means that there perhaps should be more than one working group, even. 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 Jul 5 11:58: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 l65IwKSn084326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 11:58: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 l65IwKac084325; Thu, 5 Jul 2007 11:58:20 -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 l65IwK8P084318 for ; Thu, 5 Jul 2007 11:58:20 -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 2C439F01EA for ; Thu, 5 Jul 2007 11:58:20 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Thu, 05 Jul 2007 11:58:20 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 05 Jul 2007 11:58:20 -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 1866174 for ietf-trust-anchor@vpnc.org; Thu, 05 Jul 2007 11:58:19 -0700 Received: from [63.251.255.205] ([63.251.255.205]) by keys.pgpeng.com (PGP Universal service); Thu, 05 Jul 2007 11:58:20 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Thu, 05 Jul 2007 11:58:20 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <468D2C13.30301@cs.tcd.ie> References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> <20070705130317.S37986@gecko.reptiles.org> <468D2C13.30301@cs.tcd.ie> Message-Id: From: Jon Callas Subject: Re: Definition of "trust anchor" Date: Thu, 5 Jul 2007 11:58:19 -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 Jul 5, 2007, at 10:36 AM, Stephen Farrell wrote: > > I didn't see that. I saw different words, not really different > ideas, I concur. I see all the definitions are being more or less the same, but with different scope. Carl and Paul's was very general in scope. Steve's was more specific. Yours was back more to general (and I don't quite understand the non-cert part, but that's okay at the moment). *If* we can't agree on what problem we're solving, then that's an issue we need to address up front. Everyone commenting has said a hypothetical that's close ro that. However, I don't presently believe that the conditional is true. We still need to have a working definition. 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 Jul 5 13:08:29 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 l65K8SOn097440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 13:08: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 l65K8Snt097439; Thu, 5 Jul 2007 13:08: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 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 l65K8RsR097426; Thu, 5 Jul 2007 13:08:27 -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: Definition of "trust anchor" Date: Thu, 5 Jul 2007 13:08:50 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Definition of "trust anchor" Thread-Index: Ace/KypS5Qy9VH9nTa6LUVqzCvRZNgAFOVpA From: "Thomas Hardjono" To: "Stephen Kent" , "Paul Hoffman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l65K8RsR097427 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: Thursday, July 05, 2007 10:33 AM > To: Paul Hoffman > Cc: ietf-trust-anchor@vpnc.org > Subject: Re: Definition of "trust anchor" > > > At 9:11 AM -0700 7/5/07, Paul Hoffman wrote: > >At 9:48 AM -0400 7/5/07, Stephen Kent wrote: > >>How about: > >> > >>A Trust Anchor is a Public key and associated information that a > >>relying party uses for signature verification. The associated > >>information often is used to define the scope of a trust anchor, by > >>imposing constraints on the signatures it may be used to > verify. For > >>example, if a trust anchor is used to verify signatures on X.509 > >>certificates, these constraints may include a combination of name > >>spaces, certificate policies, or application/usage types. > > > >I quite unhappy about "uses". If an S/MIME message contains an > >intermediate CA certificate, I "use" it for signature > verification, but > >it is not a trust anchor. > > > >We need something that indicates that a trust anchor has a > particular > >special property, namely that it is a key of highest > authority. I know > >you don't like the word "trust", but "uses" is not specific enough. > > You're right that "uses" is not specific enough to > distinguish a TA from a CA. "Trust" is also not good enough > to fix this problem; the usual interpretation is that a > relying party trusts a TA and, transitively trusts the CAs > below that TA. > > How about an amended version of the definition I suggested > Tuesday, one in which I distinguished between the two cases > for TA use: > > Trust Anchor: A public key and associated data used by a > relying party to validate a signature on a signed object > where the object is either > - a cert that begins a cert validation path > - a non-cert object that cannot be validated via use of > a cert path > > Trust anchors have local significance, i.e., each RP is > configured with a set of trust anchors, either by the RP or > by an entity that manages TAs in the context on which the RP > operates. The associated data often is used to define the > scope of a trust anchor, by imposing constraints on the > signatures it may be used to verify. For example, if a trust > anchor is used to verify signatures on X.509 certificates, > these constraints may include a combination of name spaces, > certificate policies, or application/usage types. > > Steve > > I like Steve's latest definition (above). /thomas/ From owner-ietf-trust-anchor Thu Jul 5 13:18:29 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 l65KIS5c098676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 13:18: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 l65KISkb098675; Thu, 5 Jul 2007 13:18: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 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 l65KIRYa098669 for ; Thu, 5 Jul 2007 13:18:28 -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: Definition of "trust anchor" Date: Thu, 5 Jul 2007 13:18:51 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Definition of "trust anchor" Thread-Index: Ace/NsEjj+pnbLbtQ0yvm4NjN2b+rwACaIBQ From: "Thomas Hardjono" To: "Jon Callas" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l65KISYa098670 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 Jon Callas > Sent: Thursday, July 05, 2007 11:54 AM > To: ietf-trust-anchor@vpnc.org > Subject: Re: Definition of "trust anchor" > > > > On Jul 5, 2007, at 9:23 AM, Stephen Farrell wrote: > > > Isn't it a bit premature to be wordsmithing the definition of a TA? > > IMO that's something we can do after the BoF, after we get > a charter > > and when we have a protocol spec at WG last call. > > (FWIW, I wouldn't personally object much to any of the offered > > definitions and would probably quibble with any of them.) > > > > We might be better off keeping the discussion a bit more open/ > > abstract at this stage, > > I don't think it's premature. In fact, I think that a > criticism of "this group can't agree on a definition of Trust > Anchor" not only means that there shouldn't be a working > group, but there shouldn't be a BOF (or shouldn't be a second BOF). > > If we find that many people think this is a good idea, but > there is more than one camp, then it means that there perhaps > should be more than one working group, even. > > Jon > >From reading the draft-00 and from experience in general, I think there is a problem to solve (ie. we need TA management). Most folks on this list seem (at least to me) to generally agree with some definition of a TA being aired so far (PS. Steve's last definition looks good to me). Going back-and-forth on the definition of a TA is a natural process in preparation for a BOF and for WG chartering. I would think that getting early consensus on a reasonable definition of a TA will help in getting consensus on the "management protocol" (i.e. protocol scope, behavior, etc). /thomas/ From owner-ietf-trust-anchor Thu Jul 5 17:20: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 l660K12j022567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 17:20: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 l660K1Dm022566; Thu, 5 Jul 2007 17:20: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 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 l660Jxjl022551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Jul 2007 17:20:00 -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 8E941321DD; Fri, 6 Jul 2007 01:19: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 l660JrlE028016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jul 2007 01:19:54 +0100 Message-ID: <468D8B18.7040304@cs.tcd.ie> Date: Fri, 06 Jul 2007 01:21:44 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jon Callas CC: ietf-trust-anchor@vpnc.org Subject: Starting a charter strawman (was: Re: Definition of "trust anchor") References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> <20070705130317.S37986@gecko.reptiles.org> <468D2C13.30301@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: 11240881 - 17ab6327104d (trained as not-spam) 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: Jon Callas wrote: > > On Jul 5, 2007, at 10:36 AM, Stephen Farrell wrote: > >> >> I didn't see that. I saw different words, not really different >> ideas, > > I concur. I see all the definitions are being more or less the same,... Good to hear. (And I obviously agree.) Meanwhile, from my p-o-v (as BoF co-chair), I think I'm seeing a good deal of agreement about the desirability of handing the enterprise case, and, so far anyway, no great interest in doing much more than that, at least right now. So, my suggestion is that we next get a strawman charter drafted and bash that a bit on the list, so that we have something do discuss in Chicago in the event that the first part of the meeting goes well. To that end, I'd like to get suggestions as to what to in/exclude from such a charter. I can try craft a bit of text around that in the next week or so, and would appreciate it if people with ideas about that would send them to either Sean and I, or to the list, as you think appropriate. Of course, if you think we need to do more work first, please do say that, but going by the mails from the last while, it seems to Sean and I that there is a constituency that would like to tackle at least the enterprise case of TA management, (for what seems to be a commensurate, but not identical, set of definitions of "TA"), Regards, Stephen. From owner-ietf-trust-anchor Thu Jul 5 20:02: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 l6632EBS037475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 20:02: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 l6632Eim037474; Thu, 5 Jul 2007 20:02: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 [165.227.249.210] (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 l66326hC037455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 20:02:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <468D8B18.7040304@cs.tcd.ie> References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> <20070705130317.S37986@gecko.reptiles.org> <468D2C13.30301@cs.tcd.ie> <468D8B18.7040304@cs.tcd.ie> Date: Thu, 5 Jul 2007 20:01:34 -0700 To: Stephen Farrell , Jon Callas From: Paul Hoffman Subject: Beyond the "enterprise case" 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 1:21 AM +0100 7/6/07, Stephen Farrell wrote: >Meanwhile, from my p-o-v (as BoF co-chair), I think I'm seeing a >good deal of agreement about the desirability of handing the >enterprise case, and, so far anyway, no great interest in doing >much more than that, at least right now. Wait, wait. I didn't see anyone asking about the "much more than that case" or I would have certainly chimed in. A non-enterprise case that is quite important, and can probably be handled by the same protocol, is that of secure TA updates for individual users. Right now, there are approximately two widely-deployed models: - Completely trust Microsoft to update your TA list for the OS and all apps that use CAPI when you are validating a signature - Completely trust Mozilla to update your TA list for their products when you update your Mozilla software. Maybe there is another useful model. :-) The "enterprise case" is that your IS department will be trusted. The end user case could be "I trust this group over here, plus I trust my bank, and I trust my government". The pile-o-TAs that you will end up with will probably be less than a third the size of the current models. The main difference between this model and where we might go with the "enterprise case" is that there is an explicit understanding that the relying party will possibly / probably trust multiple independent TA administrators. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Jul 6 02:48: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 l669mcHq075537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 02:48: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 l669mc6x075536; Fri, 6 Jul 2007 02:48: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 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 l669ma7j075522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Jul 2007 02:48:37 -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 A994F321E3; Fri, 6 Jul 2007 10:48:33 +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 l669mUmb027803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jul 2007 10:48:31 +0100 Message-ID: <468E105D.7070606@cs.tcd.ie> Date: Fri, 06 Jul 2007 10:50:21 +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: Beyond the "enterprise case" References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> <20070705130317.S37986@gecko.reptiles.org> <468D2C13.30301@cs.tcd.ie> <468D8B18.7040304@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: 11253317 - 3691c9108d33 (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: Paul Hoffman wrote: > > At 1:21 AM +0100 7/6/07, Stephen Farrell wrote: >> Meanwhile, from my p-o-v (as BoF co-chair), I think I'm seeing a >> good deal of agreement about the desirability of handing the >> enterprise case, and, so far anyway, no great interest in doing >> much more than that, at least right now. > > Wait, wait. I didn't see anyone asking about the "much more than that > case" or I would have certainly chimed in. Well, I did start a thread called "Enterprise-only or more..." but sure. > A non-enterprise case that is quite important, and can probably be > handled by the same protocol, is that of secure TA updates for > individual users. Right now, there are approximately two widely-deployed > models: > > - Completely trust Microsoft to update your TA list for the OS and all > apps that use CAPI when you are validating a signature > > - Completely trust Mozilla to update your TA list for their products > when you update your Mozilla software. > > Maybe there is another useful model. :-) Yes. However, I don't think we have anyone who's volunteering to try to present/argue-for inclusion of that problem. There's also the device/mobile-phone-like use case that Steve Kent raised, but again, I also don't see someone jumping in to say that they'd like to argue for doing a bunch of work on that. We do have agenda time if someone wants to take one of those on, and I'd be very happy to see either or both presented/discussed as potential parts of the problem statement, i.e., I wouldn't expect a worked out solution in Chicago. (I'm not sure that Carl would include either in his presentation, since his problem statement draft [1] doesn't address those use cases.) So, any volunteers? If you'd like to take a stab at either slot just let Sean and I know. If not, then I think it does look like we are only really interested in the enterprise case, S. [1] http://www.ietf.org/internet-drafts/draft-wallace-ta-mgmt-problem-statement-00.txt From owner-ietf-trust-anchor Fri Jul 6 06:23: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 l66DNg7w095687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 06:23: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 l66DNgSb095686; Fri, 6 Jul 2007 06:23: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 l66DNfp2095680 for ; Fri, 6 Jul 2007 06:23:42 -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 1I6nme-00085U-5x; Fri, 06 Jul 2007 09:23:40 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> <20070705130317.S37986@gecko.reptiles.org> <468D2C13.30301@cs.tcd.ie> <468D8B18.7040304@cs.tcd.ie> Date: Fri, 6 Jul 2007 09:09:00 -0400 To: Stephen Farrell From: Stephen Kent Subject: Re: Beyond the "enterprise case" 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, I agree with Paul that if we define a TA management interface capability that allows users to better establish constraints on the scope of TAs, end users might derive considerable benefit. Steve From owner-ietf-trust-anchor Fri Jul 6 06:35: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 l66DZ1Vr096602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 06:35: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 l66DZ1o0096601; Fri, 6 Jul 2007 06:35: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l66DYxk8096586 for ; Fri, 6 Jul 2007 06:35:00 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 22448 invoked from network); 6 Jul 2007 13:32:56 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;06 Jul 2007 13:32:56 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 6 Jul 2007 13:32:56 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Fri, 6 Jul 2007 09:34:55 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D11A3@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: Problem statement v01 Date: Fri, 6 Jul 2007 09:34:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BFD2.708969B0" 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_01C7BFD2.708969B0 Content-Type: text/plain I just submitted the -01 version of the problem statement. This includes revisions based on the list discussion of the past few weeks. Aside from general wordsmithing mainly focused on providing a multiple application view vs. a device-centric view, the primary changes are as follows: - Removed section 4 (the Using CMS section) - Added text regarding the need for multiple TA formats - Added most recent TA definition (from Steve K.) - Added text indicating add/removal operations are necessary - Added security consideration regarding integrity and authentication (this was in the Section 4 before) - Clarified that TA managers must be in control of scope constraints ------_=_NextPart_001_01C7BFD2.708969B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Problem statement v01

I just submitted the -01 version of the problem = statement.  This includes revisions based on the list discussion = of the past few weeks.  Aside from general wordsmithing mainly = focused on providing a multiple application view vs. a device-centric = view, the primary changes are as follows:

- Removed section 4 (the Using CMS section)
- Added text regarding the need for multiple TA = formats
- Added most recent TA definition (from Steve = K.)
- Added text indicating add/removal operations are = necessary
- Added security consideration regarding integrity = and authentication (this was in the Section 4 before)
- Clarified that TA managers must be in control of = scope constraints

------_=_NextPart_001_01C7BFD2.708969B0-- From owner-ietf-trust-anchor Fri Jul 6 07:52: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 l66Equrc004542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 07:52: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 l66EquQ1004541; Fri, 6 Jul 2007 07:52: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 [165.227.249.210] (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 l66Eqq5o004501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 07:52:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <468E105D.7070606@cs.tcd.ie> References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> <20070705130317.S37986@gecko.reptiles.org> <468D2C13.30301@cs.tcd.ie> <468D8B18.7040304@cs.tcd.ie> <468E105D.7070606@cs.tcd.ie> Date: Fri, 6 Jul 2007 07:52:20 -0700 To: Stephen Farrell From: Paul Hoffman Subject: Re: Beyond the "enterprise case" 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:50 AM +0100 7/6/07, Stephen Farrell wrote: >>A non-enterprise case that is quite important, and can probably be >>handled by the same protocol, is that of secure TA updates for >>individual users. Right now, there are approximately two >>widely-deployed models: >> >>- Completely trust Microsoft to update your TA list for the OS and >>all apps that use CAPI when you are validating a signature >> >>- Completely trust Mozilla to update your TA list for their >>products when you update your Mozilla software. >> >>Maybe there is another useful model. :-) > >Yes. However, I don't think we have anyone who's volunteering to >try to present/argue-for inclusion of that problem. I volunteer. As I said in the earlier message, I think that the only significant difference in the home-user case from the enterprise-user case is that the home user will have multiple TA administrators. That difference leads to some protocol-level additions, but I think the number of those is quite small. >There's also the device/mobile-phone-like use case that Steve Kent >raised, but again, I also don't see someone jumping in to say that >they'd like to argue for doing a bunch of work on that. I'll jump up for that one as well. As far as I can tell, the only difference between that and the other two is one that I brought up early on the list and didn't get objection to: that the protocol must be based on individual messages, not on connections. >We do have agenda time if someone wants to take one of those on, and >I'd be very happy to see either or both presented/discussed as potential >parts of the problem statement, i.e., I wouldn't expect a worked out >solution in Chicago. (I'm not sure that Carl would include either >in his presentation, since his problem statement draft [1] doesn't >address those use cases.) > >So, any volunteers? If you'd like to take a stab at either slot >just let Sean and I know. I would like ten minutes for each of those. I'm happy to share it with others who might also find the use cases valuable. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Jul 6 08:53: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 l66Frxps011327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 08:53:59 -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 l66FrxsH011326; Fri, 6 Jul 2007 08:53:59 -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 (wpad.iss.tcd.ie [134.226.1.156]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l66Frw3V011311; Fri, 6 Jul 2007 08:53:58 -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 1FA7A6802A; Fri, 6 Jul 2007 16:53:58 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A042FC1C1B9; Fri, 06 Jul 2007 16:53:58 +0100 Received: from [134.226.36.174] (nanga.dsg.cs.tcd.ie [134.226.36.174]) by imx2.tcd.ie (Postfix) with ESMTP id 12E376802A; Fri, 6 Jul 2007 16:53:58 +0100 (IST) Message-ID: <468E660B.6060306@cs.tcd.ie> Date: Fri, 06 Jul 2007 16:55:55 +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: Beyond the "enterprise case" References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> <20070705130317.S37986@gecko.reptiles.org> <468D2C13.30301@cs.tcd.ie> <468D8B18.7040304@cs.tcd.ie> <468E105D.7070606@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A142FC1C1B9 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.87.4) Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Hoffman wrote: > > At 10:50 AM +0100 7/6/07, Stephen Farrell wrote: >>> A non-enterprise case that is quite important, and can probably be >>> handled by the same protocol, is that of secure TA updates for >>> individual users. Right now, there are approximately two >>> widely-deployed models: >>> >>> - Completely trust Microsoft to update your TA list for the OS and >>> all apps that use CAPI when you are validating a signature >>> >>> - Completely trust Mozilla to update your TA list for their products >>> when you update your Mozilla software. >>> >>> Maybe there is another useful model. :-) >> >> Yes. However, I don't think we have anyone who's volunteering to >> try to present/argue-for inclusion of that problem. > > I volunteer. Excellent! I think that'll really help us to figure out a useful scope for the proposed work, Thanks, S. From owner-ietf-trust-anchor Fri Jul 6 09:52: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 l66Gq0LK018977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 09:52: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 l66Gq0bx018976; Fri, 6 Jul 2007 09:52: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 mailbox.reptiles.org (mail.reptiles.org [198.96.210.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l66Gpxj7018962; Fri, 6 Jul 2007 09:51:59 -0700 (MST) (envelope-from cat@reptiles.org) Received: from mail.reptiles.org ([198.96.210.227] port=63436) by mailbox.reptiles.org([198.96.210.227] port=25) via TCP with esmtp (2436 bytes) (sender: ) (ident using UNIX) id for ; Fri, 6 Jul 2007 12:51:55 -0400 (EDT) (Smail-3.2.0.121 2005-Nov-17 #4 built 2006-Nov-28) Date: Fri, 6 Jul 2007 12:51:52 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@gecko.reptiles.org Reply-To: Cat Okita To: Stephen Farrell cc: Paul Hoffman , ietf-trust-anchor@vpnc.org Subject: Re: Beyond the "enterprise case" In-Reply-To: <468E105D.7070606@cs.tcd.ie> Message-ID: <20070706124909.H37986@gecko.reptiles.org> References: <886F5D4C78AFB14D87261206BFB9612E1D1D1017@scygmxs1.cygnacom.com> <468D1AF2.9050708@cs.tcd.ie> <20070705130317.S37986@gecko.reptiles.org> <468D2C13.30301@cs.tcd.ie> <468D8B18.7040304@cs.tcd.ie> <468E105D.7070606@cs.tcd.ie> 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 Fri, 6 Jul 2007, Stephen Farrell wrote: > Yes. However, I don't think we have anyone who's volunteering to > try to present/argue-for inclusion of that problem. I'm certainly willing to argue for inclusion of that problem - it seems daft to sort out something that's bound to end up including/affecting users, and deliberately ignoring them. > We do have agenda time if someone wants to take one of those on, and > I'd be very happy to see either or both presented/discussed as potential > parts of the problem statement, i.e., I wouldn't expect a worked out > solution in Chicago. (I'm not sure that Carl would include either > in his presentation, since his problem statement draft [1] doesn't > address those use cases.) > > So, any volunteers? If you'd like to take a stab at either slot > just let Sean and I know. Unfortunately I'm overcommitted for the next month, but I'd be glad to assist if there's somebody that can lead... 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 Fri Jul 6 14:51: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 l66LpEir049643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 14:51: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 l66LpEqe049642; Fri, 6 Jul 2007 14:51: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 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 l66LpDLJ049636 for ; Fri, 6 Jul 2007 14:51:14 -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, 6 Jul 2007 14:50:36 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879085A71F5@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise-only or more... Thread-Index: Ace/MFCpy/Mu88f+QtSjXHllGcE7RwA51k7Q References: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879084EFB8B@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879084F05D7@EXVS01.ex.dslextreme.net> <7908B207-A42A-4BE0-9EDD-E192B41C9C4A@cisco.com> <20070703191716.I37986@gecko.reptiles.org> <82D5657AE1F54347A734BDD33637C879084F0784@EXVS01.ex.dslextreme.net> From: "Santosh Chokhani" To: "Max Pritikin" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l66LpELJ049637 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: And that is not what I said. -----Original Message----- From: Max Pritikin [mailto:pritikin@cisco.com] Sent: Thursday, July 05, 2007 2:13 PM To: Santosh Chokhani Cc: ietf-trust-anchor@vpnc.org Subject: Re: Enterprise-only or more... On Jul 3, 2007, at 10:53 PM, Santosh Chokhani wrote: > > We do want to manage multiple trust anchors. I am mot sure when > you get > the impression that we are talking about a single TA. > From statements like: > If I need to install/delete multiple TAs, I should just run the same > protocol multiple times. which I don't think is a sufficient answer. - max From owner-ietf-trust-anchor Sat Jul 7 12:27: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 l67JRB82071528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jul 2007 12:27: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 l67JRBxk071527; Sat, 7 Jul 2007 12:27: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 relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l67JR901071472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 7 Jul 2007 12:27:10 -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 8E9033213F for ; Sat, 7 Jul 2007 20:27:08 +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 l67JR7Se010632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 7 Jul 2007 20:27:07 +0100 Message-ID: <468FE97A.7040404@cs.tcd.ie> Date: Sat, 07 Jul 2007 20:28: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: What's out of scope? 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: 11304142 - 4ace8a0c6596 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: Hi all, As we get started on drafting a strawman charter (Sean and I are starting work on that now-ish), I think one of the things that might be good to be say something about is what's out of scope. I would assume that CMC/CMP related managment is out of scope, as is certificate retrieval (as done by LDAP) and status checking (SCVP-to-be,OCSP,XKMS). Similarly local trust anchor storage and use mechanisms (and their security) should be out of scope. Other inputs? (Don't worry about wording just yet.) Cheers, Stephen. From owner-ietf-trust-anchor Mon Jul 9 07:51:58 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 l69EpwsM095354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2007 07:51: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 l69EpwlP095353; Mon, 9 Jul 2007 07:51: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 sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l69Epu79095343 for ; Mon, 9 Jul 2007 07:51:57 -0700 (MST) (envelope-from pritikin@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2007 07:51:56 -0700 X-IronPort-AV: i="4.16,517,1175497200"; d="scan'208"; a="7248325:sNHT22874274" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l69Epu0O017847; Mon, 9 Jul 2007 07:51:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l69Epfka004576; Mon, 9 Jul 2007 14:51:46 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 07:51:41 -0700 Received: from [10.32.244.66] ([10.32.244.66]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 07:51:41 -0700 In-Reply-To: <82D5657AE1F54347A734BDD33637C879085A71F5@EXVS01.ex.dslextreme.net> References: <886F5D4C78AFB14D87261206BFB9612E1D1D102B@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879084EFB8B@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879084F05D7@EXVS01.ex.dslextreme.net> <7908B207-A42A-4BE0-9EDD-E192B41C9C4A@cisco.com> <20070703191716.I37986@gecko.reptiles.org> <82D5657AE1F54347A734BDD33637C879084F0784@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C879085A71F5@EXVS01.ex.dslextreme.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Content-Transfer-Encoding: 7bit From: Max Pritikin Subject: Re: Enterprise-only or more... Date: Mon, 9 Jul 2007 09:51:14 -0500 To: Santosh Chokhani X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Jul 2007 14:51:41.0366 (UTC) FILETIME=[A90F5560:01C7C238] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2362; t=1183992716; x=1184856716; 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=20Enterprise-only=20or=20more... |Sender:=20; bh=BsFe3CVJgIIPnmw9zzDWwtoll4UqTMYxecpUzKyE444=; b=jFz/7sYJp5Vvds1z/hYNjXElHKsSEGvihYnrClCOA00Rq/U+qXijXRVVBzUzAR0WctbRjUQC /ln4V7zWSYuZIYcTA2Cqcjk4/Yzmp2mmOj29pCZnstr1pZ3rpMf6covacLnoo4WIFYrIYCJJZB 1dccmzMkNupkN14baHawRw06Q=; 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: Santosh, my apologies for the bad quoting practices. The example statement below by was 'Thomas Hardjono' and was in response to my general query. It was not my intention to pick on Thomas and I did a poor job of formatting my message. My point was just that some statements on the list have implied that only one "TA" (whatever that turns out to be defined as) would be managed at a time -- and example definitions seemed to be leaning toward one keypair/cert-chain as a definition. So while you and I appear to be in agreement I felt there was some doubt about how this would be handled. It might be too early for us to worry too much about these details and I'm happy enough to hear some agreement about managing multiple "TA"s. In summary of my concern: I have seen many PKI deployments where multiple CAs are used in an overlapping fashion. For example "VPN- CA1" with a subsequent CA deployed at the half-life called "VPN-CA2". The devices communicating end up with client certificates from both CA's and this then "solves" the problem of maintaining the security connections when the first CA1 root certificate expires. I use quotes around "solves" because of course it doesn't always - and also some out of band management protocol is being used to manage the VPN-CA1 and VPN-CA2 and VPN-CA3 lists etc etc. So anyway this is the scenario I'm picturing when reading this ietf-trust-anchor list and thus I'm perceiving the "Trust Anchor"[s] to be managed to be the full set of VPN-CAs. Cheers, - max On Jul 6, 2007, at 4:50 PM, Santosh Chokhani wrote: > And that is not what I said. > > -----Original Message----- > From: Max Pritikin [mailto:pritikin@cisco.com] > Sent: Thursday, July 05, 2007 2:13 PM > To: Santosh Chokhani > Cc: ietf-trust-anchor@vpnc.org > Subject: Re: Enterprise-only or more... > > > > On Jul 3, 2007, at 10:53 PM, Santosh Chokhani wrote: >> >> We do want to manage multiple trust anchors. I am mot sure when >> you get >> the impression that we are talking about a single TA. >> > > From statements like: On Jul 3, 2007, at 6:43 PM, Thomas Hardjono wrote: >> If I need to install/delete multiple TAs, I should just run the same >> protocol multiple times. > which I don't think is a sufficient answer. > > - max From owner-ietf-trust-anchor Mon Jul 9 12:12: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 l69JCV72021610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2007 12:12: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 l69JCVQL021609; Mon, 9 Jul 2007 12:12: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 nmta1.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.214]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l69JCUwp021602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Jul 2007 12:12:31 -0700 (MST) (envelope-from hotz@jpl.nasa.gov) Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l69JCT0j022005 for ; Mon, 9 Jul 2007 12:12:29 -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 l69JCRhA018109 for ; Mon, 9 Jul 2007 12:12:27 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <00f201c7bb0f$31566e80$0301a8c0@Wylie> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Henry B. Hotz" Subject: Re: Enterprise-only or more... Date: Mon, 9 Jul 2007 12:12:14 -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: Agreed. Also agree with the point that it's actually authorization decisions we're trying to control. In practical terms "trust" only specifies that appropriate keys are known. That's necessary, but not remotely sufficient for any practical decisions. The decision that a particular chain of keys is OK for a given use *is* an authorization decision whether its called that or not. On Jul 3, 2007, at 10:39 AM, Stephen Kent wrote: > I'd prefer to use a term like "scope of the TA" rather than "trust." ------------------------------------------------------------------------ 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 Tue Jul 10 03:39: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 l6AAd4Vk047352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2007 03:39: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 l6AAd49g047351; Tue, 10 Jul 2007 03:39: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l6AAd3CS047344 for ; Tue, 10 Jul 2007 03:39:03 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 32309 invoked from network); 10 Jul 2007 10:36:56 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Jul 2007 10:36:56 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 10 Jul 2007 10:36:56 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Tue, 10 Jul 2007 06:39:01 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D12A7@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: Problem statement v01 Date: Tue, 10 Jul 2007 06:39:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C2DE.8719BE0E" 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_01C7C2DE.8719BE0E Content-Type: text/plain Since no announce message was sent to the list, here's a link to the -01 problem statement: http://www.ietf.org/internet-drafts/draft-wallace-ta-mgmt-problem-statement- 01.txt. ________________________________ From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Carl Wallace Sent: Friday, July 06, 2007 9:35 AM To: ietf-trust-anchor@vpnc.org Subject: Problem statement v01 I just submitted the -01 version of the problem statement. This includes revisions based on the list discussion of the past few weeks. Aside from general wordsmithing mainly focused on providing a multiple application view vs. a device-centric view, the primary changes are as follows: - Removed section 4 (the Using CMS section) - Added text regarding the need for multiple TA formats - Added most recent TA definition (from Steve K.) - Added text indicating add/removal operations are necessary - Added security consideration regarding integrity and authentication (this was in the Section 4 before) - Clarified that TA managers must be in control of scope constraints ------_=_NextPart_001_01C7C2DE.8719BE0E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Problem statement v01

Since no announce message was sent to the list, = here's a link to the -01 problem statement: http://www.ietf.org/internet-drafts/draft-wallace-ta-m= gmt-problem-statement-01.txt.


________________________________

        From: = owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-= trust-anchor@mail.vpnc.org] On Behalf Of Carl Wallace

        Sent: = Friday, July 06, 2007 9:35 AM
        To: = ietf-trust-anchor@vpnc.org
        Subject: = Problem statement v01
       =20
       =20

        I just = submitted the -01 version of the problem statement.  This includes = revisions based on the list discussion of the past few weeks.  = Aside from general wordsmithing mainly focused on providing a multiple = application view vs. a device-centric view, the primary changes are as = follows:

        - Removed = section 4 (the Using CMS section)
        - Added = text regarding the need for multiple TA formats
        - Added = most recent TA definition (from Steve K.)
        - Added = text indicating add/removal operations are necessary
        - Added = security consideration regarding integrity and authentication (this was = in the Section 4 before)
        - = Clarified that TA managers must be in control of scope constraints =

------_=_NextPart_001_01C7C2DE.8719BE0E-- From owner-ietf-trust-anchor Tue Jul 10 07:40: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 l6AEeD34069355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2007 07:40: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 l6AEeDDs069354; Tue, 10 Jul 2007 07:40: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 [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 l6AEeCnc069340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2007 07:40:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 10 Jul 2007 07:39:27 -0700 To: ietf-trust-anchor@vpnc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-wallace-ta-mgmt-problem-statement-01.txt 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: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Trust Anchor Management Problem Statement Author(s) : R. Reddy, C. Wallace Filename : draft-wallace-ta-mgmt-problem-statement-01.txt Pages : 14 Date : 2007-7-8 This document provides a problem statement for the Trust Anchor Management Birds of a Feather (BOF). Trust anchors are public keys and associated information that are directly trusted by an application or system to validate digital signatures, including signatures covering other public keys. At present, there exists no standard mechanism for distributing and managing trust anchors. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism as well as problems that must be addressed by such a mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wallace-ta-mgmt-problem-statement-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-wallace-ta-mgmt-problem-statement-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-wallace-ta-mgmt-problem-statement-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] From owner-ietf-trust-anchor Tue Jul 10 08:15:50 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 l6AFFn3p072799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2007 08:15:49 -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 l6AFFnrF072798; Tue, 10 Jul 2007 08:15:49 -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 mail.newbay.com (089-101-140017.ntlworld.ie [89.101.140.17] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6AFFkUI072790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2007 08:15:48 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 9FB3C1003F57C for ; Tue, 10 Jul 2007 16:15:45 +0100 (IST) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAPCC8qMCPQ4 for ; Tue, 10 Jul 2007 16:15:43 +0100 (IST) Received: from [192.168.2.190] (sfx41.newbay.com [192.168.2.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id F12601003EB5D for ; Tue, 10 Jul 2007 16:15:42 +0100 (IST) Message-ID: <4693A315.7000200@cs.tcd.ie> Date: Tue, 10 Jul 2007 16:17:41 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-trust-anchor@vpnc.org Subject: Very eary cut at strawman draft charter... Content-Type: multipart/mixed; boundary="------------010603010205050602010507" 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. --------------010603010205050602010507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, Since we seem to be converging to some extent Sean and I, with a bit of help from a few others (they can id themselves if they like:-) threw together a very early strawman charter text. Note that we did not spend time honing the text, we just got it to the stage where we think it fairly, but not particularly precisely, reflects the list discussion to date. If things go well in the 1st half of the Chicago meeting, then it might be worthwhile spending some time on this. Meanwhile we can discuss it on the list. As you'll see the main missing thing is the "out of scope" list, for which I've not seen anything much on the list so far. Cheers, Stephen. --------------010603010205050602010507 Content-Type: text/plain; name="charter-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="charter-01.txt" Strawman charter for trust anchor management (tam) BoF Version: 01, July 9th 2007 Chair(s) TBD Security Area Director(s): - Tim Polk - Sam Hartman Security Area Advisor: TBD Mailing Lists: General Discussion: ietf-trust-anchor@vpnc.org To Subscribe: http://www.vpnc.org/ietf-trust-anchor/ Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/ Description of Working Group: The need for a standard protocol for trust anchor management has been recognized for some time. Many groups within the IETF, including PKIX, Kerberos, TLS and SIDR have a dependency on trust anchors, yet provide no generic mechanism for the their management. A trust anchor is a public key and associated data used by a relying party to begin the process of validating a signature on a signed object. Associated data is used to define the scope of the use of the trust anchor for validating signatures; for example, associated data might limit the types of identifiers in certificates that a trust anchor is allowed to validate. Despite the wide-spread use of trust anchors, there is no standard means for managing these security-critical data. This Working Group will develop a specification to fill this gap. The initial problem statement for this work is to be based on: - draft-wallace-ta-mgmt-problem-statement The scope of the work is to include: <> - Supporting a single trust anchor administrator, such as in a typical enterprise, who may be administering multiple trust anchors in her domain, where those trust anchors can be either local or "foreign" - Supporting multiple trust anchor administrators, such as is typical for home users - Supporting devices with limited or no user interface that may or may not have connected to the Internet The following are out of scope of this work: <> - TBD The deliverables will be: - An informational problem statement/requirements specification for a trust anchor management protocol - A standards track trust anchor management protocol specification Goals and Milestones: +6 months WG last call on problem statement/requirements +9 months Adoption of WG draft protocol spec. +15 months WG last call for protocol spec. --------------010603010205050602010507-- From owner-ietf-trust-anchor Tue Jul 10 12:48: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 l6AJm1E1005243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2007 12:48: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 l6AJm1FU005242; Tue, 10 Jul 2007 12:48: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 cod.sandelman.ca (cod.sandelman.ca [192.139.46.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6AJlwIL005230 for ; Tue, 10 Jul 2007 12:48:00 -0700 (MST) (envelope-from mcr@marajade.sandelman.ca) Received: from sandelman.ottawa.on.ca (fleet-canuck.thintropy.com [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 5C2B01239E for ; Tue, 10 Jul 2007 15:47:53 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 32F504E7A1 for ; Tue, 10 Jul 2007 15:47:52 -0400 (EDT) From: Michael Richardson To: ietf-trust-anchor@vpnc.org Subject: Re: Distribution of trust anchor policy In-Reply-To: Message from Paul Hoffman of "Thu, 21 Jun 2007 10:45:24 PDT." References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) Date: Tue, 10 Jul 2007 15:47:52 -0400 Message-ID: <21681.1184096872@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> Another requirement that I see only touched on a bit in the Paul> first draft is that of policy. As the trust anchor Paul> administrator, I might want to distribute a trust anchor but Paul> to require that it only be used for trusting certificates Paul> whose domain names are in example.com. The trust anchor itself Paul> might not have the name constraint in it, but the constraint yes, an implementation flaw. Paul> is what I, as administrator, am telling my users to trust it Paul> for. Thus, I need to be able to express some kind of policy Paul> with a trust anchor. Well, if instead of storing your trust anchors into some "secure store", one was instead, to have a certificate authority on the system, and instead of entering the trust anchor into the "secure store", one was to instead, to digitally sign the trust anchor with your certificate authority, one could use the name constraints at *THAT LEVEL* to implement your policy. All policy is local. - -- ] 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 iQEVAwUBRpPiYICLcPvd0N1lAQLdmQgArNN7MXIlla6ombXncV+bgIj035nwSh/c A0NnVRXrXONzazKtmKE2/szvtZ1VS3sVtQSDCEC5IKvwdh7BSPcjk24NsHoxSm7R xBCks9zgjfe+8gP7xhpq6ZPXfTPNuqMcI0s4XFBcbjInhfisvCbG/941ZAt+aC/E rV8iY8m/ZGecNwA3vukfrw+5ykXn3koSohaobtNBD12sea7XEkX/GFXbPO54/b19 mz1eXD+4fBSI1bmmqrBOihdI8m0VcI8eme76ukh1zvJDhX/EDQEh8/zpK5iDKCa9 C//5NHd+EhR7Boe9X0vQejzq/sNhUU174HuLUhoMuciAzwwE2Bs/0Q== =7m2+ -----END PGP SIGNATURE----- From owner-ietf-trust-anchor Tue Jul 10 12:51: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 l6AJpELH005683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2007 12:51: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 l6AJpEpB005682; Tue, 10 Jul 2007 12:51: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 cod.sandelman.ca (cod.sandelman.ca [192.139.46.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6AJpDd2005668; Tue, 10 Jul 2007 12:51:13 -0700 (MST) (envelope-from mcr@marajade.sandelman.ca) Received: from sandelman.ottawa.on.ca (fleet-canuck.thintropy.com [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 F2A3F12386; Tue, 10 Jul 2007 15:51:12 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id ACF024E7A1; Tue, 10 Jul 2007 15:51:10 -0400 (EDT) From: Michael Richardson To: "Henry B. Hotz" cc: Paul Hoffman , ietf-trust-anchor@vpnc.org Subject: Re: Distribution of trust anchor policy In-Reply-To: Message from "Henry B. Hotz" of "Thu, 21 Jun 2007 16:50:27 PDT." <606890F7-6C77-4621-9667-4B7317DB5DC3@jpl.nasa.gov> References: <606890F7-6C77-4621-9667-4B7317DB5DC3@jpl.nasa.gov> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) Date: Tue, 10 Jul 2007 15:51:10 -0400 Message-ID: <21894.1184097070@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 >>>>> "Henry" == Henry B Hotz writes: Henry> I'm sitting in front of an email client and I can decode this Henry> email using a cert that traces in a perfectly valid way to Henry> e.g. a Verisign CA. This is a valid CA that I should use for Henry> lots of legitimate email to lots of people, so I *want* this Henry> CA in my trust anchors. Henry> BUT Henry> The specific email in question purports to come from someone Henry> at e.g. NASA HQ. Verisign has not (and maybe can't) specify Henry> any constraints that prohibit the use of the certs in That's an interesting situation. It seems to me that Verisign has violated some protocol somehow, but frankly, the whole X.509/internet/https situation is ALL broken unless there is only one root. Henry> In other words, the problem isn't specifying that a specific Henry> chain is only valid for a specific domain/purpose. The Henry> problem is specifying that no other chain is valid for that Henry> domain/purpose, REGARDLESS OF WHAT THE OTHER CHAINS CLAIM. So, if you could install a name constraint when you installed the verisign CA (and all other CAs), stating this, it would be okay. - -- ] 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 iQEVAwUBRpPjLYCLcPvd0N1lAQIxkgf/eq/SoKwaYPPHJvL5PdrR2J8SCYzclc6c CbLvaWtfKLTiTy8tai9AoloPpNe09TZ+UDKsbyEeyE8lOxJL4Squ50idxtCrhFZu yH5eNRFhnCOQRG7zOwTNUqBqWi/vo6ePJAQKTkx74vdj/GydBLLrbFsFUGNYSKlU AjQrGMw6FcpFK7aAd4Es8Z0rbcdsV61jqX+hzWx5GH9Ra49XIgQbbo7xWpCZswqM wGLOezuTCGbJ+XzuM+G+VgJRURr8mbe68vQbwJ+bumHOn8vxEp4blBfVv9CxVm2E W1DprrwsTKqurDhBalUhju/sQJDeblhfco3a+Iq+lwNPjCoSDyYQTw== =x6jy -----END PGP SIGNATURE----- From owner-ietf-trust-anchor Tue Jul 10 13:27: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 l6AKRm97011075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2007 13:27: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 l6AKRmTu011074; Tue, 10 Jul 2007 13:27: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] (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 l6AKReq2011040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2007 13:27:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <21894.1184097070@marajade.sandelman.ca> References: <606890F7-6C77-4621-9667-4B7317DB5DC3@jpl.nasa.gov> <21894.1184097070@marajade.sandelman.ca> Date: Tue, 10 Jul 2007 13:27:02 -0700 To: Michael Richardson , "Henry B. Hotz" 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 3:51 PM -0400 7/10/07, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>>>>> "Henry" == Henry B Hotz writes: > Henry> I'm sitting in front of an email client and I can decode this > Henry> email using a cert that traces in a perfectly valid way to > Henry> e.g. a Verisign CA. This is a valid CA that I should use for > Henry> lots of legitimate email to lots of people, so I *want* this > Henry> CA in my trust anchors. > > Henry> BUT > > Henry> The specific email in question purports to come from someone > Henry> at e.g. NASA HQ. Verisign has not (and maybe can't) specify > Henry> any constraints that prohibit the use of the certs in > > That's an interesting situation. > It seems to me that Verisign has violated some protocol somehow, Say what? Assuming that VeriSign did its stated due diligence to make sure that public key Kn was actually associated with someone@nasa.gov, then no protocol was violated. What Henry seems to be asking for (which I think is legitimate enough to be a requirement for our work) is a way for a TA administrator to say "for user Un and application An, key Kn is good for validating all signatures except for those in the set of identifiers In, regardless of what the folks who control Kn might think". > but >frankly, the whole X.509/internet/https situation is ALL broken unless >there is only one root. Run by whom?!?!? With what policy?!?! This is bizarre, coming from a developer whose security products supports all support multiple trust anchors. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jul 10 15:45: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 l6AMjWPw025870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2007 15:45: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 l6AMjWAk025869; Tue, 10 Jul 2007 15:45: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 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 l6AMjULT025861 for ; Tue, 10 Jul 2007 15:45: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: What's out of scope? Date: Tue, 10 Jul 2007 15:45:55 -0700 Message-ID: In-Reply-To: <468FE97A.7040404@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What's out of scope? Thread-Index: AcfAzc9+BmbW4hhwQsS/c7uEDXvyMQCdW4aw From: "Thomas Hardjono" To: "Stephen Farrell" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l6AMjVLT025863 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: Saturday, July 07, 2007 12:29 PM > To: ietf-trust-anchor@vpnc.org > Subject: What's out of scope? > > > > Hi all, > > As we get started on drafting a strawman charter (Sean and I > are starting work on that now-ish), I think one of the things > that might be good to be say something about is what's out of scope. > > I would assume that CMC/CMP related managment is out of > scope, as is certificate retrieval (as done by LDAP) and > status checking (SCVP-to-be,OCSP,XKMS). > > Similarly local trust anchor storage and use mechanisms (and > their security) should be out of scope. > > Other inputs? (Don't worry about wording just yet.) > > Cheers, > Stephen. Is it possible to specify a "TA management protocol" without specifying the transport protocol underneath? (ie. make the transport protocol out-of-scope). I'm thinking that many vendors supplying management tools and softwares are moving towards (remote management) using the WS-Manage standard (over SOAP/HTTP/TLS). It would make sense to ensure that the output of this WG could be implemented and operate with/over WS-Man. cheers, /thomas/ From owner-ietf-trust-anchor Tue Jul 10 17:07: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 l6B07XlC031150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2007 17:07: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 l6B07XKi031148; Tue, 10 Jul 2007 17:07: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 [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 l6B07VdI031141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2007 17:07:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 10 Jul 2007 17:06:52 -0700 To: From: Paul Hoffman Subject: RE: What's out of scope? 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:45 PM -0700 7/10/07, Thomas Hardjono wrote: >Is it possible to specify a "TA management protocol" without specifying >the transport protocol underneath? Yes. I will make an argument at the Chicago BoF that the protocol should be stand-alone messages, not an online interaction. >(ie. make the transport protocol >out-of-scope). There is no need to make the transport out of scope. If people agree that our messages are standalone, it is still fine to say "and if you want to pass them back and forth interactively, do it with { HTTP on port 61111 | SMTP | finger | something... }". >I'm thinking that many vendors supplying management tools and softwares >are moving towards (remote management) using the WS-Manage standard >(over SOAP/HTTP/TLS). It would make sense to ensure that the output of >this WG could be implemented and operate with/over WS-Man. I would be happy to support making SOAP out of scope. :-) If we make our messages stand-alone, they can be carried by any transport. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Jul 10 17:06: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 l6B06XML031111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2007 17:06: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 l6B06XL7031110; Tue, 10 Jul 2007 17:06: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 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 l6B06V7t031103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 Jul 2007 17:06:32 -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 F3827321FD; Wed, 11 Jul 2007 01:06:30 +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 l6B06Pbn010500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jul 2007 01:06:25 +0100 Message-ID: <46941F71.7020409@cs.tcd.ie> Date: Wed, 11 Jul 2007 01:08:17 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Thomas Hardjono CC: ietf-trust-anchor@vpnc.org Subject: Re: What's out of scope? 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: 11403413 - faaecce179ce (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: Thomas Hardjono wrote: > > >> -----Original Message----- >> From: owner-ietf-trust-anchor@mail.vpnc.org >> [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of >> Stephen Farrell >> Sent: Saturday, July 07, 2007 12:29 PM >> To: ietf-trust-anchor@vpnc.org >> Subject: What's out of scope? >> >> >> >> Hi all, >> >> As we get started on drafting a strawman charter (Sean and I >> are starting work on that now-ish), I think one of the things >> that might be good to be say something about is what's out of scope. >> >> I would assume that CMC/CMP related managment is out of >> scope, as is certificate retrieval (as done by LDAP) and >> status checking (SCVP-to-be,OCSP,XKMS). >> >> Similarly local trust anchor storage and use mechanisms (and >> their security) should be out of scope. >> >> Other inputs? (Don't worry about wording just yet.) >> >> Cheers, >> Stephen. > > Is it possible to specify a "TA management protocol" without specifying > the transport protocol underneath? (ie. make the transport protocol > out-of-scope). > > I'm thinking that many vendors supplying management tools and softwares > are moving towards (remote management) using the WS-Manage standard > (over SOAP/HTTP/TLS). It would make sense to ensure that the output of > this WG could be implemented and operate with/over WS-Man. I'm not sure if "out of scope" is the best phrase for that. Perhaps "transport agnostic" is more what you're after. If so, that's a bit different, and is to an extent covered by saying that the protocol should be able to be used in both client/server and store-and-forward contexts (which did seem to be supported earlier on the list). That does leave open the question of how to get interop, but that's something that's been figured out before and can be done again, so there are fairly well known answers, even though all of them are inherently more complicated than the option of just choosing one transport. Cheers, S. From owner-ietf-trust-anchor Tue Jul 10 17:51: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 l6B0ptei033999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2007 17:51: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 l6B0ptVP033998; Tue, 10 Jul 2007 17:51: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 mailbox.reptiles.org (mail.reptiles.org [198.96.210.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6B0psw5033991 for ; Tue, 10 Jul 2007 17:51:55 -0700 (MST) (envelope-from cat@reptiles.org) Received: from mail.reptiles.org ([198.96.210.227] port=56762) by mailbox.reptiles.org([198.96.210.227] port=25) via TCP with esmtp (1963 bytes) (sender: ) (ident using UNIX) id for ; Tue, 10 Jul 2007 20:51:48 -0400 (EDT) (Smail-3.2.0.121 2005-Nov-17 #4 built 2006-Nov-28) Date: Tue, 10 Jul 2007 20:51:47 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@gecko.reptiles.org Reply-To: Cat Okita To: Stephen Farrell cc: Thomas Hardjono , ietf-trust-anchor@vpnc.org Subject: Re: What's out of scope? In-Reply-To: <46941F71.7020409@cs.tcd.ie> Message-ID: <20070710205047.K37986@gecko.reptiles.org> References: <46941F71.7020409@cs.tcd.ie> 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 Wed, 11 Jul 2007, Stephen Farrell wrote: >> I'm thinking that many vendors supplying management tools and softwares >> are moving towards (remote management) using the WS-Manage standard >> (over SOAP/HTTP/TLS). It would make sense to ensure that the output of >> this WG could be implemented and operate with/over WS-Man. > > I'm not sure if "out of scope" is the best phrase for that. Perhaps > "transport agnostic" is more what you're after. If so, that's a bit > different, and is to an extent covered by saying that the protocol > should be able to be used in both client/server and store-and-forward > contexts (which did seem to be supported earlier on the list). I think transport agnostic is more to the point - out of scope leaves a fine swamp to get stuck in later. 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 Wed Jul 11 01:22: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 l6B8MgRK066601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 01:22: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 l6B8MgCw066600; Wed, 11 Jul 2007 01:22: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 nmta1.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.214]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6B8Mf2V066592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Jul 2007 01:22:41 -0700 (MST) (envelope-from hotz@jpl.nasa.gov) Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l6B8Mb2h031247 for ; Wed, 11 Jul 2007 01:22:37 -0700 Received: from [192.168.2.2] (vpn-149-246-028.jpl.nasa.gov [128.149.246.28]) by xmta3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l6B8MYLu029557 for ; Wed, 11 Jul 2007 01:22:36 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070710205047.K37986@gecko.reptiles.org> References: <46941F71.7020409@cs.tcd.ie> <20070710205047.K37986@gecko.reptiles.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26730EC5-9160-4961-9BFD-9D1C1A4BEC52@jpl.nasa.gov> Content-Transfer-Encoding: 7bit From: "Henry B. Hotz" Subject: Re: What's out of scope? Date: Wed, 11 Jul 2007 00:21:32 -0700 To: ietf-trust-anchor@vpnc.org X-Mailer: Apple Mail (2.752.3) X-Source-IP: vpn-149-246-028.jpl.nasa.gov [128.149.246.28] 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: It's fine to define the messages and their content without the transport mechanism. That's what SASL and GSSAPI do for example. Also fine to put transport stuff in separate rfc's. On Jul 10, 2007, at 5:51 PM, Cat Okita wrote: > > On Wed, 11 Jul 2007, Stephen Farrell wrote: >>> I'm thinking that many vendors supplying management tools and >>> softwares >>> are moving towards (remote management) using the WS-Manage standard >>> (over SOAP/HTTP/TLS). It would make sense to ensure that the >>> output of >>> this WG could be implemented and operate with/over WS-Man. >> >> I'm not sure if "out of scope" is the best phrase for that. Perhaps >> "transport agnostic" is more what you're after. If so, that's a bit >> different, and is to an extent covered by saying that the protocol >> should be able to be used in both client/server and store-and-forward >> contexts (which did seem to be supported earlier on the list). > > I think transport agnostic is more to the point - out of scope leaves > a fine swamp to get stuck in later. > > cheers! ------------------------------------------------------------------------ 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 Wed Jul 11 20:39: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 l6C3dXPW071355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 20:39: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 l6C3dXk6071354; Wed, 11 Jul 2007 20:39: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 woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l6C3dUYJ071347 for ; Wed, 11 Jul 2007 20:39:33 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200707120339.l6C3dUYJ071347@balder-227.proper.com> Received: (qmail 1216 invoked by uid 0); 12 Jul 2007 03:39:14 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (66.44.55.141) by woodstock.binhost.com with SMTP; 12 Jul 2007 03:39:14 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Jul 2007 11:55:38 -0400 To: ietf-trust-anchor@vpnc.org From: Russ Housley Subject: RE: Enterprise-only or more... In-Reply-To: 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: Clearly, a trust anchor contains a public key that is used to validate digital signatures. A trust anchor public key may be used in two different ways to support digital signature validation. In the first approach, the trust anchor public key is used directly to validate the digital signature. In the second approach, the trust anchor public key is used to validate a certification path. I'm thinking about an X.509 certification path, but this model seems to work with other certification approaches as well. When used with a certification path, the subject public key in the final certificate in the certification path is used to validate the digital signature. Of course, such a certified public key can be used for things other than digital signature, including key transport and key agreement. In X.509, the choices are constrained by the key usage certificate extension. All trust anchors used in the X.509 context consist of the following components: - a public key signature algorithm identifier and associated public key, which may optionally include parameters; - a distinguished name for use in certification path validation and construction; - a public key identifier to aid path construction and for use in signatures that are to be validated directly with the trust anchor public key; - a list of applications (perhaps admitting all applications) with which the trust anchor can be used; and - optional X.509 certification path validation input values, some of which also serve as constraints on the use of the public key when used directly to validate digital signatures. A similar set of components needs to be specified for any other contexts that we want to support (PGP, DNSSEC, etc.). One might also want a human readable trust anchor title to help with display of the trust anchor store to users. Depending on the approach taken in the trust anchor management protocol, a trust anchor might also include a sequence number for replay detection. Russ From owner-ietf-trust-anchor Wed Jul 18 12:19: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 l6IJJPuw026797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 12:19: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 l6IJJPxQ026796; Wed, 18 Jul 2007 12:19: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 [165.227.249.220] (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 l6IJJNwd026785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jul 2007 12:19:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 18 Jul 2007 12:18:46 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Article on trust anchor problems in Windows XP and Vista 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. I have posted a new security research article at . It relates directly to trust anchors, and maybe will help motivate some of the work here. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Jul 20 11:49: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 l6KIn4uS063860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jul 2007 11:49: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 l6KIn4xh063859; Fri, 20 Jul 2007 11:49: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 smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l6KIn2no063851 for ; Fri, 20 Jul 2007 11:49:03 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 84745 invoked from network); 20 Jul 2007 18:49:02 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.7.243 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 20 Jul 2007 18:49:02 -0000 X-YMail-OSG: d0lItgQVM1mrQgMCL9DywmsxyjhQEo6TGwobQ1D2ABExDwxcNYoa.K6kJS8ClJT.C4JYNrep0tpIZI5G2IfOlJQZFuRvH7ItUxssITgQCU1o1e.4lhzVovatPLf7JSZiRSgmAHtJ4oqEJg-- Reply-To: From: "Turner, Sean P." To: Subject: jabber Date: Fri, 20 Jul 2007 14:39:14 -0400 Organization: IECA, Inc. Message-ID: <025301c7cafd$4583ca30$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0254_01C7CADB.BE722A30" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfK/UUddwos1dv9TLadSjAYArpgWA== 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_000_0254_01C7CADB.BE722A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In case you are not planning on attending the meeting in person you can always do so remotely: http://ietf.org/meetings/text_conf.html#start Stephen and I will draft a jabber scribe if no one volunteers. spt ------=_NextPart_000_0254_01C7CADB.BE722A30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable jabber

In case you are not planning on = attending the meeting in person you can always do so remotely:

http://ietf.org/meetings/text_conf.html#start

Stephen and I will draft a jabber = scribe if no one volunteers.

spt

------=_NextPart_000_0254_01C7CADB.BE722A30-- From owner-ietf-trust-anchor Sat Jul 21 11:57:16 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 l6LIvGe2072514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Jul 2007 11:57:16 -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 l6LIvGqO072513; Sat, 21 Jul 2007 11:57:16 -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] (dhcp64-134-126-120.sjca.sjc.wayport.net [64.134.126.120]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6LIvEFC072506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Jul 2007 11:57:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <025301c7cafd$4583ca30$0301a8c0@Wylie> References: <025301c7cafd$4583ca30$0301a8c0@Wylie> Date: Sat, 21 Jul 2007 11:57:03 -0700 To: From: Paul Hoffman Subject: Re: jabber 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:39 PM -0400 7/20/07, Turner, Sean P. wrote: >In case you are not planning on attending the meeting in person you >can always do so remotely: > >http://ietf.org/meetings/text_conf.html#start > >Stephen and I will draft a jabber scribe if no one volunteers. You should also probably be able to listen. The chart is not fully filled in at the moment, but see for information on how to find the audio track. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Wed Jul 25 07:28: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 l6PES2T3019341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 07:28: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 l6PES2YN019339; Wed, 25 Jul 2007 07:28: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 [130.129.17.106] (dhcp-14d8.ietf69.org [130.129.20.216]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6PERxZ2019321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jul 2007 07:28:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <025301c7cafd$4583ca30$0301a8c0@Wylie> Date: Wed, 25 Jul 2007 09:27:56 -0500 To: From: Paul Hoffman Subject: Re: jabber 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: >You should also probably be able to listen. The chart is not fully >filled in at the moment, but see > for information on how to >find the audio track. The audio people have updated the site to have the information needed for listening in. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Wed Jul 25 08:25:49 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 l6PFPnJL038750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 08:25:49 -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 l6PFPnkg038749; Wed, 25 Jul 2007 08:25:49 -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.mud.yahoo.com (smtp100.biz.mail.mud.yahoo.com [68.142.201.176]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l6PFPjth038731 for ; Wed, 25 Jul 2007 08:25:48 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 42244 invoked from network); 25 Jul 2007 15:25:45 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.18.223 with login) by smtp100.biz.mail.mud.yahoo.com with SMTP; 25 Jul 2007 15:25:45 -0000 X-YMail-OSG: 1i.SrVMVM1kn_2c0JjzXZzF1YHiD4qarEoPMVzzMnD4w148SvVdiNvpeRNhWLHuhkQcRsWwv5NTU81VaHPdDQ9EpICtxhoGRDD0Yii_QDSAjh6_j3fE- Reply-To: From: "Turner, Sean P." To: Subject: TAM BOF Agenda and Slides Date: Wed, 25 Jul 2007 10:15:40 -0500 Organization: IECA, Inc. Message-ID: <009301c7cece$aa3df340$df128182@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0094_01C7CEA4.C167EB40" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfOzqmDK1zvzOltT0yvjli+c8GO+Q== 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_000_0094_01C7CEA4.C167EB40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In case you were unaware, the agenda and slides that will be presented are posted to (scroll down to TAM BOF): https://datatracker.ietf.org/meeting/69/materials.html Other presentations will be uploaded as they are received. spt ------=_NextPart_000_0094_01C7CEA4.C167EB40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TAM BOF Agenda and Slides

In case you were unaware, the agenda = and slides that will be presented are posted to (scroll down to TAM = BOF):

https://datatracker.ietf.org/meeting/69/materials.html

Other presentations will be uploaded as = they are received.

spt

------=_NextPart_000_0094_01C7CEA4.C167EB40-- From owner-ietf-trust-anchor Wed Jul 25 10:42: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 l6PHgDVG083644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 10:42: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 l6PHgDmW083643; Wed, 25 Jul 2007 10:42: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 keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6PHgCuN083626 for ; Wed, 25 Jul 2007 10:42:12 -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 39F5B1F6861 for ; Wed, 25 Jul 2007 10:42:12 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Wed, 25 Jul 2007 10:42:12 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Wed, 25 Jul 2007 10:42:12 -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 1920188 for ietf-trust-anchor@vpnc.org; Wed, 25 Jul 2007 10:42:08 -0700 Received: from [66.93.68.165] ([66.93.68.165]) by keys.pgpeng.com (PGP Universal service); Wed, 25 Jul 2007 10:42:08 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Wed, 25 Jul 2007 10:42:08 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <025301c7cafd$4583ca30$0301a8c0@Wylie> Message-Id: From: Jon Callas Subject: Re: jabber Date: Wed, 25 Jul 2007 10:42:24 -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 Jul 25, 2007, at 7:27 AM, Paul Hoffman wrote: > >> You should also probably be able to listen. The chart is not fully >> filled in at the moment, but see > events/ietf/> for information on how to find the audio track. > > The audio people have updated the site to have the information > needed for listening in. > Is the Jabber room going to be tam@jabber.ietf.org? 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 Wed Jul 25 10:46: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 l6PHkr6W085181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 10:46: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 l6PHkr1a085180; Wed, 25 Jul 2007 10:46: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 hiltonsmtp.worldspice.net (hiltonsmtp.worldspice.net [216.37.94.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6PHkqRU085165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jul 2007 10:46:53 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: (qmail 32222 invoked by uid 0); 25 Jul 2007 17:39:14 -0000 Received: by simscan 1.2.0 ppid: 32198, pid: 32203, t: 0.7689s scanners: clamav: 0.90.2/m: spam: 3.1.8 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on hiltonsmtp.worldspice.net X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=6.5 tests=BAYES_99,RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO ?172.28.168.188?) (67.97.210.2) by hiltonsmtp.worldspice.net with SMTP; 25 Jul 2007 17:39:14 -0000 Message-ID: <46A78D05.6000700@cs.tcd.ie> Date: Wed, 25 Jul 2007 18:48:53 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Jon Callas CC: ietf-trust-anchor@vpnc.org Subject: Re: jabber References: <025301c7cafd$4583ca30$0301a8c0@Wylie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > > > On Jul 25, 2007, at 7:27 AM, Paul Hoffman wrote: > >> >>> You should also probably be able to listen. The chart is not fully >>> filled in at the moment, but see >>> for information on how to >>> find the audio track. >> >> The audio people have updated the site to have the information needed >> for listening in. >> > > Is the Jabber room going to be tam@jabber.ietf.org? I believe so. Seems to work now anyway, S. From owner-ietf-trust-anchor Wed Jul 25 10:52: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 l6PHqQxl086767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 10:52: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 l6PHqQTI086766; Wed, 25 Jul 2007 10:52: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 smtp110.biz.mail.mud.yahoo.com (smtp110.biz.mail.mud.yahoo.com [68.142.201.179]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l6PHqOx9086750 for ; Wed, 25 Jul 2007 10:52:25 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 97405 invoked from network); 25 Jul 2007 17:52:24 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.18.223 with login) by smtp110.biz.mail.mud.yahoo.com with SMTP; 25 Jul 2007 17:52:24 -0000 X-YMail-OSG: r0d.P2EVM1meRWjHEYr7cKZFi4cX.SpVh_mU526MKKB.7tQ9f3i3OsXmCvLwYtYdDow_QIL0lZaaRo9CuTcnUYAEFntQ9NOTt5NrL7iE5zQ4ebSMjXHzMvq85htdHQ-- Reply-To: From: "Turner, Sean P." To: "'Jon Callas'" , References: <025301c7cafd$4583ca30$0301a8c0@Wylie> Subject: RE: jabber Date: Wed, 25 Jul 2007 12:42:19 -0500 Organization: IECA, Inc. Message-ID: <001201c7cee3$27036360$df128182@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: Thread-Index: AcfO45sy8nKRHDnoRa+ScGQVpyflNgAAIp6g 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: Yes -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Jon Callas Sent: Wednesday, July 25, 2007 12:42 PM To: ietf-trust-anchor@vpnc.org Subject: Re: jabber On Jul 25, 2007, at 7:27 AM, Paul Hoffman wrote: > >> You should also probably be able to listen. The chart is not fully >> filled in at the moment, but see > events/ietf/> for information on how to find the audio track. > > The audio people have updated the site to have the information needed > for listening in. > Is the Jabber room going to be tam@jabber.ietf.org? 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 Jul 27 09:47: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 l6RGlI5U073885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jul 2007 09:47: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 l6RGlIop073884; Fri, 27 Jul 2007 09:47: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 hiltonsmtp.worldspice.net (hiltonsmtp.worldspice.net [216.37.94.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6RGlGYf073876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jul 2007 09:47:17 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: (qmail 15050 invoked by uid 0); 27 Jul 2007 16:39:36 -0000 Received: by simscan 1.2.0 ppid: 15044, pid: 15045, t: 0.7287s scanners: clamav: 0.90.2/m: spam: 3.1.8 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on hiltonsmtp.worldspice.net X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=6.2 tests=BAYES_99,RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO ?172.28.170.138?) (67.97.210.2) by hiltonsmtp.worldspice.net with SMTP; 27 Jul 2007 16:39:35 -0000 Message-ID: <46AA220D.7070100@cs.tcd.ie> Date: Fri, 27 Jul 2007 17:49:17 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ietf-trust-anchor@vpnc.org Subject: BoF minutes... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ...no we don't have any yet:-) Thanks to everyone for what I thought was a v. useful discussion today. Sean and I will gather a draft set of minutes and post them here, probably next week due to travel. S. From owner-ietf-trust-anchor Mon Aug 6 05:32: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 l76CW9nC004238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 05:32: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 l76CW9hp004237; Mon, 6 Aug 2007 05:32: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 smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l76CW8vL004223 for ; Mon, 6 Aug 2007 05:32:08 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 81633 invoked from network); 6 Aug 2007 12:32:07 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.2.68 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 6 Aug 2007 12:32:07 -0000 X-YMail-OSG: ZUQeZRAVM1kkgRksd60L0VVtis9SIc0X99uY90WRgJ735r8Y8NwKYB84Y_byz..vG11RGgImEFAJ43sjIMk7wNJLtRN.rXKE7eS.avomkfNkV8o.FGczpQqOvM.A4uv0cviVDqHHSnjQ.S0- Reply-To: From: "Turner, Sean P." To: Subject: TAM BOF Minutes Date: Mon, 6 Aug 2007 08:21:30 -0400 Organization: IECA, Inc. Message-ID: <00e101c7d824$51c97d10$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: AcfYJFFs4IKkyRIxSdC7cn/r4vQI2w== 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: Trust Anchor Management (tam) Birds of a Feather (BoF) 69th Internet Engineering Task Force (IETF) Chairs: Sean Turner Stephen Farrell Mailing List: ietf-trust-anchor@vpnc.org Summary: The tam BoF was held on Friday, 27 July 2007. Approximately 120 attendees came to the meeting in person; approximately 40 people were on jabber, some were on both. The BoF co-chairs conducted agenda bashing; no additional speakers were added. Background and meeting goals were also provided by the co-chairs. This information provided context for audience members who have not been part of the mailing list discussion. (Slides presented at the BoF are available at: https://datatracker.ietf.org/meeting/69/materials.html) Carl Wallace presented the problem statement (see "Problem Statement" slides). Explained the: trust anchor (TA) concept and uses, general problem and proposal, proposed a list of functional properties, and outlined security considerations. Received questions regarding feasibility of doing all the items listed as functional requirements, the threat model that might apply and the need for confidentiality, among others. Paul Hoffman presented non-enterprise scenarios (see "TAM Scenarios" slides). Provided: background, terminology information, one and/or multiple TA administrator (TAA) scenarios, and examples of systems that need trust management. Received questions regarding: the vision between the user and the TAA; doing transfer protocol, acquisition protocol, or both; whether work would be for managing number of application information; among others. A concern about properly scoping the problem was raised. Raksha Reddy presented the enterprise case (no slides). Presented the NSA/DoD view on support for this topic. The primary reason was there are things the DoD wants to manage in their specialized space, that would benefit from having a TA management protocol. Indicated interest in having a collaborative effort for development. The remainder of the time was used for open mic discussion and hums (show of hands). Concern raised about the apparent lack of industry/vendor support for the concept. Questions about whether to include devices and browsers, or limit the scope. Comment that the Trusted Computer Group (TCG) has a lot of interest in this topic. Comment that vendors are not at the BoF yet because they don't know that they need to be. Clarification from the AD that working group formation was not the objective of this BoF. Goal is to determine if there is a real problem, who cares about it, and is there a constituency for it. Comments from the government of Canada regarding: - Title/ownership management (assurance of integrity and originator in protocols) - Liability management (assurance of authority in protocols) - Protocol for concept of relinquishment (at time of manufacture, at time of distribution, at time of use in the field) - Protocol for policy management (reflecting on conditions of use such as licensing arrangements, restrictions on the use of intellectual property rights) - Protocol for identification of liability from both the perspective of assurance of authority and of non-repudiation (useful in establishing risk and addressing it in appropriate business plans Comment questioning whether trust anchor management is a subset of remote management, is it covered by netconf? Polling by co-chairs to determine support, results are as follows: - About half the room in favor of the IETF working on the idea (no hands against) - 20 to actively work the topic - Another 12 to review - 10 to implement (if its of good quality) Will take the topic back to the mailing list. Need to get a better understanding of what "this" is (scope). Will use the mailing list to do scoping, refine questions, build/recruit/demonstrate more constituency. Monitor the list to see how the group is progressing. From owner-ietf-trust-anchor Thu Aug 9 15:19:58 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 l79MJwCv006968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 15:19: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 l79MJwso006967; Thu, 9 Aug 2007 15:19: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 l79MJuMA006958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Aug 2007 15:19:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 9 Aug 2007 15:19:40 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Nailing down the definition of "trust anchor" 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 of the topics earlier on the mailing list was defining what a "trust anchor" is. A few of us hammered out the following words. If folks like them, great, we can move on to harder topics. If not, let's see if we can coalesce on words that work. ----- A trust anchor is a public key and associated data used by a relying party to begin the process of validating a signature on a signed object. Associated data is used to define the scope of the use of the trust anchor for validating signatures. For example, associated data might limit the types of identifiers in certificates that a trust anchor is allowed to validate. ----- Given the number of people at the TAM BoF who were confused about what "associated data" might be, I think it is important for us to call it out and to give a fairly easy example. Thus, the third sentence is not technically part of the definition, but it is fairly important to helping the reader understand what we are talking about. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Aug 9 15:29: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 l79MTFEY007468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 15:29: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 l79MTFAQ007467; Thu, 9 Aug 2007 15:29: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 [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 l79MTDG7007460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Aug 2007 15:29:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 9 Aug 2007 15:28:58 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Issue with the requirements document: PKIX-centric terminology 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. draft-wallace-ta-mgmt-problem-statement-01.txt does a good job of listing the problems we need to deal with, but some parts use PKIX language in places they don't need to. It's fine if these places are marked off with "for example, in PKIX ...", but in many places that is not included. To help make it clearer that the requirements are for management of all public keys, I propose that the following topics be removed or delimited as PKIXy examples: - Name constraints - Key usage - Expiration dates of keys - Possibly others that I have missed --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Aug 9 15:30: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 l79MU9qQ007522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 15:30: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 l79MU9AU007521; Thu, 9 Aug 2007 15:30: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 hiroshima.bogus.com (hiroshima.bogus.com [147.28.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l79MU7ds007507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 15:30:08 -0700 (MST) (envelope-from llynch@civil-tongue.net) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.13.8/8.13.8) with ESMTP id l79MU7Dq062344; Thu, 9 Aug 2007 15:30:07 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.13.8/8.13.8/Submit) with ESMTP id l79MU7Qs062341; Thu, 9 Aug 2007 15:30:07 -0700 (PDT) (envelope-from llynch@civil-tongue.net) X-Authentication-Warning: hiroshima.bogus.com: llynch owned process doing -bs Date: Thu, 9 Aug 2007 15:30:07 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Paul Hoffman cc: ietf-trust-anchor@vpnc.org Subject: Re: Nailing down the definition of "trust anchor" In-Reply-To: Message-ID: <20070809152755.S46118@hiroshima.bogus.com> 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, 9 Aug 2007, Paul Hoffman wrote: > > Greetings again. One of the topics earlier on the mailing list was defining > what a "trust anchor" is. A few of us hammered out the following words. If > folks like them, great, we can move on to harder topics. If not, let's see if > we can coalesce on words that work. > > ----- > A trust anchor is a public key and associated data used by a relying party to > begin the process of validating a signature on a signed object. Associated > data is used to define the scope of the use of the trust anchor for > validating signatures. For example, associated data might limit the types of > identifiers in certificates that a trust anchor is allowed to validate. > ----- Paul - Really nit-picky question: do you really mean "to begin" or would "in" work... as in: "A trust anchor is a public key and associated data used by a relying party in the process of validating a signature on a signed object." - Lucy > Given the number of people at the TAM BoF who were confused about what > "associated data" might be, I think it is important for us to call it out and > to give a fairly easy example. Thus, the third sentence is not technically > part of the definition, but it is fairly important to helping the reader > understand what we are talking about. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-trust-anchor Thu Aug 9 15:52: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 l79MqAcX009166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 15:52: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 l79MqAvH009165; Thu, 9 Aug 2007 15:52: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 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 l79Mq9PB009151; Thu, 9 Aug 2007 15:52: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: Nailing down the definition of "trust anchor" Date: Thu, 9 Aug 2007 15:52:45 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nailing down the definition of "trust anchor" Thread-Index: Acfa1Yg8TlImZ5AlR9OUekpAQpkNxQAAdH8g From: "Thomas Hardjono" To: "Paul Hoffman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l79MqAPB009153 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul, Looks good. Perhaps if the words "associated data" remain too broad/vague, we could add a further distinction regarding "data": - TA description data: information about the type of key, key length, algorithm etc (ie. the usual profile related info) of the TA public key. - TA usage data: namely the scope of the use of the trust anchor. /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, August 09, 2007 3:20 PM > To: ietf-trust-anchor@vpnc.org > Subject: Nailing down the definition of "trust anchor" > > > Greetings again. One of the topics earlier on the mailing > list was defining what a "trust anchor" is. A few of us > hammered out the following words. If folks like them, great, > we can move on to harder topics. If not, let's see if we can > coalesce on words that work. > > ----- > A trust anchor is a public key and associated data used by a > relying party to begin the process of validating a signature > on a signed object. Associated data is used to define the > scope of the use of the trust anchor for validating > signatures. For example, associated data might limit the > types of identifiers in certificates that a trust anchor is > allowed to validate. > ----- > > Given the number of people at the TAM BoF who were confused > about what "associated data" might be, I think it is > important for us to call it out and to give a fairly easy > example. Thus, the third sentence is not technically part of > the definition, but it is fairly important to helping the > reader understand what we are talking about. > > --Paul Hoffman, Director > --VPN Consortium > > From owner-ietf-trust-anchor Thu Aug 9 15:54: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 l79Ms1Tl009276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 15:54: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 l79Ms1rt009275; Thu, 9 Aug 2007 15:54: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 [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 l79Mrr43009262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 15:53:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20070809152755.S46118@hiroshima.bogus.com> References: <20070809152755.S46118@hiroshima.bogus.com> Date: Thu, 9 Aug 2007 15:53:37 -0700 To: Lucy Lynch From: Paul Hoffman Subject: Re: Nailing down the definition of "trust anchor" 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:30 PM -0700 8/9/07, Lucy Lynch wrote: >Really nit-picky question: Really nit-picky is quite appropriate at this juncture! >do you really mean "to begin" or would "in" work... as in: > >"A trust anchor is a public key and associated data used by a >relying party in the process of validating a signature on a signed >object." I really meant "to begin" because these are trust anchors, not keys that might appear in the middle of a validation chain. For example, assume you are trying to validate key A, which chains to key B, which chains to key C, which chains to key D which you trust inherently. Only key D is a trust anchor. Key B and key C are used "in the process of validating". --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Aug 9 16:06:49 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 l79N6mvF010243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 16:06: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 l79N6mTi010242; Thu, 9 Aug 2007 16:06: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 smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l79N6kCc010229 for ; Thu, 9 Aug 2007 16:06:47 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 20989 invoked from network); 9 Aug 2007 23:06:40 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.35.187 with login) by smtp109.biz.mail.re2.yahoo.com with SMTP; 9 Aug 2007 23:06:40 -0000 X-YMail-OSG: vfLcQsoVM1n_KBLv4..ah1nKtQQ6gFCFEalmpNyDXdTPsLoYribyVOsN6YH4BGlbuIsE3Bj7ffnYQpSk.uXAidHDTRiOLe3aEHPW2D7CtC4FKk0.XDU- Reply-To: From: "Turner, Sean P." To: Subject: Draft Charter Date: Thu, 9 Aug 2007 18:55:47 -0400 Organization: IECA, Inc. Message-ID: <000801c7dad8$6ee87e30$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_01C7DAB6.E7D6DE30" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfa2GzES6VtkbIxSn+fWYnL9yTUtQ== 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_000_0009_01C7DAB6.E7D6DE30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Attached is a draft of the charter that was distributed prior to the meeting. Primarily we need to discuss the scenarios (enterprise/non-enterprise) and scoping (browsers/devices/etc). spt PS thanks for all the participation at the BOF! ------=_NextPart_000_0009_01C7DAB6.E7D6DE30 Content-Type: text/plain; name="charter-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="charter-01.txt" Strawman charter for trust anchor management (tam) BoF Version: 01, July 9th 2007 Chair(s)=20 TBD Security Area Director(s): - Tim Polk - Sam Hartman Security Area Advisor: TBD Mailing Lists: General Discussion: ietf-trust-anchor@vpnc.org To Subscribe: http://www.vpnc.org/ietf-trust-anchor/ Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/ Description of Working Group: The need for a standard protocol for trust anchor management has been recognized for some time. Many groups within the IETF, including PKIX, Kerberos, TLS and SIDR have a dependency on trust anchors, yet provide = no generic mechanism for the their management. =20 A trust anchor is a public key and associated data used by a relying = party to begin the process of validating a signature on a signed object. = Associated data is used to define the scope of the use of the trust anchor for = validating signatures; for example, associated data might limit the types of = identifiers in certificates that a trust anchor is allowed to validate.=20 Despite the wide-spread use of trust anchors, there is no standard means = for managing these security-critical data. This Working Group will develop = a specification to fill this gap. The initial problem statement for this work is to be based on: - draft-wallace-ta-mgmt-problem-statement The scope of the work is to include: <> - Supporting a single trust anchor administrator, such as in a typical enterprise, who may be administering multiple trust anchors in her = domain, where those trust anchors can be either local or "foreign" - Supporting multiple trust anchor administrators, such as is typical = for home users - Supporting devices with limited or no user interface that may or may = not have connected to the Internet The following are out of scope of this work: <> - TBD The deliverables will be: - An informational problem statement/requirements specification for a trust anchor management protocol - A standards track trust anchor management protocol=20 specification Goals and Milestones: +6 months WG last call on problem statement/requirements +9 months Adoption of WG draft protocol spec. +15 months WG last call for protocol spec. ------=_NextPart_000_0009_01C7DAB6.E7D6DE30-- From owner-ietf-trust-anchor Thu Aug 9 16:00: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 l79N0rVk009792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 16:00: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 l79N0rKM009791; Thu, 9 Aug 2007 16:00: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 sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l79N0owq009776; Thu, 9 Aug 2007 16:00:52 -0700 (MST) (envelope-from pritikin@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Aug 2007 16:00:50 -0700 X-IronPort-AV: i="4.19,243,1183359600"; d="scan'208"; a="12941621:sNHT21304488" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l79N0nEf032636; Thu, 9 Aug 2007 16:00:49 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l79N0jiF011082; Thu, 9 Aug 2007 23:00:49 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 16:00:44 -0700 Received: from [10.32.244.70] ([10.32.244.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 16:00:44 -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: <1D35DE5A-8BDA-4490-A70F-4B67F5031D89@cisco.com> Cc: "Paul Hoffman" , Content-Transfer-Encoding: 7bit From: Max Pritikin Subject: Re: Nailing down the definition of "trust anchor" Date: Thu, 9 Aug 2007 18:00:28 -0500 To: "Thomas Hardjono" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Aug 2007 23:00:44.0596 (UTC) FILETIME=[1DCB2740:01C7DAD9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2303; t=1186700449; x=1187564449; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pritikin@cisco.com; z=From:=20Max=20Pritikin=20 |Subject:=20Re=3A=20Nailing=20down=20the=20definition=20of=20=22trust=20a nchor=22 |Sender:=20; bh=Zo/1SRJ2tkCDeqmpVhFuyqb8gQwuQIg/huS2iZ3zi4c=; b=kkMHKdsGiccpiUsKHq0MkZgIKSl0Sja11J9PV2WWRYMRyfCxKV5gdmIaWPJ8rBnV01fIdVTl a8ItepDtSUPEbV1I2pcZQgSOPGkDrMGQ84/V/akJg2R9576POZ0bj+uY; Authentication-Results: sj-dkim-3; header.From=pritikin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Personally I think "associated data" is enough for now. The exact types forms/types of the data are less important, no? But if we do want to clarify it further -- since the one intention is to perform management functions this "associated data" would seem to include configuration information appropriate to said management. For example protocol or port information. - max On Aug 9, 2007, at 5:52 PM, Thomas Hardjono wrote: > > > Paul, > > Looks good. Perhaps if the words "associated data" remain too > broad/vague, we could add a further distinction regarding "data": > > - TA description data: information about the type of key, > key length, algorithm etc (ie. the usual profile related > info) of the TA public key. > > - TA usage data: namely the scope of the use of the trust anchor. > > /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, August 09, 2007 3:20 PM >> To: ietf-trust-anchor@vpnc.org >> Subject: Nailing down the definition of "trust anchor" >> >> >> Greetings again. One of the topics earlier on the mailing >> list was defining what a "trust anchor" is. A few of us >> hammered out the following words. If folks like them, great, >> we can move on to harder topics. If not, let's see if we can >> coalesce on words that work. >> >> ----- >> A trust anchor is a public key and associated data used by a >> relying party to begin the process of validating a signature >> on a signed object. Associated data is used to define the >> scope of the use of the trust anchor for validating >> signatures. For example, associated data might limit the >> types of identifiers in certificates that a trust anchor is >> allowed to validate. >> ----- >> >> Given the number of people at the TAM BoF who were confused >> about what "associated data" might be, I think it is >> important for us to call it out and to give a fairly easy >> example. Thus, the third sentence is not technically part of >> the definition, but it is fairly important to helping the >> reader understand what we are talking about. >> >> --Paul Hoffman, Director >> --VPN Consortium >> >> From owner-ietf-trust-anchor Thu Aug 9 18:25: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 l7A1PJUE022058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 18:25: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 l7A1PJG9022057; Thu, 9 Aug 2007 18:25: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 smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7A1PHF0022043 for ; Thu, 9 Aug 2007 18:25:18 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 38047 invoked from network); 10 Aug 2007 01:25:12 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.14.190 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 10 Aug 2007 01:25:11 -0000 X-YMail-OSG: 2wqqROYVM1kgxmcg3jOTGd4NXNXfGqJ8m2GBO.xHd5VdfgtykxHjWPHiZa0PPS2psjvP_YmO3A-- Reply-To: From: "Turner, Sean P." To: References: Subject: RE: Issue with the requirements document: PKIX-centric terminology Date: Thu, 9 Aug 2007 21:14:21 -0400 Organization: IECA, Inc. Message-ID: <000101c7daeb$c8746730$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: Acfa1Rw9/RqPb0vuQnGaZB1d7TdvhQAFpsmg 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: I think we should delimit them and not delete them. 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: Thursday, August 09, 2007 6:29 PM To: ietf-trust-anchor@vpnc.org Subject: Issue with the requirements document: PKIX-centric terminology Greetings again. draft-wallace-ta-mgmt-problem-statement-01.txt does a good job of listing the problems we need to deal with, but some parts use PKIX language in places they don't need to. It's fine if these places are marked off with "for example, in PKIX ...", but in many places that is not included. To help make it clearer that the requirements are for management of all public keys, I propose that the following topics be removed or delimited as PKIXy examples: - Name constraints - Key usage - Expiration dates of keys - Possibly others that I have missed --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Aug 10 03:48: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 l7AAmfgB023114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 03:48: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 l7AAmfwD023109; Fri, 10 Aug 2007 03:48: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7AAmdmD023091 for ; Fri, 10 Aug 2007 03:48:40 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 28824 invoked from network); 10 Aug 2007 10:45:47 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Aug 2007 10:45:47 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 10 Aug 2007 10:45:47 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Fri, 10 Aug 2007 06:48:37 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> From: Carl Wallace To: Paul Hoffman , ietf-trust-anchor@vpnc.org Subject: RE: Issue with the requirements document: PKIX-centric terminolog y Date: Fri, 10 Aug 2007 06:48:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DB3C.016A5EBC" 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_01C7DB3C.016A5EBC Content-Type: text/plain I thought this was generally already done but will review the in-progress -02 draft for outliers and try to make the distinction clearer. I don't think we should remove the language since supporting RFC3280 is important. Two examples equate validation of certification paths with RFC3280. Maybe it'd be clearer if those were made more explicit. For example, instead of "When the public key is used to validate certification paths, a distinguished name must also be included." could be "When the public key is used to validate certification paths in accordance with [RFC3280], a distinguished name must also be included." With regard to the specific examples you gave, the first reference (in the introduction) is qualified with "For example, if a trust anchor is used to verify signatures on X.509 certificates...". That seems OK to me. The other reference (last paragraph in section 3) is one of the places that may benefit from not equating path validation with 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, August 09, 2007 6:29 PM > To: ietf-trust-anchor@vpnc.org > Subject: Issue with the requirements document: PKIX-centric > terminology > > > Greetings again. > draft-wallace-ta-mgmt-problem-statement-01.txt does a good > job of listing the problems we need to deal with, but some > parts use PKIX language in places they don't need to. It's > fine if these places are marked off with "for example, in > PKIX ...", but in many places that is not included. > > To help make it clearer that the requirements are for > management of all public keys, I propose that the following > topics be removed or delimited as PKIXy examples: > > - Name constraints > > - Key usage > > - Expiration dates of keys > > - Possibly others that I have missed > > --Paul Hoffman, Director > --VPN Consortium > ------_=_NextPart_001_01C7DB3C.016A5EBC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Issue with the requirements document: PKIX-centric = terminology

I thought this was generally already done but will = review the in-progress -02 draft for outliers and try to make the = distinction clearer.  I don't think we should remove the language = since supporting RFC3280 is important. 

Two examples equate validation of certification paths = with RFC3280.  Maybe it'd be clearer if those were made more = explicit.  For example, instead of "When the public key is = used to validate certification paths, a distinguished name must also be = included." could be "When the public key is used to validate = certification paths in accordance with [RFC3280], a distinguished name = must also be included."

With regard to the specific examples you gave, the = first reference (in the introduction) is qualified with "For = example, if a trust anchor is used to verify signatures on X.509 = certificates...".  That seems OK to me.  The other = reference (last paragraph in section 3) is one of the places that may = benefit from not equating path validation with 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, August 09, 2007 6:29 PM
> To: ietf-trust-anchor@vpnc.org
> Subject: Issue with the requirements document: = PKIX-centric
> terminology
>
>
> Greetings again.
> draft-wallace-ta-mgmt-problem-statement-01.txt = does a good
> job of listing the problems we need to deal = with, but some
> parts use PKIX language in places they don't = need to. It's
> fine if these places are marked off with = "for example, in
> PKIX ...", but in many places that is not = included.
>
> To help make it clearer that the requirements = are for
> management of all public keys, I propose that = the following
> topics be removed or delimited as PKIXy = examples:
>
> - Name constraints
>
> - Key usage
>
> - Expiration dates of keys
>
> - Possibly others that I have missed
>
> --Paul Hoffman, Director
> --VPN Consortium
>

------_=_NextPart_001_01C7DB3C.016A5EBC-- From owner-ietf-trust-anchor Fri Aug 10 06:42: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 l7ADgeZP039604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 06:42: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 l7ADge2S039603; Fri, 10 Aug 2007 06:42: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7ADgcfP039571; Fri, 10 Aug 2007 06:42:39 -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 1IJUlB-00030O-5s; Fri, 10 Aug 2007 09:42:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 10 Aug 2007 09:38:18 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: Issue with the requirements document: PKIX-centric terminology 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:28 PM -0700 8/9/07, Paul Hoffman wrote: >Greetings again. draft-wallace-ta-mgmt-problem-statement-01.txt does >a good job of listing the problems we need to deal with, but some >parts use PKIX language in places they don't need to. It's fine if >these places are marked off with "for example, in PKIX ...", but in >many places that is not included. > >To help make it clearer that the requirements are for management of >all public keys, I propose that the following topics be removed or >delimited as PKIXy examples: > >- Name constraints > >- Key usage > >- Expiration dates of keys > >- Possibly others that I have missed > >--Paul Hoffman, Director >--VPN Consortium Paul, During the IETF meeting I spoke with several folks about the question of the scope of the TAM effort. Derek Atkins said that he didn't see OPGP as benefiting from this work. I think Mike St' Johns didn't view DNSSEC as a beneficiary either. So, maybe we're trying too hard to make this effort generic, when the primary constituency is X.509-centric, at least for now. Steve From owner-ietf-trust-anchor Fri Aug 10 06:42: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 l7ADgeBJ039605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 06:42: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 l7ADge4n039602; Fri, 10 Aug 2007 06:42: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7ADgcg2039573; Fri, 10 Aug 2007 06:42:39 -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 1IJUlC-00030O-4I; Fri, 10 Aug 2007 09:42:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070809152755.S46118@hiroshima.bogus.com> References: <20070809152755.S46118@hiroshima.bogus.com> Date: Fri, 10 Aug 2007 09:42:03 -0400 To: Lucy Lynch From: Stephen Kent Subject: Re: Nailing down the definition of "trust anchor" 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:30 PM -0700 8/9/07, Lucy Lynch wrote: >On Thu, 9 Aug 2007, Paul Hoffman wrote: > >> >>Greetings again. One of the topics earlier on the mailing list was >>defining what a "trust anchor" is. A few of us hammered out the >>following words. If folks like them, great, we can move on to >>harder topics. If not, let's see if we can coalesce on words that >>work. >> >>----- >>A trust anchor is a public key and associated data used by a >>relying party to begin the process of validating a signature on a >>signed object. Associated data is used to define the scope of the >>use of the trust anchor for validating signatures. For example, >>associated data might limit the types of identifiers in >>certificates that a trust anchor is allowed to validate. >>----- > >Paul - > >Really nit-picky question: > >do you really mean "to begin" or would "in" work... as in: > >"A trust anchor is a public key and associated data used by a >relying party in the process of validating a signature on a signed >object." > >- Lucy The definition above is not specific enough to distinguish a TA from any other public key or cert, because a cert path that is several hops long will have multiple keys that are "used by a relying party in the process of validating a signature ..." A TA is special because it is the starting point for validation, or the end point for path construction. Steve From owner-ietf-trust-anchor Fri Aug 10 07:51: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 l7AEpYBi048303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 07:51: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 l7AEpY5O048302; Fri, 10 Aug 2007 07:51: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 [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 l7AEpWY9048293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Aug 2007 07:51:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> Date: Fri, 10 Aug 2007 07:41:29 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: RE: Issue with the requirements document: PKIX-centric terminology 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:48 AM -0400 8/10/07, Carl Wallace wrote: >I thought this was generally already done but will review the >in-progress -02 draft for outliers and try to make the distinction >clearer. Thanks! >I don't think we should remove the language since supporting RFC3280 >is important. Of course, but that could easily be covered by talking about supporting PKIX, not by including all the minutia in the examples. :-) At 9:38 AM -0400 8/10/07, Stephen Kent wrote: >During the IETF meeting I spoke with several folks about the >question of the scope of the TAM effort. Derek Atkins said that he >didn't see OPGP as benefiting from this work. I think Mike St' >Johns didn't view DNSSEC as a beneficiary either. With all due respect to Derek and Mike, they do not represent the entire OpenPGP- and DNSSEC-using community (and they probably didn't pretend to in your conversations with them...). Others from the OpenPGP and DNSSEC communities have already given use cases for TAM. I am most interested in DNSSEC, where there are obvious political problems with a single signed root in many operational environments. >So, maybe we're trying too hard to make this effort generic, when >the primary constituency is X.509-centric, at least for now. While I don't think we're trying too hard (see Carl's message above), I agree that the primary constituency will use PKIX certs below the trust anchors. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Aug 10 07:51: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 l7AEpZWK048311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 07:51: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 l7AEpZRs048310; Fri, 10 Aug 2007 07:51: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 l7AEpWYB048293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Aug 2007 07:51:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <000801c7dad8$6ee87e30$0301a8c0@Wylie> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> Date: Fri, 10 Aug 2007 07:51:14 -0700 To: From: Paul Hoffman Subject: Re: Draft Charter 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:55 PM -0400 8/9/07, Turner, Sean P. wrote: >Strawman charter for trust anchor management (tam) BoF > >Version: 01, July 9th 2007 > >Chair(s) > >TBD > >Security Area Director(s): > >- Tim Polk >- Sam Hartman > >Security Area Advisor: > >TBD > >Mailing Lists: > >General Discussion: ietf-trust-anchor@vpnc.org >To Subscribe: http://www.vpnc.org/ietf-trust-anchor/ >Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/ > >Description of Working Group: > >The need for a standard protocol for trust anchor management has been >recognized for some time. Many groups within the IETF, including PKIX, >Kerberos, TLS and SIDR have a dependency on trust anchors, yet provide no >generic mechanism for the their management. Editorial nit: a comma is needed after "SIDR". > > >A trust anchor is a public key and associated data used by a relying party to >begin the process of validating a signature on a signed object. >Associated data >is used to define the scope of the use of the trust anchor for validating >signatures; for example, associated data might limit the types of identifiers >in certificates that a trust anchor is allowed to validate. > >Despite the wide-spread use of trust anchors, there is no standard means for >managing these security-critical data. This Working Group will develop a >specification to fill this gap. > >The initial problem statement for this work is to be based on: > >- draft-wallace-ta-mgmt-problem-statement > >The scope of the work is to include: > ><> Chicago is now in the past; elide that. >- Supporting a single trust anchor administrator, such as in a typical > enterprise, who may be administering multiple trust anchors in her domain, > where those trust anchors can be either local or "foreign" >- Supporting multiple trust anchor administrators, such as is typical for home > users >- Supporting devices with limited or no user interface that may or >may not have > connected to the Internet Some of the questions at the mic made it clear that people had issues with user interface. It might be better to separate that out into two bullet items: - Supporting systems with limited or no user interface - Supporting devices that may or many not be connected to the Internet at the time of management > >The following are out of scope of this work: > ><> >- TBD I think this is non-controversial for out-of-scope: - Management of non-anchor signature validation objects such as intermediate certificates in a validation path. This might be more controversial, but should be considered as out-of-scope: - Mandating whether the recipient of trust anchors from a trust anchor manager will use those anchors > >The deliverables will be: > >- An informational problem statement/requirements specification > for a trust anchor management protocol >- A standards track trust anchor management protocol > specification > >Goals and Milestones: > >+6 months WG last call on problem statement/requirements >+9 months Adoption of WG draft protocol spec. >+15 months WG last call for protocol spec. > > --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Aug 10 08:03: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 l7AF3km1049790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 08:03: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 l7AF3kEr049789; Fri, 10 Aug 2007 08:03: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 smtp3.su.se (smtp3.su.se [130.237.93.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AF3iYw049765; Fri, 10 Aug 2007 08:03:45 -0700 (MST) (envelope-from leifj@it.su.se) Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id E650E3BE71; Fri, 10 Aug 2007 17:03:43 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01501-01-92; Fri, 10 Aug 2007 17:03:43 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 613B13BE65; Fri, 10 Aug 2007 17:03:42 +0200 (CEST) Message-ID: <46BC7E63.9050307@it.su.se> Date: Fri, 10 Aug 2007 17:04:03 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Paul Hoffman CC: Lucy Lynch , ietf-trust-anchor@vpnc.org Subject: Re: Nailing down the definition of "trust anchor" References: <20070809152755.S46118@hiroshima.bogus.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.283 tagged_above=-99 required=7 tests=[AWL=0.029, BAYES_00=-2.312] X-Spam-Level: Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Hoffman wrote: > > At 3:30 PM -0700 8/9/07, Lucy Lynch wrote: >> Really nit-picky question: > > Really nit-picky is quite appropriate at this juncture! > >> do you really mean "to begin" or would "in" work... as in: >> >> "A trust anchor is a public key and associated data used by a relying >> party in the process of validating a signature on a signed object." > > I really meant "to begin" because these are trust anchors, not keys > that might appear in the middle of a validation chain. For example, > assume you are trying to validate key A, which chains to key B, which > chains to key C, which chains to key D which you trust inherently. > Only key D is a trust anchor. Key B and key C are used "in the process > of validating". > How about "to complete" ? Cheers Leif From owner-ietf-trust-anchor Fri Aug 10 08:40: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 l7AFeW0D055472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 08:40: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 l7AFeWvF055471; Fri, 10 Aug 2007 08:40: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 [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 l7AFeLtJ055446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 08:40:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <46BC7E63.9050307@it.su.se> References: <20070809152755.S46118@hiroshima.bogus.com> <46BC7E63.9050307@it.su.se> Date: Fri, 10 Aug 2007 08:40:03 -0700 To: Leif Johansson From: Paul Hoffman Subject: Re: Nailing down the definition of "trust anchor" Cc: Lucy Lynch , 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 5:04 PM +0200 8/10/07, Leif Johansson wrote: >Paul Hoffman wrote: >> >> At 3:30 PM -0700 8/9/07, Lucy Lynch wrote: >>> Really nit-picky question: >> >> Really nit-picky is quite appropriate at this juncture! >> >>> do you really mean "to begin" or would "in" work... as in: >>> >>> "A trust anchor is a public key and associated data used by a relying >>> party in the process of validating a signature on a signed object." >> >> I really meant "to begin" because these are trust anchors, not keys >> that might appear in the middle of a validation chain. For example, >> assume you are trying to validate key A, which chains to key B, which >> chains to key C, which chains to key D which you trust inherently. >> Only key D is a trust anchor. Key B and key C are used "in the process >> of validating". >> >How about "to complete" ? "To complete" could also mean a middle key. Assume the same example above. If I have key A as a trust anchor, key B and key C are still used "to complete" the validation process. I don't think we want TAM to be distributing "middle" keys (but others might disagree). --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Aug 10 09:10:49 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 l7AGAn6q059555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 09:10:49 -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 l7AGAnTw059554; Fri, 10 Aug 2007 09:10:49 -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 l7AGAmSi059537; Fri, 10 Aug 2007 09:10:49 -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 1IJX4Z-0006J0-4U; Fri, 10 Aug 2007 12:10:47 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> Date: Fri, 10 Aug 2007 11:33:20 -0400 To: Paul Hoffman From: Stephen Kent Subject: RE: Issue with the requirements document: PKIX-centric terminology 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:41 AM -0700 8/10/07, Paul Hoffman wrote: >>... > >With all due respect to Derek and Mike, they do not represent the >entire OpenPGP- and DNSSEC-using community (and they probably didn't >pretend to in your conversations with them...). Others from the >OpenPGP and DNSSEC communities have already given use cases for TAM. >I am most interested in DNSSEC, where there are obvious political >problems with a single signed root in many operational environments. It's certainly fair to say that neither Derek nor MIke represent the entirety of each of these communities, but I do view them as well informed representatives of these communities. If folks from these communities make good, concrete arguments about how this work will relate to their interests, then I agree that we should try to keep the work broad, and not exclude these other areas. However, many (most?) of the messages I've seen on this list discussing broader applicability have been very vague in this respect. Thus I think we need more specific examples from these other areas. Also, these examples should be such that they can all be accommodated by standards that are specific enough to be useful, not just broad enough so that we can say that we encompass everything. Steve From owner-ietf-trust-anchor Fri Aug 10 09:10:50 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 l7AGAoSZ059564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 09:10:50 -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 l7AGAobw059563; Fri, 10 Aug 2007 09:10:50 -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 l7AGAnbi059552 for ; Fri, 10 Aug 2007 09:10:49 -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 1IJX4a-0006J0-6I; Fri, 10 Aug 2007 12:10:49 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <000801c7dad8$6ee87e30$0301a8c0@Wylie> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> Date: Fri, 10 Aug 2007 12:10:11 -0400 To: From: Stephen Kent Subject: Re: Draft Charter Cc: Content-Type: multipart/alternative; boundary="============_-1025360243==_ma============" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --============_-1025360243==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sean, Some more comments on the charter text: A trust anchor is a public key and associated data used by a relying party to begin the process of validating a signature on a signed object. At least in the X.509 context, we often end to use the term "verify" for signatures, and validate for certs, although we are not absolutely consistent in this usage. RFC 2828 discusses this in the section entitled "validate vs. verify" and I suggest we adopt the suggested usage guidelines from there. "begin" may still be problematic, e.g., because one might argue that the beginning of the signature validation process is path discovery. Unfirtunately I don't have a good alternative suggestion right now. Associated data is used to define the scope of the use of the trust anchor for validating signatures. For example, associated data might limit the types of identifiers in certificates that a public key is used to validate, or the types of objects the signatures of which can be verified using a public key. The suggested rewording adheres to the validate vs. verify model in 2828, avoids recursive use of the term TA in its own definition, and extends the example to encompass non-cert signed data. The scope section seems confusing to me: - Supporting a single trust anchor administrator, such as in a typical enterprise, who may be administering multiple trust anchors in her domain, where those trust anchors can be either local or "foreign" We have not defined "local" or "foreign" so it's hard to understand the importance of the distinction being drawn here. - Supporting multiple trust anchor administrators, such as is typical for home users Why do we believe it is common for a home user to need multiple TA administrators? - Supporting devices with limited or no user interface that may or may not have connectivity to the Internet a simple typo fix, but if a deliverable is a TA management protocol, then why do we worry about devices that have no Internet connectivity? Steve --============_-1025360243==_ma============ Content-Type: text/html; charset="us-ascii" Re: Draft Charter
Sean,

Some more comments on the charter text:

A trust anchor is a public key and associated data used by a relying party to
begin the process of validating a signature on a signed object.

At least in the X.509 context, we often end to use the term "verify" for signatures, and validate for certs, although we are not absolutely consistent in this usage.  RFC 2828 discusses this in the section entitled "validate vs. verify" and I suggest we adopt the suggested usage guidelines from there.

"begin" may still be problematic, e.g., because one might argue that the beginning of the signature validation process is path discovery. Unfirtunately I don't have a good alternative suggestion right now.

Associated data is used to define the scope of the use of the trust anchor for validating signatures. For example, associated data might limit the types of identifiers in certificates that a public key is used to validate, or the types of objects the signatures of which can be verified using a public key.

The suggested rewording adheres to the validate vs. verify model in 2828, avoids recursive use of the term TA in its own definition, and extends the example to encompass non-cert signed data.

The scope section seems confusing to me:

- Supporting a single trust anchor administrator, such as in a typical
  enterprise, who may be administering multiple trust anchors in her domain,
  where those trust anchors can be either local or "foreign"

We have not defined "local" or "foreign" so it's hard to understand the importance of the distinction being drawn here.

- Supporting multiple trust anchor administrators, such as is typical for home
  users

Why do we believe it is common for a home user to need multiple TA administrators?

- Supporting devices with limited or no user interface that may or may not have connectivity to the Internet

a simple typo fix, but if a deliverable is a TA management protocol, then why do we worry about devices that have no Internet connectivity?

Steve
--============_-1025360243==_ma============-- From owner-ietf-trust-anchor Fri Aug 10 12:26: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 l7AJQRdK079319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 12:26: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 l7AJQROS079318; Fri, 10 Aug 2007 12:26: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 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 l7AJQQXC079312 for ; Fri, 10 Aug 2007 12:26:26 -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: multipart/alternative; boundary="----_=_NextPart_001_01C7DB84.7952FEAA" Subject: RE: Draft Charter Date: Fri, 10 Aug 2007 12:26:19 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Charter Thread-Index: Acfba1A5D3tSQSxlT7WmMydLd+AyigAGJwYQ References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> From: "Santosh Chokhani" 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_01C7DB84.7952FEAA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, =20 Would the following do? =20 A relying party uses the trust anchor and associated information to verify signature on the first certificate in a certification path. If there are no certificates (i.e., the trusted anchor has directly signed an object), the relying party uses the trust anchor and associated information to verify signature on the signed object. =20 ________________________________ From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen Kent Sent: Friday, August 10, 2007 12:10 PM To: turners@ieca.com Cc: ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter =20 Sean, =20 Some more comments on the charter text: =20 A trust anchor is a public key and associated data used by a relying party to begin the process of validating a signature on a signed object. =20 At least in the X.509 context, we often end to use the term "verify" for signatures, and validate for certs, although we are not absolutely consistent in this usage. RFC 2828 discusses this in the section entitled "validate vs. verify" and I suggest we adopt the suggested usage guidelines from there. =20 "begin" may still be problematic, e.g., because one might argue that the beginning of the signature validation process is path discovery. Unfirtunately I don't have a good alternative suggestion right now. =20 Associated data is used to define the scope of the use of the trust anchor for validating signatures. For example, associated data might limit the types of identifiers in certificates that a public key is used to validate, or the types of objects the signatures of which can be verified using a public key. =20 The suggested rewording adheres to the validate vs. verify model in 2828, avoids recursive use of the term TA in its own definition, and extends the example to encompass non-cert signed data. =20 The scope section seems confusing to me: =20 - Supporting a single trust anchor administrator, such as in a typical enterprise, who may be administering multiple trust anchors in her domain, where those trust anchors can be either local or "foreign" =20 We have not defined "local" or "foreign" so it's hard to understand the importance of the distinction being drawn here. - Supporting multiple trust anchor administrators, such as is typical for home users =20 Why do we believe it is common for a home user to need multiple TA administrators? =20 - Supporting devices with limited or no user interface that may or may not have connectivity to the Internet =20 a simple typo fix, but if a deliverable is a TA management protocol, then why do we worry about devices that have no Internet connectivity? =20 Steve ------_=_NextPart_001_01C7DB84.7952FEAA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: Draft Charter

Steve,

 

Would the following = do?

 

A relying party uses the trust = anchor and associated information to verify signature on the first certificate in a = certification path.  If there are no certificates (i.e., the trusted anchor has = directly signed an object), the relying party uses the trust anchor and = associated information to verify signature on the signed = object.

 

From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen Kent
Sent: Friday, August 10, = 2007 12:10 PM
To: turners@ieca.com
Cc: = ietf-trust-anchor@vpnc.org
Subject: Re: Draft = Charter

 

Sean,

 

Some more comments on the charter = text:

 

A trust anchor is a public key = and associated data used by a relying party to

begin the process of validating a signature on a signed object.

 

At least in the X.509 context, we = often end to use the term "verify" for signatures, and validate for = certs, although we are not absolutely consistent in this usage.  RFC 2828 discusses this in the section entitled "validate vs. verify" = and I suggest we adopt the suggested usage guidelines from = there.

 

"begin" may still be problematic, e.g., because one might argue that the beginning of the = signature validation process is path discovery. Unfirtunately I don't have a good alternative suggestion right now.

 

Associated data is used to define = the scope of the use of the trust anchor for validating signatures. For = example, associated data might limit the types of identifiers in certificates = that a public key is used to validate, or the types of objects the signatures = of which can be verified using a public key.

 

The suggested rewording adheres = to the validate vs. verify model in 2828, avoids recursive use of the term TA = in its own definition, and extends the example to encompass non-cert signed = data.

 

The scope section seems confusing = to me:

 

- Supporting a single trust = anchor administrator, such as in a typical
  enterprise, who may be administering multiple trust anchors in = her domain,

  where those trust anchors = can be either local or "foreign"

 

We have not defined = "local" or "foreign" so it's hard to understand the importance of the distinction being drawn here.


- Supporting multiple trust anchor administrators, such as is typical = for home

  = users

 

Why do we believe it is common = for a home user to need multiple TA administrators?

 

- Supporting devices with limited = or no user interface that may or may not have connectivity to the = Internet

 

a simple typo fix, but if a deliverable is a TA = management protocol, then why do we worry = about devices that have no Internet connectivity?

 

Steve

------_=_NextPart_001_01C7DB84.7952FEAA-- From owner-ietf-trust-anchor Fri Aug 10 12:36: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 l7AJaft3080035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 12:36: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 l7AJafw5080034; Fri, 10 Aug 2007 12:36: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 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 l7AJacRm080026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 10 Aug 2007 12:36:40 -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 9D2C7426E; Fri, 10 Aug 2007 20:36:37 +0100 (IST) Received: from [127.0.0.1] (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 l7AJaZWM018420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Aug 2007 20:36:35 +0100 Message-ID: <46BCBE41.6000707@cs.tcd.ie> Date: Fri, 10 Aug 2007 20:36:33 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Santosh Chokhani CC: ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> In-Reply-To: <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> 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: 12344157 - 6a0dcbed0793 (trained as not-spam) 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: That definition is x.509 specific ("certificate"). While that may be what emerges as the consensus wrt scope for this proposed work, we shouldn't decide that this way IMO. S. Santosh Chokhani wrote: > Steve, > > > > Would the following do? > > > > A relying party uses the trust anchor and associated information to > verify signature on the first certificate in a certification path. If > there are no certificates (i.e., the trusted anchor has directly signed > an object), the relying party uses the trust anchor and associated > information to verify signature on the signed object. > > > > ------------------------------------------------------------------------ > > *From:* owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] *On Behalf Of *Stephen Kent > *Sent:* Friday, August 10, 2007 12:10 PM > *To:* turners@ieca.com > *Cc:* ietf-trust-anchor@vpnc.org > *Subject:* Re: Draft Charter > > > > Sean, > > > > Some more comments on the charter text: > > > > A trust anchor is a public key and associated data used by a relying > party to > > begin the process of validating a signature on a signed object. > > > > At least in the X.509 context, we often end to use the term "verify" for > signatures, and validate for certs, although we are not absolutely > consistent in this usage. RFC 2828 discusses this in the section > entitled "validate vs. verify" and I suggest we adopt the suggested > usage guidelines from there. > > > > "begin" may still be problematic, e.g., because one might argue that the > beginning of the signature validation process is path discovery. > Unfirtunately I don't have a good alternative suggestion right now. > > > > Associated data is used to define the scope of the use of the trust > anchor for validating signatures. For example, associated data might > limit the types of identifiers in certificates that a_ public key is > used to validate, or the types of objects the signatures of which can be > verified using a public key_. > > > > The suggested rewording adheres to the validate vs. verify model in > 2828, avoids recursive use of the term TA in its own definition, and > extends the example to encompass non-cert signed data. > > > > The scope section seems confusing to me: > > > > - Supporting a single trust anchor administrator, such as in a typical > enterprise, who may be administering multiple trust anchors in her domain, > > where those trust anchors can be either local or "foreign" > > > > We have not defined "local" or "foreign" so it's hard to understand the > importance of the distinction being drawn here. > > > - Supporting multiple trust anchor administrators, such as is typical > for home > > users > > > > Why do we believe it is common for a home user to need multiple TA > administrators? > > > > - Supporting devices with limited or no user interface that may or may > not have_ connectivity_ to the Internet > > > > a simple typo fix, but if a deliverable is a TA management* protocol*, > then why do we worry about devices that have no Internet connectivity? > > > > Steve > From owner-ietf-trust-anchor Fri Aug 10 12:39: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 l7AJdXSm080211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 12:39: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 l7AJdXgP080210; Fri, 10 Aug 2007 12:39: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 l7AJdWlr080204 for ; Fri, 10 Aug 2007 12:39:33 -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: Draft Charter Date: Fri, 10 Aug 2007 12:39:34 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87908C9C352@EXVS01.ex.dslextreme.net> In-Reply-To: <46BCBE41.6000707@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Charter Thread-Index: AcfbhenglIAxUbcdQqueaYca4JqwVwAAAqqw References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> <46BCBE41.6000707@cs.tcd.ie> From: "Santosh Chokhani" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7AJdXlr080205 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: What is X.509 specific? The term certificate or certification path or both. Will PGP and others not have a chain of keys/certificates? Are not these concepts generic and is this not time to separate concepts from X.509 format? -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Friday, August 10, 2007 3:37 PM To: Santosh Chokhani Cc: ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter That definition is x.509 specific ("certificate"). While that may be what emerges as the consensus wrt scope for this proposed work, we shouldn't decide that this way IMO. S. Santosh Chokhani wrote: > Steve, > > > > Would the following do? > > > > A relying party uses the trust anchor and associated information to > verify signature on the first certificate in a certification path. If > there are no certificates (i.e., the trusted anchor has directly signed > an object), the relying party uses the trust anchor and associated > information to verify signature on the signed object. > > > > ------------------------------------------------------------------------ > > *From:* owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] *On Behalf Of *Stephen Kent > *Sent:* Friday, August 10, 2007 12:10 PM > *To:* turners@ieca.com > *Cc:* ietf-trust-anchor@vpnc.org > *Subject:* Re: Draft Charter > > > > Sean, > > > > Some more comments on the charter text: > > > > A trust anchor is a public key and associated data used by a relying > party to > > begin the process of validating a signature on a signed object. > > > > At least in the X.509 context, we often end to use the term "verify" for > signatures, and validate for certs, although we are not absolutely > consistent in this usage. RFC 2828 discusses this in the section > entitled "validate vs. verify" and I suggest we adopt the suggested > usage guidelines from there. > > > > "begin" may still be problematic, e.g., because one might argue that the > beginning of the signature validation process is path discovery. > Unfirtunately I don't have a good alternative suggestion right now. > > > > Associated data is used to define the scope of the use of the trust > anchor for validating signatures. For example, associated data might > limit the types of identifiers in certificates that a_ public key is > used to validate, or the types of objects the signatures of which can be > verified using a public key_. > > > > The suggested rewording adheres to the validate vs. verify model in > 2828, avoids recursive use of the term TA in its own definition, and > extends the example to encompass non-cert signed data. > > > > The scope section seems confusing to me: > > > > - Supporting a single trust anchor administrator, such as in a typical > enterprise, who may be administering multiple trust anchors in her domain, > > where those trust anchors can be either local or "foreign" > > > > We have not defined "local" or "foreign" so it's hard to understand the > importance of the distinction being drawn here. > > > - Supporting multiple trust anchor administrators, such as is typical > for home > > users > > > > Why do we believe it is common for a home user to need multiple TA > administrators? > > > > - Supporting devices with limited or no user interface that may or may > not have_ connectivity_ to the Internet > > > > a simple typo fix, but if a deliverable is a TA management* protocol*, > then why do we worry about devices that have no Internet connectivity? > > > > Steve > From owner-ietf-trust-anchor Fri Aug 10 12:46: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 l7AJkdE2080856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 12:46: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 l7AJkd6q080855; Fri, 10 Aug 2007 12:46: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 relay.imagine.ie (relay.imagine.ie [87.232.1.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AJkb5Y080844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 10 Aug 2007 12:46:38 -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 9B52C428F; Fri, 10 Aug 2007 20:46:36 +0100 (IST) Received: from [127.0.0.1] (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 l7AJkXFx019884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Aug 2007 20:46:34 +0100 Message-ID: <46BCC098.4030808@cs.tcd.ie> Date: Fri, 10 Aug 2007 20:46:32 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Santosh Chokhani CC: ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> <46BCBE41.6000707@cs.tcd.ie> <82D5657AE1F54347A734BDD33637C87908C9C352@EXVS01.ex.dslextreme.net> In-Reply-To: <82D5657AE1F54347A734BDD33637C87908C9C352@EXVS01.ex.dslextreme.net> 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: 12344799 - bdebbc44c9eb (trained as not-spam) 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: Santosh Chokhani wrote: > What is X.509 specific? > > The term certificate or certification path or both. Yes. For me anyway, particularly the latter term. > Will PGP and others > not have a chain of keys/certificates? Who knows? (Can't recall off the top of my head what the PGP things are called - not keyrings was it?) > Are not these concepts generic and is this not time to separate concepts > from X.509 format? That would be a worthwhile activity. But not one that it'd be wise to build in as a precondition on this proposed activity. So I'd rather see a definition use more neutral terms. S. > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Friday, August 10, 2007 3:37 PM > To: Santosh Chokhani > Cc: ietf-trust-anchor@vpnc.org > Subject: Re: Draft Charter > > > That definition is x.509 specific ("certificate"). While that > may be what emerges as the consensus wrt scope for this proposed > work, we shouldn't decide that this way IMO. > > S. > > Santosh Chokhani wrote: >> Steve, >> >> >> >> Would the following do? >> >> >> >> A relying party uses the trust anchor and associated information to >> verify signature on the first certificate in a certification path. If > >> there are no certificates (i.e., the trusted anchor has directly > signed >> an object), the relying party uses the trust anchor and associated >> information to verify signature on the signed object. >> >> >> >> > ------------------------------------------------------------------------ >> *From:* owner-ietf-trust-anchor@mail.vpnc.org >> [mailto:owner-ietf-trust-anchor@mail.vpnc.org] *On Behalf Of *Stephen > Kent >> *Sent:* Friday, August 10, 2007 12:10 PM >> *To:* turners@ieca.com >> *Cc:* ietf-trust-anchor@vpnc.org >> *Subject:* Re: Draft Charter >> >> >> >> Sean, >> >> >> >> Some more comments on the charter text: >> >> >> >> A trust anchor is a public key and associated data used by a relying >> party to >> >> begin the process of validating a signature on a signed object. >> >> >> >> At least in the X.509 context, we often end to use the term "verify" > for >> signatures, and validate for certs, although we are not absolutely >> consistent in this usage. RFC 2828 discusses this in the section >> entitled "validate vs. verify" and I suggest we adopt the suggested >> usage guidelines from there. >> >> >> >> "begin" may still be problematic, e.g., because one might argue that > the >> beginning of the signature validation process is path discovery. >> Unfirtunately I don't have a good alternative suggestion right now. >> >> >> >> Associated data is used to define the scope of the use of the trust >> anchor for validating signatures. For example, associated data might >> limit the types of identifiers in certificates that a_ public key is >> used to validate, or the types of objects the signatures of which can > be >> verified using a public key_. >> >> >> >> The suggested rewording adheres to the validate vs. verify model in >> 2828, avoids recursive use of the term TA in its own definition, and >> extends the example to encompass non-cert signed data. >> >> >> >> The scope section seems confusing to me: >> >> >> >> - Supporting a single trust anchor administrator, such as in a typical >> enterprise, who may be administering multiple trust anchors in her > domain, >> where those trust anchors can be either local or "foreign" >> >> >> >> We have not defined "local" or "foreign" so it's hard to understand > the >> importance of the distinction being drawn here. >> >> >> - Supporting multiple trust anchor administrators, such as is typical >> for home >> >> users >> >> >> >> Why do we believe it is common for a home user to need multiple TA >> administrators? >> >> >> >> - Supporting devices with limited or no user interface that may or may > >> not have_ connectivity_ to the Internet >> >> >> >> a simple typo fix, but if a deliverable is a TA management* protocol*, > >> then why do we worry about devices that have no Internet connectivity? >> >> >> >> Steve >> > > From owner-ietf-trust-anchor Fri Aug 10 12:47: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 l7AJlTj6080932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 12:47: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 l7AJlTdB080931; Fri, 10 Aug 2007 12:47: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 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 l7AJlRk5080923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 10 Aug 2007 12:47:29 -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 6EB4B428F; Fri, 10 Aug 2007 20:47:27 +0100 (IST) Received: from [127.0.0.1] (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 l7AJlPKb019966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Aug 2007 20:47:26 +0100 Message-ID: <46BCC0CC.2040805@cs.tcd.ie> Date: Fri, 10 Aug 2007 20:47:24 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen Kent CC: ietf-trust-anchor@vpnc.org Subject: Re: Issue with the requirements document: PKIX-centric terminology References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.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: 12344855 - 05ba73086827 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, You seem to prefer that this work be scoped so as to be limited to x.509 TAs only. I'm just wondering if you see any specific benefit to that, or if its just that you've not seen specific enough reasons to want to support more than x.509? (From my p-o-v, I guess I'd argue that any TA related work starting in 2008 shouldn't only support x.509.) S. Stephen Kent wrote: > > At 7:41 AM -0700 8/10/07, Paul Hoffman wrote: >>> ... >> >> With all due respect to Derek and Mike, they do not represent the >> entire OpenPGP- and DNSSEC-using community (and they probably didn't >> pretend to in your conversations with them...). Others from the >> OpenPGP and DNSSEC communities have already given use cases for TAM. I >> am most interested in DNSSEC, where there are obvious political >> problems with a single signed root in many operational environments. > > It's certainly fair to say that neither Derek nor MIke represent the > entirety of each of these communities, but I do view them as well > informed representatives of these communities. > > If folks from these communities make good, concrete arguments about how > this work will relate to their interests, then I agree that we should > try to keep the work broad, and not exclude these other areas. However, > many (most?) of the messages I've seen on this list discussing broader > applicability have been very vague in this respect. Thus I think we need > more specific examples from these other areas. Also, these examples > should be such that they can all be accommodated by standards that are > specific enough to be useful, not just broad enough so that we can say > that we encompass everything. > > Steve > > From owner-ietf-trust-anchor Fri Aug 10 13:07: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 l7AK7fDw083435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 13:07: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 l7AK7fEu083434; Fri, 10 Aug 2007 13:07: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 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 l7AK7e28083420; Fri, 10 Aug 2007 13:07:40 -0700 (MST) (envelope-from thardjono@wavesys.com) Content-class: urn:content-classes:message Subject: RE: Issue with the requirements document: PKIX-centric terminology Date: Fri, 10 Aug 2007 13:08:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue with the requirements document: PKIX-centric terminology Thread-Index: AcfbVkFiWkn58WPcSo+4hEodi7ZQMQAMoh1Q From: "Thomas Hardjono" To: "Stephen Kent" , "Paul Hoffman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7AK7f28083422 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, August 10, 2007 6:38 AM > To: Paul Hoffman > Cc: ietf-trust-anchor@vpnc.org > Subject: Re: Issue with the requirements document: > PKIX-centric terminology > > > At 3:28 PM -0700 8/9/07, Paul Hoffman wrote: > >Greetings again. > draft-wallace-ta-mgmt-problem-statement-01.txt does a > >good job of listing the problems we need to deal with, but > some parts > >use PKIX language in places they don't need to. It's fine if these > >places are marked off with "for example, in PKIX ...", but in many > >places that is not included. > > > >To help make it clearer that the requirements are for > management of all > >public keys, I propose that the following topics be removed or > >delimited as PKIXy examples: > > > >- Name constraints > > > >- Key usage > > > >- Expiration dates of keys > > > >- Possibly others that I have missed > > > >--Paul Hoffman, Director > >--VPN Consortium > > Paul, > > During the IETF meeting I spoke with several folks about the > question of the scope of the TAM effort. Derek Atkins said > that he didn't see OPGP as benefiting from this work. I > think Mike St' Johns didn't view DNSSEC as a beneficiary > either. So, maybe we're trying too hard to make this effort > generic, when the primary constituency is X.509-centric, at > least for now. > > Steve > > Steve, I think the effort and language is pitched just right. Clearly not all applications and not all Internet-infrastructure elements/ protocols use X.509. But that's ok. If the DNSSEC and OpenPGP chairs feel they are not benefiting from the TAM work then that's also ok. Bear in mind that there are perhaps more beneficiaries outside the IETF than inside. /thomas/ From owner-ietf-trust-anchor Fri Aug 10 13:07: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 l7AK7qcl083475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 13:07: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 l7AK7qPU083473; Fri, 10 Aug 2007 13:07: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AK7ofQ083455 for ; Fri, 10 Aug 2007 13:07:51 -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 1IJaly-0003K6-4I; Fri, 10 Aug 2007 16:07:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <46BCC0CC.2040805@cs.tcd.ie> References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> Date: Fri, 10 Aug 2007 16:07:46 -0400 To: Stephen Farrell From: Stephen Kent Subject: Re: Issue with the requirements document: PKIX-centric terminology 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:47 PM +0100 8/10/07, Stephen Farrell wrote: >Hi Steve, > >You seem to prefer that this work be scoped so as to be limited >to x.509 TAs only. > >I'm just wondering if you see any specific benefit to that, or >if its just that you've not seen specific enough reasons to want >to support more than x.509? > >(From my p-o-v, I guess I'd argue that any TA related work starting >in 2008 shouldn't only support x.509.) > >S. 1. I noted in my comments on the problem statement that it was essentially X.509-centric, with just lip service to other contexts. This says that we will have to work hard(er) to create a problem statement that is truly inclusive, and this is not just fluff. 2. I have not seen specific, well-reasoned comments on the problem statement from the other communities we might try to encompass. We need that input, and a corresponding expression of a willingness to work on the problem, to justify the effort to get #1 right :-). 3. So far the greatest interest seems to have been shown by folks who are focused on the X.509 arena, which suggests that this ought to be the first priority. It's always tempting to say that we will scope an effort to not exclude other contexts where we can envision a solution might be applicable, but that tends to make it even harder to make progress in the area that we agree ought to be the highest priority. I think our difficult in writing a good definition of a TA is indicative of the sort of additional work we incur when we try to broaden the scope. None of this means we can't decide to address more than the X.509 context, but it may suggest that we ought not adopt a broader scope by default. Steve From owner-ietf-trust-anchor Fri Aug 10 13:07: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 l7AK7qMs083474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 13:07: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 l7AK7qc4083472; Fri, 10 Aug 2007 13:07: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AK7oMg083452 for ; Fri, 10 Aug 2007 13:07:51 -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 1IJalx-0003K6-4Y; Fri, 10 Aug 2007 16:07:49 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> Date: Fri, 10 Aug 2007 15:57:41 -0400 To: "Santosh Chokhani" From: Stephen Kent Subject: RE: Draft Charter Cc: Content-Type: multipart/alternative; boundary="============_-1025346022==_ma============" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --============_-1025346022==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 12:26 PM -0700 8/10/07, Santosh Chokhani wrote: >Steve, > >Would the following do? slightly re-worded, to reflect the notion that a TA consists of both a public key and associated info, and that one verifies a signature with a TA, vs. signing an object with a TA: "A relying party uses a trust anchor to verify the signature on the first certificate in a certification path, or is used to directly verify the signature on a signed object when no certification path is involved." --============_-1025346022==_ma============ Content-Type: text/html; charset="us-ascii" RE: Draft Charter
At 12:26 PM -0700 8/10/07, Santosh Chokhani wrote:
Steve,
 
Would the following do?

slightly re-worded, to reflect the notion that a TA consists of both a public key and associated info, and that one verifies a signature with a TA, vs. signing an object with a TA:

 
"A relying party uses a trust anchor to verify the signature on the first certificate in a certification path, or is used to directly verify the signature on a signed object when no certification path is involved."
 
--============_-1025346022==_ma============-- From owner-ietf-trust-anchor Fri Aug 10 13:16: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 l7AKG4so086293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 13:16: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 l7AKG4Oc086292; Fri, 10 Aug 2007 13:16: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 [165.227.249.213] (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 l7AKG262086271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 13:16:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> Date: Fri, 10 Aug 2007 13:15:45 -0700 To: "Santosh Chokhani" , From: Paul Hoffman Subject: RE: Draft Charter 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:26 PM -0700 8/10/07, Santosh Chokhani wrote: >Would the following do? > >A relying party uses the trust anchor and associated information to >verify signature on the first certificate in a certification path. > If there are no certificates (i.e., the trusted anchor has directly >signed an object), the relying party uses the trust anchor and >associated information to verify signature on the signed object. Not for me. We do not need to be using "certificates" here. A specific use case that does not involve certificates is a trust anchor that directly signs objects that the device uses such as trust anchor management messages. Even if we are in a PKIX-centric world, not everything is a certificate. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Aug 10 13:20: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 l7AKKBlQ087712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 13:20: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 l7AKKBSv087711; Fri, 10 Aug 2007 13:20: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AKKAtq087688; Fri, 10 Aug 2007 13:20:10 -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 1IJaxu-0003Zx-3K; Fri, 10 Aug 2007 16:20:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 10 Aug 2007 16:20:01 -0400 To: "Thomas Hardjono" From: Stephen Kent Subject: RE: Issue with the requirements document: PKIX-centric terminology Cc: "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 1:08 PM -0700 8/10/07, Thomas Hardjono wrote: >... >Steve, > >I think the effort and language is pitched just right. Clearly not all >applications and not all Internet-infrastructure elements/ protocols use >X.509. But that's ok. > >If the DNSSEC and OpenPGP chairs feel they are not benefiting from the >TAM work then that's also ok. Bear in mind that there are perhaps more >beneficiaries outside the IETF than inside. > >/thomas/ I think we should make decisions about what work to do in the IETF based on who participates in the IETF work, not based on who we believe may benefit. I don't think we need DNESEC or OpenPGP WG chairs to bless this work, although their input is certainly welcome; we do need individuals who will work on documents (and protocol implementations) and contribute on the list. Steve From owner-ietf-trust-anchor Fri Aug 10 13:27: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 l7AKR82a089971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 13:27: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 l7AKR84R089970; Fri, 10 Aug 2007 13:27: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 [165.227.249.213] (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 l7AKLYoQ088211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 13:21:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> Date: Fri, 10 Aug 2007 13:21:12 -0700 To: Stephen Kent , From: Paul Hoffman Subject: Re: Draft Charter Cc: Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Re: Draft Charter
At 12:10 PM -0400 8/10/07, Stephen Kent wrote:
At least in the X.509 context, we often end to use the term "verify" for signatures, and validate for certs, although we are not absolutely consistent in this usage.  RFC 2828 discusses this in the section entitled "validate vs. verify" and I suggest we adopt the suggested usage guidelines from there.

Even without the RFC 2828 definitions, I think it is good to talk about "verifying" signatures instead of "validating" signatures.

"begin" may still be problematic, e.g., because one might argue that the beginning of the signature validation process is path discovery. Unfirtunately I don't have a good alternative suggestion right now.

Let's leave it as "begin" until we have a better word. I think everyone understands it.

Associated data is used to define the scope of the use of the trust anchor for validating signatures. For example, associated data might limit the types of identifiers in certificates that a public key is used to validate, or the types of objects the signatures of which can be verified using a public key.

This sounds good too.

The scope section seems confusing to me:

- Supporting a single trust anchor administrator, such as in a typical
  enterprise, who may be administering multiple trust anchors in her domain,
  where those trust anchors can be either local or "foreign"

We have not defined "local" or "foreign" so it's hard to understand the importance of the distinction being drawn here.

The bullet works just as well without the last clause. That is, there is no assumption in the words before it that the trust anchors are all run by the TAA.

- Supporting multiple trust anchor administrators, such as is typical for home
  users

Why do we believe it is common for a home user to need multiple TA administrators?

I would be happy if we swapped "individual" for "home". If needed, we can add text such as "For example, they may want their employers and their banks to act as trust anchor administrators."

- Supporting devices with limited or no user interface that may or may not have connectivity to the Internet

a simple typo fix, but if a deliverable is a TA management protocol, then why do we worry about devices that have no Internet connectivity?

Protocols do not require Internet connectivity. End-to-end email is a good example of that.

--Paul Hoffman, Director
--VPN Consortium
From owner-ietf-trust-anchor Fri Aug 10 13:41: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 l7AKfsbj092561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 13:41: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 l7AKfsR5092560; Fri, 10 Aug 2007 13:41: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AKfrdP092547; Fri, 10 Aug 2007 13:41:53 -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 1IJbIu-0003yG-6E; Fri, 10 Aug 2007 16:41:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> Date: Fri, 10 Aug 2007 16:41:50 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: Draft Charter Cc: , Content-Type: multipart/alternative; boundary="============_-1025343979==_ma============" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --============_-1025343979==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 1:21 PM -0700 8/10/07, Paul Hoffman wrote: >... the TAA. > >>- Supporting multiple trust anchor administrators, such as is >>typical for home >> users >> >>Why do we believe it is common for a home user to need multiple TA >>administrators? > >I would be happy if we swapped "individual" for "home". If needed, >we can add text such as "For example, they may want their employers >and their banks to act as trust anchor administrators." Ah, I see your point. If I can appropriately constrain the impact of what a TAA can do, I can safely let others be TAAs for my machine. That seems right for my home machine, but for a company-owned machine the roles probably are reversed, i.e., the employer is in charge and will allow the employee limited control over TAs. > >>- Supporting devices with limited or no user interface that may or >>may not have connectivity to the Internet >> >>a simple typo fix, but if a deliverable is a TA management >>protocol, then why do we worry about devices that have no Internet >>connectivity? > >Protocols do not require Internet connectivity. End-to-end email is >a good example of that. Good point. We may want to define protocols that can use staged delivery, even if there is no network involved. If that's the intent, the bullet could be a bit clearer, e.g., if we want to define protocols that work even if we deliver messages via a USB token from a source to a destination. However, I note that a protocol of that sort is likely to be more complex than one that assumes use of lower layer network protocols, even staged delivery ones. Steve --============_-1025343979==_ma============ Content-Type: text/html; charset="us-ascii" Re: Draft Charter
At 1:21 PM -0700 8/10/07, Paul Hoffman wrote:
... the TAA.

- Supporting multiple trust anchor administrators, such as is typical for home
  users

Why do we believe it is common for a home user to need multiple TA administrators?

I would be happy if we swapped "individual" for "home". If needed, we can add text such as "For example, they may want their employers and their banks to act as trust anchor administrators."

Ah, I see your point. If I can appropriately constrain the impact of what a TAA can do, I can safely let others be TAAs for my machine. That seems right for my home machine, but for a company-owned machine the roles probably are reversed, i.e., the employer is in charge and will allow the employee limited control over TAs.


- Supporting devices with limited or no user interface that may or may not have connectivity to the Internet

a simple typo fix, but if a deliverable is a TA management protocol, then why do we worry about devices that have no Internet connectivity?

Protocols do not require Internet connectivity. End-to-end email is a good example of that.

Good point.  We may want to define protocols that can use staged delivery, even if there is no network involved.  If that's the intent, the bullet could be a bit clearer, e.g., if we want to define protocols that work even if we deliver messages via a USB token from a source to a destination. However, I note that a protocol of that sort is likely to be more complex than one that assumes use of lower layer network protocols, even staged delivery ones.

Steve
--============_-1025343979==_ma============-- From owner-ietf-trust-anchor Fri Aug 10 14:13: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 l7ALDRYY095813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 14:13: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 l7ALDRph095812; Fri, 10 Aug 2007 14:13: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 l7ALDQoU095806 for ; Fri, 10 Aug 2007 14:13:26 -0700 (MST) (envelope-from thardjono@wavesys.com) Content-class: urn:content-classes:message Subject: More specific examples (use-cases of TAM) -- RE: Issue with the requirements document: PKIX-centric terminology MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Aug 2007 14:14:04 -0700 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More specific examples (use-cases of TAM) -- RE: Issue with the requirements document: PKIX-centric terminology Thread-Index: Acfba1wGU6HWnshCTPqsT4UiHoXDOQAH5xAw From: "Thomas Hardjono" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7ALDQoU095807 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, August 10, 2007 8:33 AM > To: Paul Hoffman > Cc: ietf-trust-anchor@vpnc.org > Subject: RE: Issue with the requirements document: > PKIX-centric terminology > ...cut > However, many (most?) of the messages I've seen on this list > discussing broader applicability have been very vague in this > respect. Thus I think we need more specific examples from > these other areas. Also, these examples should be such that > they can all be accommodated by standards that are specific > enough to be useful, not just broad enough so that we can say > that we encompass everything. > > Steve Since I was one of the persons at the BOF who mentioned wider applicability of TAs and TAM (a) beyond browsers and TLS, and (b) beyond the IETF, I'll provide some use-cases. (PS. Carl/Raksha/Sean/Stephen, its not perfect but please feel free to use the text in the draft or charter). TA and TAM Use-Cases -------------------- UC#1: Code-signing Code-signing is an important requirement for the security of computers today. Essentially, in code-signing only digitally-signed code or executables are allowed to be installed and executed on a computer systems. This requirement introduces the need to have present on the computer systems a set of Trust Anchors representing entities trusted by the computer owner. The owner of the machine needs the ability to set acceptable TAs according to the policies in place using a standardized protocol. UC#2: Field upgrade of sensitive firmware There are over 50 million Trusted Platform Modules (TPM) hardware on PC client machines today (with a projected number of 100M by 2010). Once in the field, a TPM's firmware will require updates in a secure manner. RFC4108 (Using CMS to protect firmware) has already begun addressing firmware packages. However, what is still required is a protocol to update the original TA (from the TPM manufacturer) that reside inside the TPM hardware. Additionally, each TPM hardware may incorporate a number of TPM-specific (X.509) certificates issued by various entities in the PC supply-chain. These certificates are in fact Trust Anchors, and in turn require management using a standardized protocol. UC#3: Secure boot Within a Pre-OS environment, it is desirable from a trust/security perspective to configure computers to load the various boot codes in a pre-defined sequence (eg. configured by the IT admin). One interpretation of a secure boot is one in which the sequence of loaded codes follow exactly what has been pre-defined (by the IT admin). Additionally, it is desirable that the loaded codes can be verifiable as coming from a trusted source (eg. BIOS vendor). Verification of Pre-OS components requires Trust Anchors issued by the vendors to be readily available in the Pre-OS environment. Among others, this allows updates to the boot codes be introduced into the Pre-OS environment. However, this introduces the need to manage and update TAs within the Pre-OS environment. UC#4: Multi stakeholder mobile phones Today within the mobile telecommunications industry there are a number of key stakeholders that participate in the mobile phone ecosystem and management lifecycle. These include the device manufacturer , the carrier (MNO), various third-party content providers and lastly the device owner. Each of these stakeholders through contractual agreements have access to different physical components of a mobile phone in the field. A given stakeholder will allow access to be made (to the components under its control) only by verifiable authenticated entities (usually themselves or subordinates). One way to express this control is through the presence of a X.509 certificate (namely a Trust Anchor) issued by the respective stakeholder. Software and firmware updates over-the-air and other senstive management commands will only be accepted by the mobile phone when it can be verified against one or more TAs found on the phone. Thus, TAs and TA management represents a crucial part of mobile phone security and the mobile phone ecosystem as a whole. UC#5: Secure virtualization With the advent of client-side virtualization, it is desirable that a given physical host machine be able to run more than one Guest Operating Systems (GOS) simultaneously. A typical architecture of such a host machine includes a hypervisor layer which may include a virtualization management component that supervises the loading and off-loading of the Guest Operating Systems. An organization (eg. Enterprise) may wish to allow only certain authorized GOSs to be loaded on its host machines. This may be governed by business reasons or security reasons (or both). With the absence of a full operating system, the hypervisor may use Trust Anchors (TA) to identify and authenticate GOSs that are permitted to load and execute. From owner-ietf-trust-anchor Fri Aug 10 14:11: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 l7ALBRZu095602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 14:11: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 l7ALBR3i095601; Fri, 10 Aug 2007 14:11: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 relay.imagine.ie (relay.imagine.ie [87.232.1.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7ALBPFE095593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 10 Aug 2007 14:11:26 -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 DF5AC42E1; Fri, 10 Aug 2007 22:11:24 +0100 (IST) Received: from [127.0.0.1] (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 l7ALBMW1031415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Aug 2007 22:11:23 +0100 Message-ID: <46BCD478.5050503@cs.tcd.ie> Date: Fri, 10 Aug 2007 22:11:20 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen Kent CC: ietf-trust-anchor@vpnc.org Subject: Re: Issue with the requirements document: PKIX-centric terminology References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@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: 12350331 - 668fee6a48e2 (trained as not-spam) 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: > At 8:47 PM +0100 8/10/07, Stephen Farrell wrote: >> Hi Steve, >> >> You seem to prefer that this work be scoped so as to be limited >> to x.509 TAs only. >> >> I'm just wondering if you see any specific benefit to that, or >> if its just that you've not seen specific enough reasons to want >> to support more than x.509? >> >> (From my p-o-v, I guess I'd argue that any TA related work starting >> in 2008 shouldn't only support x.509.) >> >> S. > > 1. I noted in my comments on the problem statement that it was > essentially X.509-centric, with just lip service to other contexts. This > says that we will have to work hard(er) to create a problem statement > that is truly inclusive, and this is not just fluff. > > 2. I have not seen specific, well-reasoned comments on the problem > statement from the other communities we might try to encompass. We need > that input, and a corresponding expression of a willingness to work on > the problem, to justify the effort to get #1 right :-). > > 3. So far the greatest interest seems to have been shown by folks who > are focused on the X.509 arena, which suggests that this ought to be the > first priority. It's always tempting to say that we will scope an effort > to not exclude other contexts where we can envision a solution might be > applicable, but that tends to make it even harder to make progress in > the area that we agree ought to be the highest priority. The above seems quite reasonable to me. > I think our > difficult in writing a good definition of a TA is indicative of the sort > of additional work we incur when we try to broaden the scope. Well, there's also the fact that we're quite a picky crowd - personally I reckon that most of the people on this list, and those who spoke in Chicago, all know well what we mean by a TA. Getting all those same people to agree on one set of words will always be tedious. > None of this means we can't decide to address more than the X.509 > context, but it may suggest that we ought not adopt a broader scope by > default. Possibly. x.509 is clearly the major use case, but I'd at least like any protocol to have the same level of flexibility as, say, TLS has to support other infrastructures if they emerge. That doesn't require a lot of overhead IMO. But, your main point is correct - if there are people with real non-x.509 use cases they really should speak up now before a WG is chartered (or re-chartered). S. From owner-ietf-trust-anchor Fri Aug 10 16:52:49 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 l7ANqnK0009053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 16:52:49 -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 l7ANqn5q009052; Fri, 10 Aug 2007 16:52:49 -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 l7ANqcas009033 for ; Fri, 10 Aug 2007 16:52:38 -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 391BBF0298; Fri, 10 Aug 2007 16:52:38 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Fri, 10 Aug 2007 16:52:38 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Fri, 10 Aug 2007 16:52:38 -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 1983435; Fri, 10 Aug 2007 16:52:36 -0700 Received: from [10.214.201.166] ([10.214.201.166]) by keys.pgpeng.com (PGP Universal service); Fri, 10 Aug 2007 16:52:36 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Fri, 10 Aug 2007 16:52:36 -0700 In-Reply-To: <82D5657AE1F54347A734BDD33637C87908C9C352@EXVS01.ex.dslextreme.net> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> <46BCBE41.6000707@cs.tcd.ie> <82D5657AE1F54347A734BDD33637C87908C9C352@EXVS01.ex.dslextreme.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <7D4F5A79-DBD1-4D9F-805E-2C024C68A514@pgpeng.com> Cc: From: Jon Callas Subject: Re: Draft Charter Date: Fri, 10 Aug 2007 16:52:36 -0700 To: Santosh Chokhani 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 Aug 10, 2007, at 12:39 PM, Santosh Chokhani wrote: > > What is X.509 specific? > > The term certificate or certification path or both. Will PGP and > others > not have a chain of keys/certificates? I presume you mean OpenPGP. PGP is software, and it is software that implements X.509 as well as OpenPGP. > > Are not these concepts generic and is this not time to separate > concepts > from X.509 format? Yes. 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 Aug 10 17:26: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 l7B0QVV6010673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 17:26: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 l7B0QVk9010672; Fri, 10 Aug 2007 17:26: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 [165.227.249.213] (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 l7B0QEQ0010655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 17:26:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> Date: Fri, 10 Aug 2007 17:25:48 -0700 To: Stephen Kent From: Paul Hoffman Subject: Re: Draft Charter 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 4:41 PM -0400 8/10/07, Stephen Kent wrote: >At 1:21 PM -0700 8/10/07, Paul Hoffman wrote: >>... the TAA. >> >>>- Supporting multiple trust anchor administrators, such as is >>>typical for home >>> users >>> >>>Why do we believe it is common for a home user to need multiple TA >>>administrators? >> >>I would be happy if we swapped "individual" for "home". If needed, >>we can add text such as "For example, they may want their employers >>and their banks to act as trust anchor administrators." > >Ah, I see your point. If I can appropriately constrain the impact of >what a TAA can do, I can safely let others be TAAs for my machine. >That seems right for my home machine, but for a company-owned >machine the roles probably are reversed, i.e., the employer is in >charge and will allow the employee limited control over TAs. Exactly right. From the TAA's point of view, there are two choices: "I control everything in his store" and "I share control of his store with unknown others". We don't have to choose the second way, but I think the overhead of doing so is worth the benefit of many more potential use cases. >>>- Supporting devices with limited or no user interface that may or >>>may not have connectivity to the Internet >>> >>>a simple typo fix, but if a deliverable is a TA management >>>protocol, then why do we worry about devices that have no Internet >>>connectivity? >> >>Protocols do not require Internet connectivity. End-to-end email is >>a good example of that. > >Good point. We may want to define protocols that can use staged >delivery, even if there is no network involved. If that's the >intent, the bullet could be a bit clearer, e.g., if we want to >define protocols that work even if we deliver messages via a USB >token from a source to a destination. However, I note that a >protocol of that sort is likely to be more complex than one that >assumes use of lower layer network protocols, even staged delivery >ones. Fully disagree. We can decouple the format from how one hands the object to the next party. This is akin to defining CMS separate from S/MIME. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Aug 10 17:42: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 l7B0gJfH011443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 17:42: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 l7B0gJRL011442; Fri, 10 Aug 2007 17:42: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 [165.227.249.213] (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 l7B0g6j3011431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 17:42:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <46BCD478.5050503@cs.tcd.ie> References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> <46BCD478.5050503@cs.tcd.ie> Date: Fri, 10 Aug 2007 17:41:48 -0700 To: Stephen Farrell , Stephen Kent From: Paul Hoffman Subject: Re: Issue with the requirements document: PKIX-centric terminology 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:11 PM +0100 8/10/07, Stephen Farrell wrote: > >But, your main point is correct - if there are people with real >non-x.509 use cases they really should speak up now before a WG is >chartered (or re-chartered). In addition to Thomas' long list, I would add "items directly signed by the TA with no intervening certificates". This would likely include the TA instructions themselves, but it also includes various authorization instructions. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Aug 10 17:46: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 l7B0kgPV011698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 17:46: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 l7B0kgHi011697; Fri, 10 Aug 2007 17:46: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 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 l7B0kfVe011691 for ; Fri, 10 Aug 2007 17:46:41 -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: multipart/alternative; boundary="----_=_NextPart_001_01C7DBB1.38479D6C" Subject: RE: Draft Charter Date: Fri, 10 Aug 2007 17:46:44 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87908C9C5FC@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Charter Thread-Index: AcfbikY5o6WD6Zc5T5G/BbaIAISlcwAJsl/A References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> From: "Santosh Chokhani" To: "Stephen Kent" Cc: 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_01C7DBB1.38479D6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, =20 Sounds good. =20 ________________________________ From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Friday, August 10, 2007 3:58 PM To: Santosh Chokhani Cc: ietf-trust-anchor@vpnc.org Subject: RE: Draft Charter =20 At 12:26 PM -0700 8/10/07, Santosh Chokhani wrote: Steve, =20 Would the following do? =20 slightly re-worded, to reflect the notion that a TA consists of both a public key and associated info, and that one verifies a signature with a TA, vs. signing an object with a TA: =20 =20 "A relying party uses a trust anchor to verify the signature on the first certificate in a certification path, or is used to directly verify the signature on a signed object when no certification path is involved." =20 ------_=_NextPart_001_01C7DBB1.38479D6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Draft Charter

Steve,

 

Sounds = good.

 

From: = Stephen Kent [mailto:kent@bbn.com]
Sent: Friday, August 10, = 2007 3:58 PM
To: Santosh Chokhani
Cc: = ietf-trust-anchor@vpnc.org
Subject: RE: Draft = Charter

 

At 12:26 PM -0700 8/10/07, Santosh = Chokhani wrote:

Steve,

 

Would the following = do?

 

slightly re-worded, to reflect the notion that a TA consists of = both a public key and associated info, and that one verifies a signature with a = TA, vs. signing an object with a TA:

 

 

"A relying party uses a trust anchor to verify the = signature on the first certificate in a certification path, or is used to directly = verify the signature on a signed object when no certification path is = involved."

 

------_=_NextPart_001_01C7DBB1.38479D6C-- From owner-ietf-trust-anchor Fri Aug 10 17:55: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 l7B0t75e012119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 17:55: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 l7B0t7ZY012118; Fri, 10 Aug 2007 17:55: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 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 l7B0t6K8012112 for ; Fri, 10 Aug 2007 17:55:06 -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: Draft Charter Date: Fri, 10 Aug 2007 17:55:07 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87908C9C603@EXVS01.ex.dslextreme.net> In-Reply-To: <46BCC098.4030808@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Charter Thread-Index: Acfbh1G4+ej5GGoRSpi2cJimqo2SPQACdLYQ References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> <46BCBE41.6000707@cs.tcd.ie> <82D5657AE1F54347A734BDD33637C87908C9C352@EXVS01.ex.dslextreme.net> <46BCC098.4030808@cs.tcd.ie> From: "Santosh Chokhani" To: "Stephen Farrell" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7B0t6K8012113 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steve, It may be better if we agreed on how generic this definition needs to be. What communities are having trouble understanding these terms and what their recommendations are. I have been monitoring this list and I feel that most people on the list know what trust anchor is. Thus, rather than perfecting the definition, we may be better served discussing the scope of TAMP, benefits of having TAMP, and by generating implementers interest based on these benefits. -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Friday, August 10, 2007 3:47 PM To: Santosh Chokhani Cc: ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter Santosh Chokhani wrote: > What is X.509 specific? > > The term certificate or certification path or both. Yes. For me anyway, particularly the latter term. > Will PGP and others > not have a chain of keys/certificates? Who knows? (Can't recall off the top of my head what the PGP things are called - not keyrings was it?) > Are not these concepts generic and is this not time to separate concepts > from X.509 format? That would be a worthwhile activity. But not one that it'd be wise to build in as a precondition on this proposed activity. So I'd rather see a definition use more neutral terms. S. > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Friday, August 10, 2007 3:37 PM > To: Santosh Chokhani > Cc: ietf-trust-anchor@vpnc.org > Subject: Re: Draft Charter > > > That definition is x.509 specific ("certificate"). While that > may be what emerges as the consensus wrt scope for this proposed > work, we shouldn't decide that this way IMO. > > S. > > Santosh Chokhani wrote: >> Steve, >> >> >> >> Would the following do? >> >> >> >> A relying party uses the trust anchor and associated information to >> verify signature on the first certificate in a certification path. If > >> there are no certificates (i.e., the trusted anchor has directly > signed >> an object), the relying party uses the trust anchor and associated >> information to verify signature on the signed object. >> >> >> >> > ------------------------------------------------------------------------ >> *From:* owner-ietf-trust-anchor@mail.vpnc.org >> [mailto:owner-ietf-trust-anchor@mail.vpnc.org] *On Behalf Of *Stephen > Kent >> *Sent:* Friday, August 10, 2007 12:10 PM >> *To:* turners@ieca.com >> *Cc:* ietf-trust-anchor@vpnc.org >> *Subject:* Re: Draft Charter >> >> >> >> Sean, >> >> >> >> Some more comments on the charter text: >> >> >> >> A trust anchor is a public key and associated data used by a relying >> party to >> >> begin the process of validating a signature on a signed object. >> >> >> >> At least in the X.509 context, we often end to use the term "verify" > for >> signatures, and validate for certs, although we are not absolutely >> consistent in this usage. RFC 2828 discusses this in the section >> entitled "validate vs. verify" and I suggest we adopt the suggested >> usage guidelines from there. >> >> >> >> "begin" may still be problematic, e.g., because one might argue that > the >> beginning of the signature validation process is path discovery. >> Unfirtunately I don't have a good alternative suggestion right now. >> >> >> >> Associated data is used to define the scope of the use of the trust >> anchor for validating signatures. For example, associated data might >> limit the types of identifiers in certificates that a_ public key is >> used to validate, or the types of objects the signatures of which can > be >> verified using a public key_. >> >> >> >> The suggested rewording adheres to the validate vs. verify model in >> 2828, avoids recursive use of the term TA in its own definition, and >> extends the example to encompass non-cert signed data. >> >> >> >> The scope section seems confusing to me: >> >> >> >> - Supporting a single trust anchor administrator, such as in a typical >> enterprise, who may be administering multiple trust anchors in her > domain, >> where those trust anchors can be either local or "foreign" >> >> >> >> We have not defined "local" or "foreign" so it's hard to understand > the >> importance of the distinction being drawn here. >> >> >> - Supporting multiple trust anchor administrators, such as is typical >> for home >> >> users >> >> >> >> Why do we believe it is common for a home user to need multiple TA >> administrators? >> >> >> >> - Supporting devices with limited or no user interface that may or may > >> not have_ connectivity_ to the Internet >> >> >> >> a simple typo fix, but if a deliverable is a TA management* protocol*, > >> then why do we worry about devices that have no Internet connectivity? >> >> >> >> Steve >> > > From owner-ietf-trust-anchor Sat Aug 11 23:44: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 l7C6ipgT049881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2007 23:44: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 l7C6ipq0049880; Sat, 11 Aug 2007 23:44: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 michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7C6imBj049873 for ; Sat, 11 Aug 2007 23:44:49 -0700 (MST) (envelope-from ynir@checkpoint.com) Received: from [172.31.21.12] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l7C6ilRL021025 for ; Sun, 12 Aug 2007 09:44:47 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <000801c7dad8$6ee87e30$0301a8c0@Wylie> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: Draft Charter Date: Sun, 12 Aug 2007 09:18:28 +0300 To: ietf-trust-anchor@vpnc.org X-Mailer: Apple Mail (2.752.3) Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Chicago there was some controversy about whether multiple administrators should be in scope. This charter draft says that they're in. I'm not saying they shouldn't be, but it does add complexity. If they're in, we need to answer big questions: - If TAA1 adds a TA, can TAA2 delete it? - If no, should there be "hard-delete" where it does delete it? - If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1 deletes it, is it there or not? - Should TAA2 be able to query TAs added by TAA1? - Should we have a delete-all command (I think that's necessary for the store-and-forward scenario) - How does delete-all interact with multiple TAAs? Do we need a hard- delete-all? I would answer these questions no, yes, yes, yes, yes and yes, but these are far from trivial. I think these and other issues suggest we should split the TAMP protocol deliverables into two documents: one to deal with the protocol, formats, encoding (XML/ASN.1) and the online/offline case. The other document should deal with trust anchor store operations: how the database is structured and what it does with the various commands. Yoav > Strawman charter for trust anchor management (tam) BoF > > Version: 01, July 9th 2007 > > Chair(s) > > TBD > > Security Area Director(s): > > - Tim Polk > - Sam Hartman > > Security Area Advisor: > > TBD > > Mailing Lists: > > General Discussion: ietf-trust-anchor@vpnc.org > To Subscribe: http://www.vpnc.org/ietf-trust-anchor/ > Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/ > > Description of Working Group: > > The need for a standard protocol for trust anchor management has been > recognized for some time. Many groups within the IETF, including > PKIX, > Kerberos, TLS and SIDR have a dependency on trust anchors, yet > provide no > generic mechanism for the their management. > > A trust anchor is a public key and associated data used by a > relying party to > begin the process of validating a signature on a signed object. > Associated data > is used to define the scope of the use of the trust anchor for > validating > signatures; for example, associated data might limit the types of > identifiers > in certificates that a trust anchor is allowed to validate. > > Despite the wide-spread use of trust anchors, there is no standard > means for > managing these security-critical data. This Working Group will > develop a > specification to fill this gap. > > The initial problem statement for this work is to be based on: > > - draft-wallace-ta-mgmt-problem-statement > > The scope of the work is to include: > > <> > - Supporting a single trust anchor administrator, such as in a typical > enterprise, who may be administering multiple trust anchors in > her domain, > where those trust anchors can be either local or "foreign" > - Supporting multiple trust anchor administrators, such as is > typical for home > users > - Supporting devices with limited or no user interface that may or > may not have > connected to the Internet > > The following are out of scope of this work: > > <> > - TBD > > The deliverables will be: > > - An informational problem statement/requirements specification > for a trust anchor management protocol > - A standards track trust anchor management protocol > specification > > Goals and Milestones: > > +6 months WG last call on problem statement/ > requirements > +9 months Adoption of WG draft protocol spec. > +15 months WG last call for protocol spec. > > From owner-ietf-trust-anchor Sun Aug 12 09:56: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 l7CGurHM099439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2007 09:56: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 l7CGurBK099438; Sun, 12 Aug 2007 09:56: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 [165.227.249.213] (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 l7CGtVRH099370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2007 09:55:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> Date: Sun, 12 Aug 2007 09:55:11 -0700 To: Yoav Nir , ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Re: Draft Charter 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:18 AM +0300 8/12/07, Yoav Nir wrote: >In Chicago there was some controversy about whether multiple >administrators should be in scope. This charter draft says that >they're in. I'm not saying they shouldn't be, but it does add >complexity. Indeed. But the complexity might be able to be contained with very different assumptions than the ones you made. >If they're in, we need to answer big questions: >- If TAA1 adds a TA, can TAA2 delete it? >- If no, should there be "hard-delete" where it does delete it? >- If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1 >deletes it, is it there or not? >- Should TAA2 be able to query TAs added by TAA1? >- Should we have a delete-all command (I think that's necessary for >the store-and-forward scenario) >- How does delete-all interact with multiple TAAs? Do we need a >hard-delete-all? > >I would answer these questions no, yes, yes, yes, yes and yes, but >these are far from trivial. This takes the view that the TAAs "add" and "delete" TAs. A very different view, one that makes things a lot simpler, is that TAAs propose additions and deletions, and the software for the recipient of those proposals chooses whether or not to act on those proposals. As I said at the mic in Chicago, I'm not suggesting that end users need to think about each TAA action; they can just make policy decisions and let the software act accordingly. For example, assume that the user has the setting "TAA1 is more important than TAA2". Then, in your examples: >- If TAA1 adds a TA, can TAA2 delete it? No. >- If no, should there be "hard-delete" where it does delete it? No. I would be against having various strengths of "add" and "delete"; no one will be able to figure them out. >- If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1 >deletes it, is it there or not? It is not. >- Should TAA2 be able to query TAs added by TAA1? Yes. A simpler and more general mechanism is that any TAA can query the TA store, and that store says which TAA added each TA. >- Should we have a delete-all command (I think that's necessary for >the store-and-forward scenario) No. That would leave the user with no one to trust, including the party that issued the delete-all. The TAM software should never leave the user with no TAs except under dire circumstances. >- How does delete-all interact with multiple TAAs? Do we need a >hard-delete-all? Moot; see above. I believe that most users who have multiple TAAs could set an order for precedence to them. I also think writing software to act on the precedence is quite straightforward: the two rules are "only allow delete proposals from TAAs at the same level or higher as the TAA who added this TA" and "if a TA has been deleted, only allow it to be re-added by a TAA at the same level or higher than the one who deleted it". Does this simplification seem like a good one? --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Sun Aug 12 10:38: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 l7CHchlm002096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2007 10:38: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 l7CHchvn002095; Sun, 12 Aug 2007 10:38: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7CHcgmi002089 for ; Sun, 12 Aug 2007 10:38:43 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 18906 invoked from network); 12 Aug 2007 17:35:48 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;12 Aug 2007 17:35:48 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 12 Aug 2007 17:35:48 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Sun, 12 Aug 2007 13:38:41 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31D3BE@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: Draft Charter Date: Sun, 12 Aug 2007 13:38:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DD07.9E1B60C8" 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_01C7DD07.9E1B60C8 Content-Type: text/plain > I believe that most users who have multiple TAAs could set an > order for precedence to them. I also think writing software > to act on the precedence is quite straightforward: the two > rules are "only allow delete proposals from TAAs at the same > level or higher as the TAA who added this TA" and "if a TA > has been deleted, only allow it to be re-added by a TAA at > the same level or higher than the one who deleted it". > > Does this simplification seem like a good one? I'd prefer to see support for rules based on TAA capabilities vs. admin precedence. For example, in PKIX, things like name constraints or usage constraints could be used. Rules based on values like these may be more applicable to enterprise scenarios with a precedence system being easier for individual users. It'd be easy to define precedence using an extension-like mechanism similar to name constraints and usage constraints. ------_=_NextPart_001_01C7DD07.9E1B60C8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Charter

> I believe that most users who have multiple TAAs = could set an
> order for precedence to them. I also think = writing software
> to act on the precedence is quite = straightforward: the two
> rules are "only allow delete proposals = from TAAs at the same
> level or higher as the TAA who added this = TA" and "if a TA
> has been deleted, only allow it to be re-added = by a TAA at
> the same level or higher than the one who = deleted it".
>
> Does this simplification seem like a good = one?

I'd prefer to see support for rules based on TAA = capabilities vs. admin precedence.  For example, in PKIX, things = like name constraints or usage constraints could be used.  Rules = based on values like these may be more applicable to enterprise = scenarios with a precedence system being easier for individual = users.  It'd be easy to define precedence using an extension-like = mechanism similar to name constraints and usage constraints.

------_=_NextPart_001_01C7DD07.9E1B60C8-- From owner-ietf-trust-anchor Sun Aug 12 14: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 l7CLZebS021903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2007 14: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 l7CLZeNo021902; Sun, 12 Aug 2007 14: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 smtp3.su.se (smtp3.su.se [130.237.93.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7CLZcLh021892 for ; Sun, 12 Aug 2007 14:35:39 -0700 (MST) (envelope-from leifj@it.su.se) Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id ACA1E3BF07; Sun, 12 Aug 2007 23:35:37 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21631-01-8; Sun, 12 Aug 2007 23:35:37 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id B3CFD3BEAD; Sun, 12 Aug 2007 23:35:36 +0200 (CEST) Message-ID: <46BF7D3F.7090703@it.su.se> Date: Sun, 12 Aug 2007 23:35:59 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Yoav Nir CC: ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> In-Reply-To: <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.284 tagged_above=-99 required=7 tests=[AWL=0.028, BAYES_00=-2.312] X-Spam-Level: Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yoav Nir wrote: > > In Chicago there was some controversy about whether multiple > administrators should be in scope. This charter draft says that > they're in. I'm not saying they shouldn't be, but it does add complexity. > Multiple admins would seem to imply the need for a standardized way to express access policy. Whenever the 'P-word' turns up I get nervous since there aren't a lot of _good_ examples of standardized policy- language. From the questions you list it sounds to me like the policy/aci language for trust-stores could be about as complex as that of any directory. Say you want to control access to the attributes associated with a trust anchor for instance - that would immediately suck in the whole mess of directory aci:s by reference. All of this can be done of course but it probably helps to jump into that hole with eyes open ;-) Cheers Leif From owner-ietf-trust-anchor Sun Aug 12 15:24:50 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 l7CMOnWN025050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2007 15:24:49 -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 l7CMOnpO025049; Sun, 12 Aug 2007 15:24:49 -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 [165.227.249.213] (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 l7CMOjjh025041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2007 15:24:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31D3BE@scygmxs1.cygnacom.com> References: <886F5D4C78AFB14D87261206BFB9612E1D31D3BE@scygmxs1.cygnacom.com> Date: Sun, 12 Aug 2007 15:24:26 -0700 To: Carl Wallace , ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: RE: Draft Charter 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:38 PM -0400 8/12/07, Carl Wallace wrote: >I'd prefer to see support for rules based on TAA capabilities vs. >admin precedence. For example, in PKIX, things like name >constraints or usage constraints could be used. Rules based on >values like these may be more applicable to enterprise scenarios >with a precedence system being easier for individual users. It'd be >easy to define precedence using an extension-like mechanism similar >to name constraints and usage constraints. It sounds like your TAA capabilities would map fairly directly to a precedence. That seems fine too. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Mon Aug 13 06:51:58 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 l7DDpwGj002176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 06:51: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 l7DDpwwf002175; Mon, 13 Aug 2007 06:51: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DDpvsS002145 for ; Mon, 13 Aug 2007 06:51:57 -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 1IKaKq-0003fY-4F; Mon, 13 Aug 2007 09:51:56 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> Date: Mon, 13 Aug 2007 09:40:38 -0400 To: Yoav Nir From: Stephen Kent Subject: Re: Draft Charter 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:18 AM +0300 8/12/07, Yoav Nir wrote: >In Chicago there was some controversy about whether multiple >administrators should be in scope. This charter draft says that >they're in. I'm not saying they shouldn't be, but it does add >complexity. > >If they're in, we need to answer big questions: >- If TAA1 adds a TA, can TAA2 delete it? if we allow creating a hierarchy )or even a lattice) of TAAs, then once cannot answer this question without knowing the relationships of TAA1 and TAA2. >- If no, should there be "hard-delete" where it does delete it? define "hard delete" >- If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1 >deletes it, is it there or not? this already presumes that the addition you mention is idempotent, somethign we have yet to deciude. >- Should TAA2 be able to query TAs added by TAA1? >- Should we have a delete-all command (I think that's necessary for >the store-and-forward scenario) >- How does delete-all interact with multiple TAAs? Do we need a >hard-delete-all? > >I would answer these questions no, yes, yes, yes, yes and yes, but >these are far from trivial. > >I think these and other issues suggest we should split the TAMP >protocol deliverables into two documents: one to deal with the >protocol, formats, encoding (XML/ASN.1) and the online/offline case. >The other document should deal with trust anchor store operations: >how the database is structured and what it does with the various >commands. > >Yoav how about one to agree on the requirements first :-), before we define the syntax and semantics? Steve From owner-ietf-trust-anchor Mon Aug 13 06:51: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 l7DDpwlC002186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 06:51:59 -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 l7DDpwcq002185; Mon, 13 Aug 2007 06:51: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DDpvlR002147; Mon, 13 Aug 2007 06:51:57 -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 1IKaKq-0003fY-60; Mon, 13 Aug 2007 09:51:57 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> Date: Mon, 13 Aug 2007 09:46:47 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: Draft Charter Cc: Yoav Nir , 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: >>... > >This takes the view that the TAAs "add" and "delete" TAs. A very >different view, one that makes things a lot simpler, is that TAAs >propose additions and deletions, and the software for the recipient >of those proposals chooses whether or not to act on those proposals. >As I said at the mic in Chicago, I'm not suggesting that end users >need to think about each TAA action; they can just make policy >decisions and let the software act accordingly. You raise an important issue of perspective. If a TAA is an "authority" then it can try to do anything (e.g., issue any command in a protocol), but the effects of what it does are constrained by the authority granted to it. That authority may be defined by the user, or by some other TAA. However, we do need to be very careful about the complexity of polices that can be expressed here. We have lots of experience in the security environment that suggest users, even sys admins, are not very good at managing policies once the level of complexity grows beyond a certain point. Our requirements development process needs to be mindful of this issue, and not assume that users will suddenly become much better at this crucial task. Steve From owner-ietf-trust-anchor Mon Aug 13 06:51:58 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 l7DDpwO2002181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 06:51: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 l7DDpwQY002177; Mon, 13 Aug 2007 06:51: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DDpuwI002144; Mon, 13 Aug 2007 06:51:57 -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 1IKaKp-0003fY-5T; Mon, 13 Aug 2007 09:51:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> Date: Mon, 13 Aug 2007 09:34:26 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: Draft Charter 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: >>>... >> >>Good point. We may want to define protocols that can use staged >>delivery, even if there is no network involved. If that's the >>intent, the bullet could be a bit clearer, e.g., if we want to >>define protocols that work even if we deliver messages via a USB >>token from a source to a destination. However, I note that a >>protocol of that sort is likely to be more complex than one that >>assumes use of lower layer network protocols, even staged delivery >>ones. > >Fully disagree. We can decouple the format from how one hands the >object to the next party. This is akin to defining CMS separate from >S/MIME. It's not the format; it's the semantics of the underlying delivery system. I designed and implemented this stuff a few years ago, and my experience suggests that there is a significant difference. For example, if I can assume network connectivity, even staged delivery, I may be able to make assumptions about responses from a device re delivery of data, that are less likely to be viable if a person is moving data on a USB token. Steve From owner-ietf-trust-anchor Mon Aug 13 06:50: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 l7DDovgP002032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 06:50: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 l7DDovk8002031; Mon, 13 Aug 2007 06:50: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 michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DDotj9002011; Mon, 13 Aug 2007 06:50:56 -0700 (MST) (envelope-from ynir@checkpoint.com) Received: from [172.31.21.12] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l7DDorRL000085; Mon, 13 Aug 2007 16:50:53 +0300 (IDT) In-Reply-To: References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <40F31377-6CFE-450C-9500-ED50163AD01A@checkpoint.com> Cc: ietf-trust-anchor@vpnc.org Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: Draft Charter Date: Mon, 13 Aug 2007 16:50:46 +0300 To: Paul Hoffman X-Mailer: Apple Mail (2.752.3) Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Inline... On Aug 12, 2007, at 7:55 PM, Paul Hoffman wrote: > At 9:18 AM +0300 8/12/07, Yoav Nir wrote: >> In Chicago there was some controversy about whether multiple >> administrators should be in scope. This charter draft says that >> they're in. I'm not saying they shouldn't be, but it does add >> complexity. > > Indeed. But the complexity might be able to be contained with very > different assumptions than the ones you made. > > This takes the view that the TAAs "add" and "delete" TAs. A very > different view, one that makes things a lot simpler, is that TAAs > propose additions and deletions, and the software for the recipient > of those proposals chooses whether or not to act on those > proposals. As I said at the mic in Chicago, I'm not suggesting that > end users need to think about each TAA action; they can just make > policy decisions and let the software act accordingly. > This just gave me a mental image of the next generation Internet Explorer scary pop-up with the DN of the TAA and the DN of the new TAA, a warning about possible exploits and data corruption, with the final question "Do you accept this trust anchor?" > For example, assume that the user has the setting "TAA1 is more > important than TAA2". Then, in your examples: > >> - If TAA1 adds a TA, can TAA2 delete it? > > No. What if TAA2 knows for a fact that the private key of the TA has been compromised? The example I have in my head is TAA1 is Microsoft (or Mozilla - the browser vendor), while TAA2 is your company. I can't say that one is more important than the other. > >> - If no, should there be "hard-delete" where it does delete it? > > No. I would be against having various strengths of "add" and > "delete"; no one will be able to figure them out. Again, I think there should be a distinction between "I don't use this CA any more" and "this CA is no longer trustworthy" > >> - If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1 >> deletes it, is it there or not? > > It is not. IMO this should depend on why TAA1 deleted it. There's a difference between "we've switched to Verisign" and "NetLock has been compromised" > >> - Should TAA2 be able to query TAs added by TAA1? > > Yes. A simpler and more general mechanism is that any TAA can query > the TA store, and that store says which TAA added each TA. > >> - Should we have a delete-all command (I think that's necessary >> for the store-and-forward scenario) > > No. That would leave the user with no one to trust, including the > party that issued the delete-all. The TAM software should never > leave the user with no TAs except under dire circumstances. I have two issues with this: 1. I don't think the TAM anchor should be in the same store that it is managing. I don't even thing TAM should be administered with TAM. 2. If Microsoft (as TAA1) wants to give the users a whole new set of anchors, it makes sense to send in a single message, a "delete-all" command and several "add" commands. this works even better if we make a separation between anchors added by different TAAs. > >> - How does delete-all interact with multiple TAAs? Do we need a >> hard-delete-all? > > Moot; see above. > > I believe that most users who have multiple TAAs could set an order > for precedence to them. I also think writing software to act on the > precedence is quite straightforward: the two rules are "only allow > delete proposals from TAAs at the same level or higher as the TAA > who added this TA" and "if a TA has been deleted, only allow it to > be re-added by a TAA at the same level or higher than the one who > deleted it". > > Does this simplification seem like a good one? I would rather have a system where each TAA manages the TAs that it has added, with provisions for multiple additions and deletions. I don't think precedence is a good simplification. Yoav From owner-ietf-trust-anchor Mon Aug 13 06:55: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 l7DDtV9h002606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 06:55: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 l7DDtV9K002605; Mon, 13 Aug 2007 06:55: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 michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DDtUZe002579 for ; Mon, 13 Aug 2007 06:55:30 -0700 (MST) (envelope-from ynir@checkpoint.com) Received: from [172.31.21.12] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l7DDtLRL001519; Mon, 13 Aug 2007 16:55:21 +0300 (IDT) In-Reply-To: References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> 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: Yoav Nir Subject: Re: Draft Charter Date: Mon, 13 Aug 2007 16:55:13 +0300 To: Stephen Kent X-Mailer: Apple Mail (2.752.3) Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Aug 13, 2007, at 4:40 PM, Stephen Kent wrote: > At 9:18 AM +0300 8/12/07, Yoav Nir wrote: >> In Chicago there was some controversy about whether multiple >> administrators should be in scope. This charter draft says that >> they're in. I'm not saying they shouldn't be, but it does add >> complexity. >> >> If they're in, we need to answer big questions: >> - If TAA1 adds a TA, can TAA2 delete it? > > if we allow creating a hierarchy )or even a lattice) of TAAs, then > once cannot answer this question without knowing the relationships > of TAA1 and TAA2. So our protocol document (or operations document) will need to define such relationships > >> - If no, should there be "hard-delete" where it does delete it? > > define "hard delete" Delete even though this TA was added by another TAA. This does assume that TAAs only manage the TAs they added. > >> - If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1 >> deletes it, is it there or not? > > this already presumes that the addition you mention is idempotent, > somethign we have yet to deciude. Of course. I'm just enumerating several possible complexities off the top of my head. > >> - Should TAA2 be able to query TAs added by TAA1? >> - Should we have a delete-all command (I think that's necessary >> for the store-and-forward scenario) >> - How does delete-all interact with multiple TAAs? Do we need a >> hard-delete-all? >> >> I would answer these questions no, yes, yes, yes, yes and yes, but >> these are far from trivial. >> >> I think these and other issues suggest we should split the TAMP >> protocol deliverables into two documents: one to deal with the >> protocol, formats, encoding (XML/ASN.1) and the online/offline case. >> The other document should deal with trust anchor store operations: >> how the database is structured and what it does with the various >> commands. >> >> Yoav > > how about one to agree on the requirements first :-), before we > define the syntax and semantics? > > Steve > From owner-ietf-trust-anchor Mon Aug 13 07:53: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 l7DErHk1011870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 07:53: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 l7DErH79011869; Mon, 13 Aug 2007 07:53: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DErFtY011848 for ; Mon, 13 Aug 2007 07:53:16 -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 1IKbIA-0002Hk-4a; Mon, 13 Aug 2007 10:53:14 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> Date: Mon, 13 Aug 2007 10:10:48 -0400 To: Yoav Nir From: Stephen Kent Subject: Re: Draft Charter 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 4:55 PM +0300 8/13/07, Yoav Nir wrote: >On Aug 13, 2007, at 4:40 PM, Stephen Kent wrote: > >>At 9:18 AM +0300 8/12/07, Yoav Nir wrote: >>>In Chicago there was some controversy about whether multiple >>>administrators should be in scope. This charter draft says that >>>they're in. I'm not saying they shouldn't be, but it does add >>>complexity. >>> >>>If they're in, we need to answer big questions: >>>- If TAA1 adds a TA, can TAA2 delete it? >> >>if we allow creating a hierarchy )or even a lattice) of TAAs, then >>once cannot answer this question without knowing the relationships >>of TAA1 and TAA2. > >So our protocol document (or operations document) will need to >define such relationships yes. >> >>>- If no, should there be "hard-delete" where it does delete it? >> >>define "hard delete" > >Delete even though this TA was added by another TAA. This does >assume that TAAs only manage the TAs they added. perhaps a simpler model is to allow a delete by a TAA if the TAA is authorized to delete the TA, period. Steve From owner-ietf-trust-anchor Mon Aug 13 08:32: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 l7DFWYcP017576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 08:32: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 l7DFWYOC017575; Mon, 13 Aug 2007 08:32: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 [165.227.249.213] (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 l7DFV0MB017330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 08:31:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <40F31377-6CFE-450C-9500-ED50163AD01A@checkpoint.com> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> <000801c7dad8$6ee87e30$0301a8c0@Wylie> <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> <40F31377-6CFE-450C-9500-ED50163AD01A@checkpoint.com> Date: Mon, 13 Aug 2007 08:30:15 -0700 To: Stephen Kent From: Paul Hoffman Subject: Re: Draft Charter Cc: Yoav Nir , 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:46 AM -0400 8/13/07, Stephen Kent wrote: >You raise an important issue of perspective. If a TAA is an >"authority" then it can try to do anything (e.g., issue any command >in a protocol), but the effects of what it does are constrained by >the authority granted to it. That authority may be defined by the >user, or by some other TAA. Exactly right. Our format/protocol gives TAAs the ability to state what they want, but it is up to the receiving system to decide what to do with that statement. >However, we do need to be very careful about the complexity of >polices that can be expressed here. We have lots of experience in >the security environment that suggest users, even sys admins, are >not very good at managing policies once the level of complexity >grows beyond a certain point. Our requirements development process >needs to be mindful of this issue, and not assume that users will >suddenly become much better at this crucial task. Fully agree. My view on this is that: - We need to make the single-TAA scenario work just as expected: the end user will follow that TAA's instructions exactly. - We need to make the multi-TAA scenario be simple. If we do not allow deletes, then there is problem, but I think we need to allow deletes. Given that, we should specify the simplest way to handle deletes. At 4:50 PM +0300 8/13/07, Yoav Nir wrote: >This just gave me a mental image of the next generation Internet >Explorer scary pop-up with the DN of the TAA and the DN of the new >TAA, a warning about possible exploits and data corruption, with the >final question "Do you accept this trust anchor?" If the hierarchy is defined as the user adds TAAs, then no such interaction is ever needed. I understand your desire for the single-TAA model, but please don't say that the multi-TAA model is more complicated than it needs to be. >>For example, assume that the user has the setting "TAA1 is more >>important than TAA2". Then, in your examples: >> >>>- If TAA1 adds a TA, can TAA2 delete it? >> >>No. > >What if TAA2 knows for a fact that the private key of the TA has >been compromised? The example I have in my head is TAA1 is >Microsoft (or Mozilla - the browser vendor), while TAA2 is your >company. I can't say that one is more important than the other. If you cannot create a hierarchy, then you are forcing the user to make decisions for every addition or removal of any TA. There was strong pushback against that in Chicago. That leaves us with two options: go with the single-TAA model, or go with a multi-TAA model that does not require user interaction when new TAs are added or current TAs are removed. I favor the latter. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Mon Aug 13 13:48: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 l7DKmaTD060875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 13:48: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 l7DKmaU1060873; Mon, 13 Aug 2007 13:48: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 l7DKmZhW060867 for ; Mon, 13 Aug 2007 13:48: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 4EA88F02A4 for ; Mon, 13 Aug 2007 13:48:35 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Mon, 13 Aug 2007 13:48:35 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Mon, 13 Aug 2007 13:48: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 1986322; Mon, 13 Aug 2007 13:48:27 -0700 Received: from [10.214.201.165] ([10.214.201.165]) by keys.pgpeng.com (PGP Universal service); Mon, 13 Aug 2007 13:48:27 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Mon, 13 Aug 2007 13:48:27 -0700 In-Reply-To: <46BCC0CC.2040805@cs.tcd.ie> References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Jon Callas Subject: Re: Issue with the requirements document: PKIX-centric terminology Date: Mon, 13 Aug 2007 13:48:29 -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 Aug 10, 2007, at 12:47 PM, Stephen Farrell wrote: > You seem to prefer that this work be scoped so as to be limited > to x.509 TAs only. > > I'm just wondering if you see any specific benefit to that, or > if its just that you've not seen specific enough reasons to want > to support more than x.509? > > (From my p-o-v, I guess I'd argue that any TA related work starting > in 2008 shouldn't only support x.509.) I'm involved in this because I see a value for it for what I do with X.509. But I also need it for OpenPGP, as well. Well, maybe not *need*. One of the things about OpenPGP is that it has a number of quasi-standard, ad-hoc ways to do a lot of things. I mean "quasi-standard" that we all do it the same way, and there's no document describing that way. Also, OpenPGP has always had the notion that roots are in the eye of the beholder, and any certificate can be a root. However, it would be very, very useful to have TAM specify how to push trust points around. It fills a huge gap in the documentation of how the larger world works. My first observation to the draft-00 was to ask if it was PKIX- specific. The answer then was that it's not. That's great, to me. I want this for other certificate types, most specifically OpenPGP. I have been broader than that because I know people building systems and considering using SPKI, and they would need this, too, or have to develop their own, ad-hoc way of doing 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 Mon Aug 13 14:47: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 l7DLlFD3067760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 14:47: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 l7DLlFU9067759; Mon, 13 Aug 2007 14:47: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 keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DLlDKg067744 for ; Mon, 13 Aug 2007 14:47:14 -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 AC138F02A6 for ; Mon, 13 Aug 2007 14:47:13 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Mon, 13 Aug 2007 14:47:13 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Mon, 13 Aug 2007 14:47:13 -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 1986603 for ietf-trust-anchor@vpnc.org; Mon, 13 Aug 2007 14:47:12 -0700 Received: from [10.214.201.165] ([10.214.201.165]) by keys.pgpeng.com (PGP Universal service); Mon, 13 Aug 2007 14:47:12 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Mon, 13 Aug 2007 14:47:12 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <46BCC098.4030808@cs.tcd.ie> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> <46BCBE41.6000707@cs.tcd.ie> <82D5657AE1F54347A734BDD33637C87908C9C352@EXVS01.ex.dslextreme.net> <46BCC098.4030808@cs.tcd.ie> Message-Id: <541D144E-80AD-4B07-85EB-4EF2786E811D@pgpeng.com> From: Jon Callas Subject: Re: Draft Charter Date: Mon, 13 Aug 2007 14:47:14 -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 Aug 10, 2007, at 12:46 PM, Stephen Farrell wrote: > > > > Santosh Chokhani wrote: >> What is X.509 specific? >> The term certificate or certification path or both. > > Yes. For me anyway, particularly the latter term. > > > Will PGP and others >> not have a chain of keys/certificates? > > Who knows? (Can't recall off the top of my head what the > PGP things are called - not keyrings was it?) > They're called "certificates." The process where by one certificate certifies another one is something we call "certification." I know that sounds flippant, but it isn't. More below. I wasn't going to send this note at all until we got into discussions of what format certificates TAM ought to address. >> Are not these concepts generic and is this not time to separate >> concepts >> from X.509 format? > > That would be a worthwhile activity. But not one that it'd be wise > to build in as a precondition on this proposed activity. So I'd rather > see a definition use more neutral terms. > An historical note first. The term "key" for "certificate" in the way that it is colloquially used in OpenPGP was coined by Whit Diffie. People like it. It's short, friendly, and has a nice provenance. However, it isn't accurate. A certificate contains a key, but a certificate is not a key. Worse, an OpenPGP certificate typically contains at least two public keys, along with a number of certifications. (It is possible to have a one-key OpenPGP certificate, but that can only be used for signing. If you want to encrypt something, you need a signing key and an encryption key in your certificate. Right now, we're moving to a use model that has at least three keys -- where the top level signing key is merely a certification key, and there's an encryption and signing subkey. This is particularly popular in Europe.) What this means is that if you say "OpenPGP Key" and want to talk about its components, you're using the word "key" far too many times. I have tried to apply rigor to the terminology, but people like using the word "key" for "certificate" and refused to play along. So I merely get precise when I need to. X.509 has a much more atomic model of certificates, but you can create the same structures of an OpenPGP certificate with a handful of X.509 certificates. Likewise, you can take a "certificate set" or "certificate family" of X.509 certificates and create an OpenPGP certificate out of them. (Note that I'm simplifying here. I don't have time to write, nor you to read the constraints and further explanations I want to write.) There is a *syntactic* isomorphism between OpenPGP and X.509. The differences are in the semantics, but you can express those semantics with either syntax. I sometimes think of this in a graph-theoretic way, and in that mode of thought, the primary X.509 object is a node +edge pair, from which you then make up graphs, and the OpenPGP object is a small graph, which contains nodes and edges. Another metaphor is that X.509 starts with quarks and builds up atoms, while OpenPGP starts with atoms that contain quarks. I like this one because in physics, atoms are not atomic, and they are not atomic for historical reasons. Now where the OpenPGP and X.509 (particularly PKIX) models diverge is an attitude about issuers and roots. In OpenPGP, every user is a potential CA. Every certificate is a potential root. This makes for some semantic differences, as well as attitude differences. Every so often, a PKIX/X.509 discussion comes up about using the same public key in more than one certificate. One thing that always comes out of that discussion is noting that if you did it, you'd need a way to revoke a public key as well as a certificate, and no such thing exists. Well, OpenPGP effectively does this by having both a signature revocation and a "key" revocation mechanism. Note that in *this* case, the OpenPGP colloquialism of "key" actually means a key! (If Alice and Bob each certify my "key," that corresponds to my having three X.509 certificates, each with the same public key. My "key" is three certs, one issued by Alice, one issued by Bob, and one that is self-signed. If I revoke my self-signed certificate, that implies revoking the other two. Yes, I know all the things you're thinking now.) So let me get to keyrings, and then back to TAM. There's no such thing as a keyring. More precisely, it is not well-defined. That file you have for PGP or GnuPG is a sequential file of OpenPGP certificates, nothing more. However, a "keyring" could also be an SQL database containing same. So if you permit me to contradict myself, a "keyring" is nothing more than a certificate database with a warm, fuzzy, Diffie-coined word for it, and is often implemented as a flat file. OpenPGP makes a show of explicitly not defining how to express trust. This is because when the OpenPGP working group was formed, we were told we couldn't be a PKI, and that meant we couldn't standardize trust. So while there is a "trust packet" in OpenPGP, it's officially implementation-dependent. As it turns out by some happy coincidence, we all base our trust structures on what went before, and we can (usually) directly import these from one implementation to another. And this is why TAM would be useful to OpenPGP, and why you'll find slightly tepid comments from some people. Historically, we've solved these problems among ourselves, and typically it all works just fine. In other words, TAM gives X.509 ways to do things that OpenPGP has done for a long time. However, I know there are rough edges, and TAM would be a fine way to iron them out. For my company, PGP Corporation, we work in PKIs that are imaged into X.509 syntax and OpenPGP syntax. We need to maintain parallel structures, and TAM is a fine way to do it. If TAM becomes PKIX-only, then I'm going to have to make a TAM extension to handle certs in different formats. I can think now of a way to do it: I go look at whatever TAM decides, and go directly to where the ASN.1 says "certificate goes here." And then I just put there instead of the certificate a type-constant (an OID?) and then the certificate. Then poof, Alice is your auntie, and we're all done. Is it *that* hard to make this part of TAM, and have type constants for PKIX, X.509, SPKI, DNSsec, SAML, XML-whatever, DKIM, etc.? 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 Aug 13 16:38: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 l7DNcYRw080600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 16:38: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 l7DNcYcq080598; Mon, 13 Aug 2007 16:38: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DNcXag080583 for ; Mon, 13 Aug 2007 16:38:33 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.130.101]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IKjUW-00083E-6E; Mon, 13 Aug 2007 19:38:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> Date: Mon, 13 Aug 2007 19:17:56 -0400 To: Jon Callas From: Stephen Kent Subject: Re: Issue with the requirements document: PKIX-centric terminology 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 1:48 PM -0700 8/13/07, Jon Callas wrote: >>... > >I'm involved in this because I see a value for it for what I do with >X.509. But I also need it for OpenPGP, as well. > >Well, maybe not *need*. One of the things about OpenPGP is that it >has a number of quasi-standard, ad-hoc ways to do a lot of things. I >mean "quasi-standard" that we all do it the same way, and there's no >document describing that way. > >Also, OpenPGP has always had the notion that roots are in the eye of >the beholder, and any certificate can be a root. The term used in X.509/PKIX (and this would-be WG) is TA, and X.509 allows any key (not just certs) to be used as a TA, and yes, the decision is purely up to the relying party; but we DO write thus stuff down :-). >However, it would be very, very useful to have TAM specify how to >push trust points around. It fills a huge gap in the documentation >of how the larger world works. I'm puzzled by this comment. Unles you're suggesting that the protocol that is developed must mimic what OPGP does, one ought not argue that "It fills a huge gap in the documentation of how the larger world works." >My first observation to the draft-00 was to ask if it was >PKIX-specific. The answer then was that it's not. That's great, to >me. I want this for other certificate types, most specifically >OpenPGP. I have been broader than that because I know people >building systems and considering using SPKI, and they would need >this, too, or have to develop their own, ad-hoc way of doing it. SPKI is not an IETF standard, and in earlier discussion on the list I think we agreed to not include it. Steve From owner-ietf-trust-anchor Mon Aug 13 16:38: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 l7DNcY8U080601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 16:38: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 l7DNcYDw080599; Mon, 13 Aug 2007 16:38: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DNcXBV080582 for ; Mon, 13 Aug 2007 16:38:33 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.130.101]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IKjUW-00083E-3T; Mon, 13 Aug 2007 19:38:32 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <46C0C1F9.3040006@pgp.com> References: <2DE3D90A-A8A9-4EC0-B3C7-7A0574133635@pgpeng.com> <46C0C1F9.3040006@pgp.com> Date: Mon, 13 Aug 2007 19:12:25 -0400 To: Derek Atkins From: Stephen Kent Subject: Re: Issue with the requirements document: PKIX-centric terminology 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: >... > >That's not exactly what I said. I said that the requirements for >OpenPGP were very different than that of PKIX. OpenPGP doesn't define >trust semantics (we were forbidden from doing so), but that doesn't mean >that OpenPGP doesn't need them. Moreover, OpenPGP could certainly use >TAM as a means of certificate distribution. > >-derek Derek, Sorry to have mis-characterized your statement. I'm not sure what you men by "trust semantics." One reasonable interpretation might make OPGP equivalent to X.509 in that regard, but I'd rather hear exactly what you mean by the phrase. Note that for X.509/PKIX, it will be important to consider the semantics of certain fields of certs (and cert extensions) in order to define requirements for TA management and to define the policy language. We have a reasonably well-articulated model for several fields upon which we impose constraints via extensions, e.g., Subject name, Subject Alt Name, Policies, address space and As number extensions, ... Steve From owner-ietf-trust-anchor Mon Aug 13 16:47: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 l7DNlgDb081549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 16:47: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 l7DNlgYC081548; Mon, 13 Aug 2007 16:47: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 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 l7DNlciA081530 for ; Mon, 13 Aug 2007 16:47:40 -0700 (MST) (envelope-from thardjono@wavesys.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: Draft Charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Aug 2007 16:48:14 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Charter Thread-Index: Acfds1z7obasLw4tSNab0zBPhVZEkAATvfRA From: "Thomas Hardjono" To: "Yoav Nir" , "Stephen Kent" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7DNlfiA081543 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 Yoav Nir > Sent: Monday, August 13, 2007 6:55 AM > To: Stephen Kent > Cc: ietf-trust-anchor@vpnc.org > Subject: Re: Draft Charter > > > > On Aug 13, 2007, at 4:40 PM, Stephen Kent wrote: > > > At 9:18 AM +0300 8/12/07, Yoav Nir wrote: > >> In Chicago there was some controversy about whether multiple > >> administrators should be in scope. This charter draft says that > >> they're in. I'm not saying they shouldn't be, but it does add > >> complexity. > >> > >> If they're in, we need to answer big questions: > >> - If TAA1 adds a TA, can TAA2 delete it? > > > > if we allow creating a hierarchy )or even a lattice) of TAAs, then > > once cannot answer this question without knowing the > relationships of > > TAA1 and TAA2. > > So our protocol document (or operations document) will need > to define such relationships > > > >> - If no, should there be "hard-delete" where it does delete it? > > > > define "hard delete" > > Delete even though this TA was added by another TAA. This > does assume that TAAs only manage the TAs they added. > > > >> - If TAA1 adds a TA, and then TAA2 adds it again, and then TAA1 > >> deletes it, is it there or not? > > > > this already presumes that the addition you mention is idempotent, > > somethign we have yet to deciude. > > Of course. I'm just enumerating several possible complexities > off the top of my head. > > > >> - Should TAA2 be able to query TAs added by TAA1? > >> - Should we have a delete-all command (I think that's > necessary for > >> the store-and-forward scenario) > >> - How does delete-all interact with multiple TAAs? Do we need a > >> hard-delete-all? > >> > >> I would answer these questions no, yes, yes, yes, yes and yes, but > >> these are far from trivial. > >> > >> I think these and other issues suggest we should split the TAMP > >> protocol deliverables into two documents: one to deal with the > >> protocol, formats, encoding (XML/ASN.1) and the > online/offline case. > >> The other document should deal with trust anchor store > operations: > >> how the database is structured and what it does with the various > >> commands. > >> > >> Yoav > > > > how about one to agree on the requirements first :-), > before we define > > the syntax and semantics? > > > > Steve With regards to the thread on multiple TA-Authorities (TAA), this is why I was a bit insistent earlier that we focus initially on the Enterprise environment (since its easier). Within the Enterprise there is typically a single TAA (eg. IT admin), and she/he will be the entity doing the adding/deleting of all Trust Anchors for all the machines & devices within the Enterprise. (PS. I'm assuming here that commands to install/delete TAs will be accompanied by the appropriate source authentication). In the Consumer space, TA usage and management may have to be application-driven. Meaning that if an organization (e.g. Bank, SalesForce.com, etc) requires its TA to be present at the client end-point before allowing a transaction, then the home-user will just have to accept such installation (ie. press "Yes" at the dialog box). If a Bank's TA is inadvertently deleted (eg. by a user, malware or another TA), then the Bank will just have to install it again the next time the user seeks to transact with the Bank. If a virus or malware succeeds in deleting or modifying TAs at a consumer machine, well the consumer will simply have to (somehow) install them back agaian (eg. from backup). /thomas/ From owner-ietf-trust-anchor Mon Aug 13 17:26: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 l7E0QHak084926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 17:26: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 l7E0QHHD084925; Mon, 13 Aug 2007 17:26: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7E0QFA1084919 for ; Mon, 13 Aug 2007 17:26:16 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.130.101]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IKkEh-000068-4r; Mon, 13 Aug 2007 20:26:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <541D144E-80AD-4B07-85EB-4EF2786E811D@pgpeng.com> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> <46BCBE41.6000707@cs.tcd.ie> <82D5657AE1F54347A734BDD33637C87908C9C352@EXVS01.ex.dslextreme.net> <46BCC098.4030808@cs.tcd.ie> <541D144E-80AD-4B07-85EB-4EF2786E811D@pgpeng.com> Date: Mon, 13 Aug 2007 20:26:22 -0400 To: Jon Callas From: Stephen Kent Subject: Re: Draft Charter 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 2:47 PM -0700 8/13/07, Jon Callas wrote: >... >An historical note first. The term "key" for "certificate" in the >way that it is colloquially used in OpenPGP was coined by Whit >Diffie. People like it. It's short, friendly, and has a nice >provenance. I believe the term "certificate" was coined in an MIT bachelor's thesis by Kornfelder in 1978. (Ron Rivest was the thesis advisor.). The original D-H paper in 1976 had no concept of a cert; instead it talked about making public keys available in a phone book like manner. >However, it isn't accurate. A certificate contains a key, but a >certificate is not a key. right. >Worse, an OpenPGP certificate typically contains at least two public >keys, along with a number of certifications. (It is possible to have >a one-key OpenPGP certificate, but that can only be used for >signing. If you want to encrypt something, you need a signing key >and an encryption key in your certificate. Right now, we're moving >to a use model that has at least three keys -- where the top level >signing key is merely a certification key, and there's an encryption >and signing subkey. This is particularly popular in Europe.) this recursive definition of a cert may be a good example of why it may be hard to develop a protocol that uses a consistent set of terminology and embraces both OPGP and X.509/PKIX. >What this means is that if you say "OpenPGP Key" and want to talk >about its components, you're using the word "key" far too many >times. I have tried to apply rigor to the terminology, but people >like using the word "key" for "certificate" and refused to play >along. So I merely get precise when I need to. on this list you probably should assume the need to be precise :-). >... > > >Now where the OpenPGP and X.509 (particularly PKIX) models diverge >is an attitude about issuers and roots. In OpenPGP, every user is a >potential CA. Every certificate is a potential root. This makes for >some semantic differences, as well as attitude differences. > >Every so often, a PKIX/X.509 discussion comes up about using the >same public key in more than one certificate. One thing that always >comes out of that discussion is noting that if you did it, you'd >need a way to revoke a public key as well as a certificate, and no >such thing exists. Well, OpenPGP effectively does this by having >both a signature revocation and a "key" revocation mechanism. Note >that in *this* case, the OpenPGP colloquialism of "key" actually >means a key! There are a lot of reasons why it is preferable to not reuse a public key in multiple certs. The semantics of X.509 deal with cert revocation because a CA's job is to vouch for the binding of the attributes in a cert and the public key in that cert. Revocaton of the cert breaks the binding, which is both necessary and sufficient for the semantic model. There is not need to add an ability to revoke keys, because a CA does not attest to the security of the key in any larger sense. >(If Alice and Bob each certify my "key," that corresponds to my >having three X.509 certificates, each with the same public key. My >"key" is three certs, one issued by Alice, one issued by Bob, and >one that is self-signed. If I revoke my self-signed certificate, >that implies revoking the other two. Yes, I know all the things >you're thinking now.) I'd try to avoid that last phrase as it may strike some as both presumptuous and, at least in my case, usually wrong :-). >So let me get to keyrings, and then back to TAM. There's no such >thing as a keyring. More precisely, it is not well-defined. That >file you have for PGP or GnuPG is a sequential file of OpenPGP >certificates, nothing more. However, a "keyring" could also be an >SQL database containing same. So if you permit me to contradict >myself, a "keyring" is nothing more than a certificate database with >a warm, fuzzy, Diffie-coined word for it, and is often implemented >as a flat file. a clear definition for a key ring would not require any mention of the type of database by which the set of certs is maintained, so, hopefully, there is a better reason that the term is not defined in any documents, right? >OpenPGP makes a show of explicitly not defining how to express >trust. This is because when the OpenPGP working group was formed, we >were told we couldn't be a PKI, and that meant we couldn't >standardize trust. So while there is a "trust packet" in OpenPGP, >it's officially implementation-dependent. As it turns out by some >happy coincidence, we all base our trust structures on what went >before, and we can (usually) directly import these from one >implementation to another. This is a very odd characterization. Despite the blatant overuse of the term, especially in marketing literature and poorly written papers, both the syntax and semantics of X.509 can be described w/o reference to the word "trust." (Even the term "trust anchor" need not be defined using the word trust, as the candidate definitions bandied about on this list have shown.) >And this is why TAM would be useful to OpenPGP, and why you'll find >slightly tepid comments from some people. Historically, we've solved >these problems among ourselves, and typically it all works just >fine. In other words, TAM gives X.509 ways to do things that OpenPGP >has done for a long time. Is this another set of things that OPGP does but which is not documented in any IETF publication? >However, I know there are rough edges, and TAM would be a fine way >to iron them out. For my company, PGP Corporation, we work in PKIs >that are imaged into X.509 syntax and OpenPGP syntax. We need to >maintain parallel structures, and TAM is a fine way to do it. > >If TAM becomes PKIX-only, then I'm going to have to make a TAM >extension to handle certs in different formats. I can think now of a >way to do it: > >I go look at whatever TAM decides, and go directly to where the >ASN.1 says "certificate goes here." And then I just put there >instead of the certificate a type-constant (an OID?) and then the >certificate. Then poof, Alice is your auntie, and we're all done. > >Is it *that* hard to make this part of TAM, and have type constants >for PKIX, X.509, SPKI, DNSsec, SAML, XML-whatever, DKIM, etc.? Syntax is not the hard part here. For example, when one defines the language needed to characterize the constraints ompised on TAAs, and the constraints expressible via a TA data structure, one probably has to be cognizant of the semantics of the certs being managed, else there will be no way to ensure that the language has enough richness to meet the requirements of the target user community (whoever we decide that to be). For example, in the X.509 context, it seems likely that we need the ability to express name constraints, maybe policy constraints, certainly RFC 3779 constraints, etc. Also, what is SAML doing in your list? It is not a PKI mechanism, not a public key format, ... Steve From owner-ietf-trust-anchor Mon Aug 13 17: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 l7E0WHkQ085300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 17: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 l7E0WHfD085299; Mon, 13 Aug 2007 17: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 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 l7E0WEFt085291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Aug 2007 17:32:16 -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 2BA7E41CF; Tue, 14 Aug 2007 01:32:14 +0100 (IST) Received: from [127.0.0.1] (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 l7E0WCBb025782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Aug 2007 01:32:12 +0100 Message-ID: <46C0F80D.7060004@cs.tcd.ie> Date: Tue, 14 Aug 2007 01:32:13 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jon Callas CC: ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> <46BCBE41.6000707@cs.tcd.ie> <82D5657AE1F54347A734BDD33637C87908C9C352@EXVS01.ex.dslextreme.net> <46BCC098.4030808@cs.tcd.ie> <541D144E-80AD-4B07-85EB-4EF2786E811D@pgpeng.com> In-Reply-To: <541D144E-80AD-4B07-85EB-4EF2786E811D@pgpeng.com> 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: 12550411 - bffb8e617d72 (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: Hi Jon, Thanks for the interesting post - that's actually clarified a few pgp things for me that I've always glossed over. Jon Callas wrote: [...good stuff, then...] > Is it *that* hard to make this part of TAM, and have type constants for > PKIX, X.509, SPKI, DNSsec, SAML, XML-whatever, DKIM, etc.? Tend to agree. One more TLV isn't very much to ask at all, assuming this becomes a new WG. If this work were to be done inside PKIX then that extra TLV would probably open too many cans of worms, perhaps sufficient to make that good idea become a bad idea;-) Cheers, S. From owner-ietf-trust-anchor Mon Aug 13 17:38: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 l7E0crLe085742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 17:38: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 l7E0cr82085740; Mon, 13 Aug 2007 17:38: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 relay.imagine.ie (relay.imagine.ie [87.232.1.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7E0covl085732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Aug 2007 17:38:52 -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 1ED97410C; Tue, 14 Aug 2007 01:38:50 +0100 (IST) Received: from [127.0.0.1] (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 l7E0cmq0026467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Aug 2007 01:38:48 +0100 Message-ID: <46C0F999.7030702@cs.tcd.ie> Date: Tue, 14 Aug 2007 01:38:49 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen Kent CC: Jon Callas , ietf-trust-anchor@vpnc.org Subject: Re: Issue with the requirements document: PKIX-centric terminology References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@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: 12550533 - 496714b837c6 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: > SPKI is not an IETF standard, and in earlier discussion on the list I > think we agreed to not include it. Well, two things. I don't recall any explicit consensus to omit spki, since we've not really got any concrete things on which we've yet got a rough consensus (the draft charter handed to the IESG I guess would be the first such). Secondly, sure, spki isn't a standard, and isn't really in serious use (afaik), but a putative WG could still agree to allocate a tag. I think the chances of spki being seen as a serious distraction to PKIX are pretty much zero these days, so that tag has no real cost. Its potential benefit is really that it might raise some technical issue that would otherwise have gone unnoticed, thus improving TAM and PKIX and OpenPGP and all. S. From owner-ietf-trust-anchor Tue Aug 14 04:59: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 l7EBxp4i062798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 04:59: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 l7EBxpsC062797; Tue, 14 Aug 2007 04:59: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 l7EBxntR062789 for ; Tue, 14 Aug 2007 04:59:50 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 3067 invoked from network); 14 Aug 2007 11:56:50 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;14 Aug 2007 11:56:50 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 14 Aug 2007 11:56:50 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Tue, 14 Aug 2007 07:59:45 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31D41D@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: Draft Charter Date: Tue, 14 Aug 2007 07:59:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DE6A.9A1FFDD8" 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_01C7DE6A.9A1FFDD8 Content-Type: text/plain > perhaps a simpler model is to allow a delete by a TAA if the > TAA is authorized to delete the TA, period. > This seems like the right rule to me. The TAA that added a particular TA need not be considered at deletion time. ------_=_NextPart_001_01C7DE6A.9A1FFDD8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Charter

 
> perhaps a simpler model is to allow a delete by = a TAA if the
> TAA is authorized to delete the TA, = period.
>

This seems like the right rule to me.  The TAA = that added a particular TA need not be considered at deletion time. =

------_=_NextPart_001_01C7DE6A.9A1FFDD8-- From owner-ietf-trust-anchor Tue Aug 14 11:15: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 l7EIFtIC033410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 11:15: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 l7EIFt4E033409; Tue, 14 Aug 2007 11:15: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 keys.pgpeng.com (keys.pgpeng.com [63.251.255.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7EIFsFf033400 for ; Tue, 14 Aug 2007 11:15:55 -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 8D577F02AA for ; Tue, 14 Aug 2007 11:15:54 -0700 (PDT) Received: from pgpeng.com ([63.251.255.75]) by keys.pgpeng.com (PGP Universal service); Tue, 14 Aug 2007 11:15:54 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Tue, 14 Aug 2007 11:15:54 -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 1988909 for ietf-trust-anchor@vpnc.org; Tue, 14 Aug 2007 11:15:53 -0700 Received: from [66.93.68.165] ([10.214.2.201]) by keys.pgpeng.com (PGP Universal service); Tue, 14 Aug 2007 11:15:53 -0700 X-PGP-Universal: processed; by keys.pgpeng.com on Tue, 14 Aug 2007 11:15:53 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> Message-Id: From: Jon Callas Subject: Re: Issue with the requirements document: PKIX-centric terminology Date: Tue, 14 Aug 2007 11:15:55 -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 Aug 13, 2007, at 4:17 PM, Stephen Kent wrote: > >> My first observation to the draft-00 was to ask if it was PKIX- >> specific. The answer then was that it's not. That's great, to me. >> I want this for other certificate types, most specifically >> OpenPGP. I have been broader than that because I know people >> building systems and considering using SPKI, and they would need >> this, too, or have to develop their own, ad-hoc way of doing it. > > SPKI is not an IETF standard, and in earlier discussion on the list > I think we agreed to not include it. > I remember an argument that it not be included. I remember that particular reason being given, and that that reason is a good one. However, I also remember the counter-argument, and that argument being that since certs-in-DNS includes it, why not TAM, *if* it is little more than assigning a constant that places a type on a following blob. I also believe that one is a good one. I also remember us all agreeing to stop debating, at least implicitly, because that's a side issue to the core of TAM. Nonetheless, I perceive your arguments saying that no other certificate system other than X.509 should be under the TAM aegis. I perceive that you argued in specific that OpenPGP need not be there, citing Mr Atkins, and asking if some one who is actually an implementer or author or something to come forward -- as if I, who have been here all along, am neither. I'm happy to debate a generalized certificate theory here, or over a beer. For the purposes of TAM, however, my opinions about certificates, however interesting anyone finds them, are irrelevant. The relevance to TAM is solely in saying, "I want TAM for OpenPGP, and here's why." I say that as an OpenPGP author, and as an implementer of multi-format PKIs. I think that if TAM becomes X.509-only, that's fine, but it shouldn't be chartered as a separate working group, it ought to be a work item for PKIX. The whole reason for it being a separate WG would be if it's broad enough to have appeal outside of PKIX. Mind you, if it's PKIX-only, I still want it and need it. I won't go away, and it will give me reason to pay attention to PKIX again. (The fact that I don't presently is because I think y'all do a fine job without me. I trust you.) To sum up -- you asked for someone in the OpenPGP world to stand up and say they want it. Yoo hoo, over here. Me. 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 Aug 14 12:26: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 l7EJQpTH040544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 12:26: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 l7EJQpcW040543; Tue, 14 Aug 2007 12:26: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 [165.227.249.213] (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 l7EJQmjd040532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Aug 2007 12:26:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> Date: Tue, 14 Aug 2007 12:26:25 -0700 To: ietf-trust-anchor@vpnc.org From: Paul Hoffman Subject: Re: Issue with the requirements document: PKIX-centric terminology 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: Further, I want to emphasize that TAM should be able to pass bare public keys and not require them to be PKIX-wrapped certs. There are lots of use cases where keys are more appropriate than a cert, and the semantics will be much clearer. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Aug 14 14:35: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 l7ELZtaa054698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 14:35: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 l7ELZtOb054697; Tue, 14 Aug 2007 14:35: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 smtp3.su.se (smtp3.su.se [130.237.93.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7ELZsJ5054678; Tue, 14 Aug 2007 14:35:55 -0700 (MST) (envelope-from leifj@it.su.se) Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 36E843BF5A; Tue, 14 Aug 2007 23:35:53 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03123-01-95; Tue, 14 Aug 2007 23:35:52 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 4561B3BF1E; Tue, 14 Aug 2007 23:35:49 +0200 (CEST) Message-ID: <46C2203D.8000400@it.su.se> Date: Tue, 14 Aug 2007 23:35:57 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Paul Hoffman CC: ietf-trust-anchor@vpnc.org Subject: Re: Issue with the requirements document: PKIX-centric terminology References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.275 tagged_above=-99 required=7 tests=[AWL=0.037, BAYES_00=-2.312] X-Spam-Level: Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Hoffman wrote: > > Further, I want to emphasize that TAM should be able to pass bare > public keys and not require them to be PKIX-wrapped certs. There are > lots of use cases where keys are more appropriate than a cert, and the > semantics will be much clearer. > > --Paul Hoffman, Director > --VPN Consortium > Won't a typed blob of some sort neatly solve all of the issues around certificate types? I'm asking because a typed blob will also have other nice properties such as isolation between a tam "engine" and plugins dealing with individual certificate types. This will allow us to spend time figuring out what a tam "client" must be able to assume about the entities stored in a tam "server" rather than engage in a discussion on the metaphysics of trust ;-) Cheers Leif From owner-ietf-trust-anchor Tue Aug 14 15:12: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 l7EMCZdI058099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 15:12: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 l7EMCZMY058098; Tue, 14 Aug 2007 15:12: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 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 l7EMCXZI058085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Aug 2007 15:12:34 -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 79B5B320A1; Tue, 14 Aug 2007 23:12:32 +0100 (IST) Received: from [127.0.0.1] (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 l7EMCTCR002521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Aug 2007 23:12:31 +0100 Message-ID: <46C228CF.80000@cs.tcd.ie> Date: Tue, 14 Aug 2007 23:12:31 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Leif Johansson CC: ietf-trust-anchor@vpnc.org Subject: Re: Issue with the requirements document: PKIX-centric terminology References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> <46C2203D.8000400@it.su.se> In-Reply-To: <46C2203D.8000400@it.su.se> 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: 12597237 - fdf0191e3abd 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: Leif Johansson wrote: > Won't a typed blob of some sort neatly solve all of the issues around > certificate types? I'm asking because a typed blob will also have other > nice properties such as isolation between a tam "engine" and plugins > dealing with individual certificate types. At the syntactic level, yes. But I suspect we need to think more about what's in some blob variants, in particular x.509 blobs and I guess PGP blobs. That process might lead to some other fields in PDUs or not, but we need to think it through in any case, S. From owner-ietf-trust-anchor Tue Aug 14 15:15: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 l7EMF2CF058286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 15:15: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 l7EMF2hU058285; Tue, 14 Aug 2007 15:15: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 yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7EMExgC058261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Aug 2007 15:15:01 -0700 (MST) (envelope-from simon@josefsson.org) Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l7EMEsSH019684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2007 00:14:55 +0200 From: Simon Josefsson To: Paul Hoffman Cc: ietf-trust-anchor@vpnc.org Subject: Re: Issue with the requirements document: PKIX-centric terminology References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070814:ietf-trust-anchor@vpnc.org::lkp3pefmTZJz4svD:CJwD X-Hashcash: 1:22:070814:paul.hoffman@vpnc.org::RIXS8vVUZ1JWOw+g:lx3v Date: Wed, 15 Aug 2007 00:14:54 +0200 In-Reply-To: (Paul Hoffman's message of "Tue\, 14 Aug 2007 12\:26\:25 -0700") Message-ID: <87fy2lwyox.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Hoffman writes: > Further, I want to emphasize that TAM should be able to pass bare > public keys and not require them to be PKIX-wrapped certs. There are > lots of use cases where keys are more appropriate than a cert, and the > semantics will be much clearer. I agree, I think TAM should support bare public keys. Another closely related use-case that I believe is relevant that haven't been mentioned is SECSH. Or have people dismissed SECSH in this context for some reason that I'm not seeing? Btw, I'm also supportive of TAM including OpenPGP. I don't see TAM as something very exciting if it is PKIX only. Useful, but not as useful. As I understand it, the issue here seems to be more about terminology problems and allocating a typed-hole for various technologies (like certs-in-dns), rather than two (or more) fundamentally different technical solutions. As such, I think the effort required to accommodate everyone is relatively low. /Simon From owner-ietf-trust-anchor Tue Aug 14 15:40: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 l7EMe6qq060024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 15:40: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 l7EMe6AY060023; Tue, 14 Aug 2007 15:40: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 [165.227.249.213] (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 l7EMe1W7060013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 15:40:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <46C2203D.8000400@it.su.se> References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> <46C2203D.8000400@it.su.se> Date: Tue, 14 Aug 2007 15:39:37 -0700 To: Leif Johansson From: Paul Hoffman Subject: Re: Issue with the requirements document: PKIX-centric terminology 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:35 PM +0200 8/14/07, Leif Johansson wrote: >Won't a typed blob of some sort neatly solve all of the issues around >certificate types? Yes. >I'm asking because a typed blob will also have other >nice properties such as isolation between a tam "engine" and plugins >dealing with individual certificate types. > >This will allow us to spend time figuring out what a tam "client" must be >able to assume about the entities stored in a tam "server" rather than >engage in a discussion on the metaphysics of trust ;-) Fully agree. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Aug 14 17:19: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 l7F0J7Gg066977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 17:19: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 l7F0J7Nb066976; Tue, 14 Aug 2007 17:19: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 l7F0J55M066960 for ; Tue, 14 Aug 2007 17:19:06 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.130.101]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IL6bI-0002lZ-3K; Tue, 14 Aug 2007 20:19:04 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <46C0F999.7030702@cs.tcd.ie> References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> <46C0F999.7030702@cs.tcd.ie> Date: Tue, 14 Aug 2007 19:13:28 -0400 To: Stephen Farrell From: Stephen Kent Subject: Re: Issue with the requirements document: PKIX-centric terminology 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 1:38 AM +0100 8/14/07, Stephen Farrell wrote: >Stephen Kent wrote: >>SPKI is not an IETF standard, and in earlier discussion on the list >>I think we agreed to not include it. > >Well, two things. I don't recall any explicit consensus to omit >spki, since we've not really got any concrete things on which we've >yet got a rough consensus (the draft charter handed to the IESG >I guess would be the first such). I thought we had a message exchange on the topic and agreed that SPKI was out of scope. My concern is that we keep talking as though the syntax of a cert is at the heart of this problem, which I think is just plain wrong. That's why a document like RFC 4398 is irrelevant. Defining a format for storing any form of cert in the DNS is trivial, because the DNS is not making use of the content to make decisions. In contrast many of the proposed TAM use cases DO need to pay attention to the contents of TAs (whether they be certs or not), in order to support meaningful TA management. >Secondly, sure, spki isn't a standard, and isn't really in serious >use (afaik), but a putative WG could still agree to allocate a >tag. I think the chances of spki being seen as a serious distraction >to PKIX are pretty much zero these days, so that tag has no real >cost. This is not a PKIX vs. SPKI issue. The IESG settled that a long time ago when it killed the SPKI WG. If all it takes is a tag, then the cost would be low for the authors, but the cost could be quite high in other ways. For example, there have been many papers that begin by saying that "... because X.509 requires a singly-rooted tree for a PKI ..." I spend way too much time as a program committee member correcting that sort of error in papers submitted to conferences. This type of misconception arises repeatedly because other people don't take the time to strike such nonsense, clueless authors read it, and then write bad papers. >Its potential benefit is really that it might raise some >technical issue that would otherwise have gone unnoticed, thus >improving TAM and PKIX and OpenPGP and all. Your sentence above suggests that by considering SPKI we might include additional functions that otherwise might not be present. That seems to contradict the assertion that the cost would be minimal, i.e., just a tag to identify the syntax. If we do our job well, we'll generate requirements based on the protocol contexts we specifically say we need to support. Steve From owner-ietf-trust-anchor Tue Aug 14 17:25: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 l7F0P0UO067234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 17:25: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 l7F0P0dJ067233; Tue, 14 Aug 2007 17:25: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7F0Oxon067224 for ; Tue, 14 Aug 2007 17:24:59 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.130.101]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IL6h0-0007yA-5w; Tue, 14 Aug 2007 20:24:58 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> Date: Tue, 14 Aug 2007 20:25:05 -0400 To: Jon Callas From: Stephen Kent Subject: Re: Issue with the requirements document: PKIX-centric terminology 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:15 AM -0700 8/14/07, Jon Callas wrote: >>... >>SPKI is not an IETF standard, and in earlier discussion on the list >>I think we agreed to not include it. >> > >I remember an argument that it not be included. I remember that >particular reason being given, and that that reason is a good one. >However, I also remember the counter-argument, and that argument >being that since certs-in-DNS includes it, why not TAM, *if* it is >little more than assigning a constant that places a type on a >following blob. I also believe that one is a good one. I also >remember us all agreeing to stop debating, at least implicitly, >because that's a side issue to the core of TAM. I keep saying that the format of what is being moved about is not nearly so hard a problem as the semantics of what is being moved, but either nobody believes me or nobody is listening. I can;t tell which based on he responses :-). >Nonetheless, I perceive your arguments saying that no other >certificate system other than X.509 should be under the TAM aegis. I >perceive that you argued in specific that OpenPGP need not be there, >citing Mr Atkins, and asking if some one who is actually an >implementer or author or something to come forward -- as if I, who >have been here all along, am neither. What I think I said was that, in my conversations with two other folks at the IETF meeting, before the TAM BoF, my perception was that there was little or no expressed need for TAM outside of the X.509 context. Derek has since indicated that I misunderstood his comment, although he has yet to rely to my question of what he meant by "trust semantics." I don't recall the reference to "an implementer or author or something" and it doesn't sound like the sort of language I use, so I'll pass on the last sentence in the paragraph above. >I'm happy to debate a generalized certificate theory here, or over a >beer. For the purposes of TAM, however, my opinions about >certificates, however interesting anyone finds them, are irrelevant. > >The relevance to TAM is solely in saying, "I want TAM for OpenPGP, >and here's why." I say that as an OpenPGP author, and as an >implementer of multi-format PKIs. Your statement certainly counts as a valid expression of interest, However, one of the problems we have in the IETF when dealing with a BoF is that we may see see interest expressed by multiple, independent constituencies. They may not be able to agree on what a WG would do, but they all like he idea of creating a WG so that they can pursue their notion of what needs to be done. Te cognizant Ad needs to decide if this will lead to a successful WG, or a protracted debate over definitions, requirements, etc. We are at that stage now. >I think that if TAM becomes X.509-only, that's fine, but it >shouldn't be chartered as a separate working group, it ought to be a >work item for PKIX. The whole reason for it being a separate WG >would be if it's broad enough to have appeal outside of PKIX. We agree. However, this is still an open question, relative to the criteria I noted above, i.e, it's not enough to have a group of folks who want to address TA management that is broader than the X.509 context. There has to be a coherent view of what TA management is, in this broader context, to give Tim Polk confidence that a newly chartered WG will generate usefu specs. >Mind you, if it's PKIX-only, I still want it and need it. I won't go >away, and it will give me reason to pay attention to PKIX again. >(The fact that I don't presently is because I think y'all do a fine >job without me. I trust you.) Thanks for the compliment. Steve From owner-ietf-trust-anchor Tue Aug 14 17:55: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 l7F0tdli069312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 17:55: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 l7F0td5B069311; Tue, 14 Aug 2007 17:55: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 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 l7F0tbm0069304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Aug 2007 17:55:38 -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 4450B3209C; Wed, 15 Aug 2007 01:55:36 +0100 (IST) Received: from [127.0.0.1] (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 l7F0tYh5021311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Aug 2007 01:55:34 +0100 Message-ID: <46C24F08.7040100@cs.tcd.ie> Date: Wed, 15 Aug 2007 01:55:36 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen Kent CC: ietf-trust-anchor@vpnc.org Subject: Re: Issue with the requirements document: PKIX-centric terminology References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> <46C0F999.7030702@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: 12599701 - 091419d28267 (trained as not-spam) 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, Let me try short-circuit a possible something here. I'm getting the impression that a lot of your argument is really directed to the goal of having the putative TAM work be added to the PKIX WG charter rather that be the subject of a new WG. (IMO not at all an unreasonable p-o-v, but neither is it definitively the best plan.) While that's basically the IESG's call, I think it may be easier to make progress on this list between now and Vancouver if we can get that card on the table (or else discover that I'm reading a tad too much into what you've been saying:-) So - is that what you believe or am I wrong? If I'm wrong, do you think that a new WG is most likely the way to go? (I take it from the attention you're paying that you do see value in the basic idea being progressed in some shape or form.) S. PS: I personally don't mind either way, other than having a slight bias towards shorter-lived WGs in general and the perhaps naive idea that the putative TAM WG could be a fine example of such. From owner-ietf-trust-anchor Tue Aug 14 19:28:16 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 l7F2SGcG076707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 19:28:16 -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 l7F2SGMr076704; Tue, 14 Aug 2007 19:28:16 -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 l7F2SFgc076691; Tue, 14 Aug 2007 19:28:16 -0700 (MST) (envelope-from cat@reptiles.org) Received: from skink.reptiles.org ([198.96.210.227] port=52151) by mailbox.reptiles.org([198.96.210.227] port=25) via TCP with esmtp (1813 bytes) (sender: ) (ident using UNIX) id for ; Tue, 14 Aug 2007 22:28:07 -0400 (EDT) (Smail-3.2.0.121 2005-Nov-17 #4 built 2006-Nov-28) Date: Tue, 14 Aug 2007 22:28:05 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@gecko.reptiles.org Reply-To: Cat Okita To: Stephen Kent cc: Thomas Hardjono , Paul Hoffman , ietf-trust-anchor@vpnc.org Subject: RE: Issue with the requirements document: PKIX-centric terminology In-Reply-To: Message-ID: <20070814222421.Y34125@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 Fri, 10 Aug 2007, Stephen Kent wrote: > I think we should make decisions about what work to do in the IETF based on > who participates in the IETF work, not based on who we believe may benefit. I think this is the attitude that leads many people to believe that the IETF is a pointless waste of time. My understanding was that the goals of the IETF include producing well considered and designed protocols that are a benefit to all, and readily used by all, not a group of inbred pedants intent only on self-gratification. 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 Aug 14 19:35: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 l7F2ZAfk077237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 19:35: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 l7F2ZAjm077236; Tue, 14 Aug 2007 19:35: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 mailbox.reptiles.org (mailbox.reptiles.org [198.96.210.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7F2Z92p077226; Tue, 14 Aug 2007 19:35:10 -0700 (MST) (envelope-from cat@reptiles.org) Received: from skink.reptiles.org ([198.96.210.227] port=53006) by mailbox.reptiles.org([198.96.210.227] port=25) via TCP with esmtp (2189 bytes) (sender: ) (ident using UNIX) id for ; Tue, 14 Aug 2007 22:33:16 -0400 (EDT) (Smail-3.2.0.121 2005-Nov-17 #4 built 2006-Nov-28) Date: Tue, 14 Aug 2007 22:33:15 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@gecko.reptiles.org Reply-To: Cat Okita To: Yoav Nir cc: Paul Hoffman , ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter In-Reply-To: <40F31377-6CFE-450C-9500-ED50163AD01A@checkpoint.com> Message-ID: <20070814223154.V34125@gecko.reptiles.org> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <26D8BDE7-D21D-4B85-97D5-08FF26EF76B9@checkpoint.com> <40F31377-6CFE-450C-9500-ED50163AD01A@checkpoint.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 Mon, 13 Aug 2007, Yoav Nir wrote: >> I believe that most users who have multiple TAAs could set an order for >> precedence to them. I also think writing software to act on the precedence >> is quite straightforward: the two rules are "only allow delete proposals >> from TAAs at the same level or higher as the TAA who added this TA" and "if >> a TA has been deleted, only allow it to be re-added by a TAA at the same >> level or higher than the one who deleted it". >> >> Does this simplification seem like a good one? > > I would rather have a system where each TAA manages the TAs that it has > added, with provisions for multiple additions and deletions. I don't think > precedence is a good simplification. I agree - precedence is a poor simplification, especially if we encounter cases where differing precedence is desired (eg: precedence for web trust varies according to the site being contacted). 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 Aug 14 23:51:29 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 l7F6pTCr098448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 23:51:29 -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 l7F6pTpM098447; Tue, 14 Aug 2007 23:51: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 michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7F6pQmH098439 for ; Tue, 14 Aug 2007 23:51:27 -0700 (MST) (envelope-from ynir@checkpoint.com) Received: from [172.31.21.12] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l7F6pPRL021059; Wed, 15 Aug 2007 09:51:25 +0300 (IDT) 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: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.com> Cc: Thomas Hardjono Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: Draft Charter Date: Wed, 15 Aug 2007 09:38:32 +0300 To: ietf-trust-anchor@vpnc.org X-Mailer: Apple Mail (2.752.3) Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Aug 14, 2007, at 2:48 AM, Thomas Hardjono wrote: > > With regards to the thread on multiple TA-Authorities (TAA), this > is why > I was a bit insistent earlier that we focus initially on the > Enterprise > environment (since its easier). > > Within the Enterprise there is typically a single TAA (eg. IT admin), > and she/he will be the entity doing the adding/deleting of all Trust > Anchors for all the machines & devices within the Enterprise. (PS. I'm > assuming here that commands to install/delete TAs will be > accompanied by > the appropriate source authentication). > > In the Consumer space, TA usage and management may have to be > application-driven. Meaning that if an organization (e.g. Bank, > SalesForce.com, etc) requires its TA to be present at the client > end-point before allowing a transaction, then the home-user will just > have to accept such installation (ie. press "Yes" at the dialog box). > If a Bank's TA is inadvertently deleted (eg. by a user, malware or > another TA), then the Bank will just have to install it again the next > time the user seeks to transact with the Bank. > > If a virus or malware succeeds in deleting or modifying TAs at a > consumer machine, well the consumer will simply have to (somehow) > install them back agaian (eg. from backup). > > /thomas/ I think what's typical for an Enterprise depends on the application. If we're talking about browsers, then I think it's perfectly acceptable to have two TAAs - one from the browser vendor (it shouldn't be my employer's task to tell me that Verisign has a new root CA certificate - that's Microsoft's job) and the other being the corporate IT department. That's why I think each TAA should be able to manage its own (and only its own) trust anchors. In your consumer space example, I again don't think SalesForce.com should be able to delete bankofamerica.com's trust anchor. Perhaps there should be exception, such as if Microsoft learns that the bankofamerica.com TA really belongs to a phishing company, but I think each TAA should manage its own as a general rule, and this should be enforced. From owner-ietf-trust-anchor Wed Aug 15 04:07: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 l7FB7Z32024442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2007 04:07: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 l7FB7Zdp024438; Wed, 15 Aug 2007 04:07: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 smtp1.su.se (smtp1.su.se [130.237.162.112]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7FB7V2c024422 for ; Wed, 15 Aug 2007 04:07:32 -0700 (MST) (envelope-from leifj@it.su.se) Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id DF9B274196; Wed, 15 Aug 2007 13:07:30 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13483-01-24; Wed, 15 Aug 2007 13:07:30 +0200 (CEST) Received: from [193.11.30.35] (dhcp-wavelan-vo-35.publik.su.se [193.11.30.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id C2DB0740AD; Wed, 15 Aug 2007 13:07:29 +0200 (CEST) Message-ID: <46C2DE82.50105@it.su.se> Date: Wed, 15 Aug 2007 13:07:46 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Stephen Kent CC: Stephen Farrell , ietf-trust-anchor@vpnc.org Subject: Re: Issue with the requirements document: PKIX-centric terminology References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> <46C0F999.7030702@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.02 tagged_above=-99 required=7 tests=[AWL=0.292, BAYES_00=-2.312] X-Spam-Level: Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > I thought we had a message exchange on the topic and agreed that SPKI > was out of scope. My concern is that we keep talking as though the > syntax of a cert is at the heart of this problem, which I think is > just plain wrong. That's why a document like RFC 4398 is irrelevant. > Defining a format for storing any form of cert in the DNS is trivial, > because the DNS is not making use of the content to make decisions. In > contrast many of the proposed TAM use cases DO need to pay attention > to the contents of TAs (whether they be certs or not), in order to > support meaningful TA management. > > Could you elaborate on one or two use cases where the content of the TA is essential.To me this is absolutely critical to figure out - if you are right there is a real risk that TAM won't be properly layered on top of things like X.509, SPKI, PGP. Cheers Leif From owner-ietf-trust-anchor Wed Aug 15 06:24: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 l7FDOKYp037548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2007 06:24: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 l7FDOKTd037547; Wed, 15 Aug 2007 06:24:20 -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 l7FDOGI8037540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Aug 2007 06:24:19 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l7FDO0l0013193; Wed, 15 Aug 2007 09:24:02 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id l7FDN4Na003962; Wed, 15 Aug 2007 09:23:05 -0400 (EDT) Message-ID: <46C2FE40.4040003@nist.gov> Date: Wed, 15 Aug 2007 09:23:12 -0400 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.4 (X11/20070620) MIME-Version: 1.0 To: Stephen Kent CC: ietf-trust-anchor@vpnc.org Subject: Re: Issue with the requirements document: PKIX-centric terminology References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen Kent wrote: > I keep saying that the format of what is being moved about is not > nearly so hard a problem as the semantics of what is being moved, but > either nobody believes me or nobody is listening. I can;t tell which > based on he responses :-). Steve, You can count me as one person who has heard and agrees with me, but who just hasn't posted a message to the list until now. I believe that I have heard a general consensus that the TAM protocol (or message syntax) needs to be able to specify more than just a list of trust anchors, but also constraints on the use of each trust anchor. Some of these constraints may apply equally to all TA types, such as the set of applications with with the TA may be used. However, as you have said, we need to allow for constraints that are format specific. For X.509, the most obvious constraints are the inputs to the path validation algorithm (name constraints, policy constraints, etc.). While, I am not very familiar with OpenPGP or SPKI, I would be very surprised if one could use the same syntax and semantics to describe constraints on the use of TAs that are intended for use with X.509 to describe constraints on the use of TAs that are intended for use with OpenPGP or SPKI. So, while it may be appropriate to have a syntax that allows for a single message to specify several different TA formats, I believe that there will need to be a separate effort to describe the syntax and semantics for specifying constraint information for each distinct TA format. Dave From owner-ietf-trust-anchor Wed Aug 15 13:24: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 l7FKONId080047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2007 13:24: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 l7FKONCE080046; Wed, 15 Aug 2007 13:24: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 smtp3.su.se (smtp3.su.se [130.237.93.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7FKOL4g080040 for ; Wed, 15 Aug 2007 13:24:22 -0700 (MST) (envelope-from leifj@it.su.se) Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 9FBF33BF89; Wed, 15 Aug 2007 22:24:20 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28151-02-8; Wed, 15 Aug 2007 22:24:20 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 705133BF81; Wed, 15 Aug 2007 22:24:15 +0200 (CEST) Message-ID: <46C360F7.7080409@it.su.se> Date: Wed, 15 Aug 2007 22:24:23 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David A. Cooper" CC: Stephen Kent , ietf-trust-anchor@vpnc.org Subject: Re: Issue with the requirements document: PKIX-centric terminology References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> <46C2FE40.4040003@nist.gov> In-Reply-To: <46C2FE40.4040003@nist.gov> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.275 tagged_above=-99 required=7 tests=[AWL=0.037, BAYES_00=-2.312] X-Spam-Level: Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David A. Cooper wrote: > > I believe that I have heard a general consensus that the TAM protocol > (or message syntax) needs to be able to specify more than just a list > of trust anchors, but also constraints on the use of each trust > anchor. Some of these constraints may apply equally to all TA types, > such as the set of applications with with the TA may be used. > However, as you have said, we need to allow for constraints that are > format specific. For X.509, the most obvious constraints are the > inputs to the path validation algorithm (name constraints, policy I don't understand that statement. The constraints you mention are extensions to X.509 certificates which undoubtedly are important when a PKIX implementation _uses_ a TA (eg part of path construction or path validation) but I don't see why this information is needed when storing or retrieving a TA from a TA store. I'm implicitly assuming that the number of TAs for any given application won't be so large so as to require more than a list-all type-of access to the TA store. Cheers Leif From owner-ietf-trust-anchor Wed Aug 15 13:46: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 l7FKkJN3081652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2007 13:46: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 l7FKkJ24081651; Wed, 15 Aug 2007 13:46: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 smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7FKkGWg081643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Aug 2007 13:46:19 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l7FKk52a014183; Wed, 15 Aug 2007 16:46:05 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id l7FKjc8c002926; Wed, 15 Aug 2007 16:45:38 -0400 (EDT) Message-ID: <46C365FA.1030706@nist.gov> Date: Wed, 15 Aug 2007 16:45:46 -0400 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.4 (X11/20070620) MIME-Version: 1.0 To: Leif Johansson CC: ietf-trust-anchor@vpnc.org Subject: Re: Issue with the requirements document: PKIX-centric terminology References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> <46C2FE40.4040003@nist.gov> <46C360F7.7080409@it.su.se> In-Reply-To: <46C360F7.7080409@it.su.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Leif, I am not referring to certificate extensions. Section 6.1.1 of 3280bis lists the following inputs to the path validation algorithm in addition to the trust anchor, prospective certification path, and current date/time: user-initial-policy-set, initial-policy-mapping-inhibit, initial-explicit-policy, initial-any-policy-inhibit, initial-permitted-subtrees, and initial-excluded-subtrees. A TAA may wish to specify values for these inputs. For example, the TAA may say that TA1 may be used with application X, but path validation should be performed with initial-explicit-policy=TRUE and user-initial-policy-set = {p1, p2}. This may be done because TA1 issues certificates at different assurance levels, and certificates issued under some of these assurance levels (e.g., p3) are not considered acceptable for use with application X. This has nothing to do with the number of TAs. Even if there is only a single TA, the TAA may wish to specify constraints so that not all certificates issued by the TA will be considered valid for use with an application. Dave Leif Johansson wrote: > David A. Cooper wrote: > > > >> I believe that I have heard a general consensus that the TAM protocol >> (or message syntax) needs to be able to specify more than just a list >> of trust anchors, but also constraints on the use of each trust >> anchor. Some of these constraints may apply equally to all TA types, >> such as the set of applications with with the TA may be used. >> However, as you have said, we need to allow for constraints that are >> format specific. For X.509, the most obvious constraints are the >> inputs to the path validation algorithm (name constraints, policy >> > I don't understand that statement. The constraints you mention are > extensions > to X.509 certificates which undoubtedly are important when a PKIX > implementation > _uses_ a TA (eg part of path construction or path validation) but I > don't see why > this information is needed when storing or retrieving a TA from a TA store. > > I'm implicitly assuming that the number of TAs for any given application > won't > be so large so as to require more than a list-all type-of access to the > TA store. > > Cheers Leif > > From owner-ietf-trust-anchor Wed Aug 15 13:57: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 l7FKvOqC082763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2007 13:57: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 l7FKvO6n082762; Wed, 15 Aug 2007 13:57: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 smtp3.su.se (smtp3.su.se [130.237.93.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7FKvM6K082753 for ; Wed, 15 Aug 2007 13:57:23 -0700 (MST) (envelope-from leifj@it.su.se) Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id A11843BF12; Wed, 15 Aug 2007 22:57:22 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32000-01-55; Wed, 15 Aug 2007 22:57:22 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 340593BE63; Wed, 15 Aug 2007 22:57:17 +0200 (CEST) Message-ID: <46C368B1.8000605@it.su.se> Date: Wed, 15 Aug 2007 22:57:21 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David A. Cooper" CC: ietf-trust-anchor@vpnc.org Subject: Re: Issue with the requirements document: PKIX-centric terminology References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> <46C2FE40.4040003@nist.gov> <46C360F7.7080409@it.su.se> <46C365FA.1030706@nist.gov> In-Reply-To: <46C365FA.1030706@nist.gov> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.275 tagged_above=-99 required=7 tests=[AWL=0.037, BAYES_00=-2.312] X-Spam-Level: Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David A. Cooper wrote: > Leif, > > I am not referring to certificate extensions. Section 6.1.1 of > 3280bis lists the following inputs to the path validation algorithm in > addition to the trust anchor, prospective certification path, and > current date/time: user-initial-policy-set, > initial-policy-mapping-inhibit, initial-explicit-policy, > initial-any-policy-inhibit, initial-permitted-subtrees, and > initial-excluded-subtrees. A TAA may wish to specify values for these > inputs. For example, the TAA may say that TA1 may be used with > application X, but path validation should be performed with > initial-explicit-policy=TRUE and user-initial-policy-set = {p1, p2}. > This may be done because TA1 issues certificates at different > assurance levels, and certificates issued under some of these > assurance levels (e.g., p3) are not considered acceptable for use with > application X. > > This has nothing to do with the number of TAs. Even if there is only > a single TA, the TAA may wish to specify constraints so that not all > certificates issued by the TA will be considered valid for use with an > application. > > Dave Thanks for clearing that up. It makes absolute sense and it sounds like a reasonable case for typed data associated with TAs in the store. It does not sound like an argument that the TA store needs to be aware of the type of TA stored beyond an understanding of which associated data types are "valid" for a given TA type (and that is only for UI validation purposes so that you don't accidentally stick a PKIX policy oid next to a PGP cert and expect things to make sense). Cheers Leif >> >> >> > From owner-ietf-trust-anchor Thu Aug 16 04:08: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 l7GB8tGH081431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 04:08: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 l7GB8tNr081430; Thu, 16 Aug 2007 04:08: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7GB8rCL081423 for ; Thu, 16 Aug 2007 04:08:54 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 22794 invoked from network); 16 Aug 2007 11:05:54 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;16 Aug 2007 11:05:54 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 16 Aug 2007 11:05:54 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Aug 2007 07:08:52 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31D4EC@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: Issue with the requirements document: PKIX-centric terminolog y Date: Thu, 16 Aug 2007 07:08:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DFF5.D0AADFA8" 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_01C7DFF5.D0AADFA8 Content-Type: text/plain > > Leif, > > I am not referring to certificate extensions. Section 6.1.1 > of 3280bis lists the following inputs to the path validation > algorithm in addition to the trust anchor, prospective > certification path, and current > date/time: user-initial-policy-set, > initial-policy-mapping-inhibit, initial-explicit-policy, > initial-any-policy-inhibit, initial-permitted-subtrees, and > initial-excluded-subtrees. A TAA may wish to specify values > for these inputs. For example, the TAA may say that TA1 may > be used with application X, but path validation should be > performed with initial-explicit-policy=TRUE and > user-initial-policy-set = {p1, p2}. This may be done because > TA1 issues certificates at different assurance levels, and > certificates issued under some of these assurance levels > (e.g., p3) are not considered acceptable for use with application X. > > This has nothing to do with the number of TAs. Even if there > is only a single TA, the TAA may wish to specify constraints > so that not all certificates issued by the TA will be > considered valid for use with an application. > > Dave It will take a while for implementations to support the inputs that are new to 3280bis. We should make sure the TA mgmt mechanisms defined by the group can be used without requiring changes to TA store consumers. ------_=_NextPart_001_01C7DFF5.D0AADFA8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Issue with the requirements document: PKIX-centric = terminology

>
> Leif,
>
> I am not referring to certificate = extensions.  Section 6.1.1
> of 3280bis lists the following inputs to the = path validation
> algorithm in addition to the trust anchor, = prospective
> certification path, and current
> date/time:  user-initial-policy-set, =
> initial-policy-mapping-inhibit, = initial-explicit-policy,
> initial-any-policy-inhibit, = initial-permitted-subtrees, and
> initial-excluded-subtrees.  A TAA may wish = to specify values
> for these inputs.  For example, the TAA = may say that TA1 may
> be used with application X, but path validation = should be
> performed with initial-explicit-policy=3DTRUE = and
> user-initial-policy-set =3D {p1, p2}.  = This may be done because
> TA1 issues certificates at different assurance = levels, and
> certificates issued under some of these = assurance levels
> (e.g., p3) are not considered acceptable for = use with application X.
>
> This has nothing to do with the number of = TAs.  Even if there
> is only a single TA, the TAA may wish to = specify constraints
> so that not all certificates issued by the TA = will be
> considered valid for use with an = application.
>
> Dave

It will take a while for implementations to support = the inputs that are new to 3280bis.  We should make sure the TA = mgmt mechanisms defined by the group can be used without requiring = changes to TA store consumers.

------_=_NextPart_001_01C7DFF5.D0AADFA8-- From owner-ietf-trust-anchor Thu Aug 16 05:31: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 l7GCVjjA094714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 05:31: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 l7GCVjNS094713; Thu, 16 Aug 2007 05:31: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 rediris.es (chico.rediris.es [130.206.1.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7GCVhbf094703 for ; Thu, 16 Aug 2007 05:31:44 -0700 (MST) (envelope-from diego.lopez@rediris.es) Received: from [10.8.0.38] (login.rediris.es [130.206.1.21]) by chico.rediris.es (Postfix) with ESMTP id 215CD45228; Thu, 16 Aug 2007 14:31:42 +0200 (CEST) In-Reply-To: <00e101c7d824$51c97d10$0301a8c0@Wylie> References: <00e101c7d824$51c97d10$0301a8c0@Wylie> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4ACC34F7-7A3D-41A6-93A1-68EEF90C4AEB@rediris.es> Cc: Content-Transfer-Encoding: 7bit From: "Diego R. Lopez" Subject: Re: TAM BOF Minutes Date: Wed, 8 Aug 2007 20:05:42 +0200 To: turners@ieca.com X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, On 6 Aug 2007, at 14:21, Turner, Sean P. wrote: > Polling by co-chairs to determine support, results are as follows: > - About half the room in favor of the IETF working on the idea (no > hands > against) > - 20 to actively work the topic > - Another 12 to review > - 10 to implement (if its of good quality) > > Will take the topic back to the mailing list. > Need to get a better understanding of what "this" is (scope). > Will use the mailing list to do scoping, refine questions, > build/recruit/demonstrate more constituency. > Monitor the list to see how the group is progressing. The academic network community (in particular, in Europe) is very much interested in the results of this group. We are deploying an infrastructure for the interconnection of federated identity systems, and that will obviously require the dynamic management of trust anchors. Furthermore, we are running a trust anchor repository (TACAR: http://www.tacar.org/) currently in use by the global Grid community and several other research projects, that I think would be an excellent demonstrator for any future result. Best regards, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Red.es - RedIRIS The Spanish NREN e-mail: diego.lopez@rediris.es jid: drlopez@im.rediris.es Tel: +34 955 056 621 Mobile: +34 669 898 094 ----------------------------------------- From owner-ietf-trust-anchor Thu Aug 16 08:32: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 l7GFWHsN021168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 08:32: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 l7GFWHZA021166; Thu, 16 Aug 2007 08: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7GFWGFv021154 for ; Thu, 16 Aug 2007 08:32:16 -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 1ILhKZ-0002rI-51; Thu, 16 Aug 2007 11:32:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.com> References: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.com> Date: Thu, 16 Aug 2007 11:32:21 -0400 To: Yoav Nir From: Stephen Kent Subject: Re: Draft Charter Cc: ietf-trust-anchor@vpnc.org, Thomas Hardjono 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 think what's typical for an Enterprise depends on the application. >If we're talking about browsers, then I think it's perfectly >acceptable to have two TAAs - one from the browser vendor (it >shouldn't be my employer's task to tell me that Verisign has a new >root CA certificate - that's Microsoft's job) and the other being >the corporate IT department. That's why I think each TAA should be >able to manage its own (and only its own) trust anchors. Even in this case I can see problems, I think several folks have noted that the default TAs currently installed in browsers ought to be subject to local management, especially deletion! So, as a browser user in an enterprise context, I would not want a TAA installed by MS (or, in my case, Apple) to be able to maintain the presence of TAs even if my IT dept wants to remove them. >In your consumer space example, I again don't think SalesForce.com >should be able to delete bankofamerica.com's trust anchor. Perhaps >there should be exception, such as if Microsoft learns that the >bankofamerica.com TA really belongs to a phishing company, but I >think each TAA should manage its own as a general rule, and this >should be enforced. This example seems to suggest that a home user might have lots of TAAs, not just a lot of TAs. I'd worry that the result would be unmanageable for most home users. Did I misunderstand your example? Steve From owner-ietf-trust-anchor Thu Aug 16 08:32: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 l7GFWHY8021169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 08: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 l7GFWHSq021167; Thu, 16 Aug 2007 08: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7GFWFlx021152 for ; Thu, 16 Aug 2007 08:32:16 -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 1ILhKY-0002rI-62; Thu, 16 Aug 2007 11:32:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <46C24F08.7040100@cs.tcd.ie> References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> <46C0F999.7030702@cs.tcd.ie> <46C24F08.7040100@cs.tcd.ie> Date: Thu, 16 Aug 2007 11:31:08 -0400 To: Stephen Farrell From: Stephen Kent Subject: Re: Issue with the requirements document: PKIX-centric terminology 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: Steve, First, I don't play cards, so I have none to put on the table :-). I started contributing to this list on the assumption that we might need a TAM protocol that is broader than the X.509 context, and thus a new WG was appropriate. We have never pursed development of a protocol like this in PKIX because nobody stepped forward to propose such work. If they had, and if there were sufficient interest, we would have pursued it in PKIX. I also am familiar with projects that have developed this sort of capability in the past; the resulting protocol was focused only on X.509 certs and raw keys. Those efforts had a fairly clear idea of their requirements, though getting agreement on them was very tough, even in a much narrower context. What I have seen so far on the list is just what I stated in a previous message: two or more constituencies, each with a different notion of what TAM means. There seems to be some desire to create a new WG to see if it can develop a protocol that will accommodate these possibly divergent goals. Personally I am not in favor of chartering such WGs, because they also can drag on without progress as the different constituencies continue to wrangle over what the problem is. Let me give an example. You have argued that we ought not spend more time trying to nail down a more precise definition of a TA, but rather move on to other topics for the charter. I worry that the difficulty we see in agreeing on a definition for TA is indicative of the problem I noted above. If folks have different ideas of what a TA is, then maybe they can agree on fuzzy language for what a TAM protocol should do, given the ambiguity created by a lack of a precise TA definition. One might be able to charter a WG this way, because each constituency reads the fuzzy words in the charter differently, and is convinced that their goals can be addressed by the WG. Only later do the conflicting views become apparent and stymie progress. I don't agree with this approach to creating a WG (even a short-lived one of the sort you favor), in any area. In my opinion, the repeated references to the need to define tags to accommodate different types of certs (as well as raw keys) suggests that folks either have very modest goals for this effort, of they have not focused on what several of us have discussed as the harder problems, e.g., defining a policy language to express TAA constraints, accommodating multiple TAAs for a single device, describing how the semantics extent in certs like X.509 will be accommodated by a protocol that purports to be cert-type independent, etc. Folks who have communicated with me off list have more clearly articulated notions of what they want in TAM, but they have focused exclusively on the X.509 context. If the TAM list doesn't manage to develop consensus on its goals and definitions, then yes, I would suggest to the folks with whom I've spoken that hey come to PKIX and ask that WG to adopt a work item that does address their needs. Hope this answers you question. Steve From owner-ietf-trust-anchor Thu Aug 16 08:51: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 l7GFpNLI022874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 08:51: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 l7GFpNmk022873; Thu, 16 Aug 2007 08:51: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 mailbox.reptiles.org (mail.reptiles.org [198.96.210.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7GFpMuE022867 for ; Thu, 16 Aug 2007 08:51:23 -0700 (MST) (envelope-from cat@reptiles.org) Received: from mail.reptiles.org ([198.96.210.227] port=55563) by mailbox.reptiles.org([198.96.210.227] port=25) via TCP with esmtp (3254 bytes) (sender: ) (ident using UNIX) id for ; Thu, 16 Aug 2007 11:49:40 -0400 (EDT) (Smail-3.2.0.121 2005-Nov-17 #4 built 2006-Nov-28) Date: Thu, 16 Aug 2007 11:49:38 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@gecko.reptiles.org Reply-To: Cat Okita To: Stephen Kent cc: Yoav Nir , ietf-trust-anchor@vpnc.org, Thomas Hardjono Subject: Re: Draft Charter In-Reply-To: Message-ID: <20070816114559.A34125@gecko.reptiles.org> References: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.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 Thu, 16 Aug 2007, Stephen Kent wrote: >> I think what's typical for an Enterprise depends on the application. If >> we're talking about browsers, then I think it's perfectly acceptable to >> have two TAAs - one from the browser vendor (it shouldn't be my employer's >> task to tell me that Verisign has a new root CA certificate - that's >> Microsoft's job) and the other being the corporate IT department. That's >> why I think each TAA should be able to manage its own (and only its own) >> trust anchors. > > Even in this case I can see problems, I think several folks have noted that > the default TAs currently installed in browsers ought to be subject to local > management, especially deletion! So, as a browser user in an enterprise > context, I would not want a TAA installed by MS (or, in my case, Apple) to be > able to maintain the presence of TAs even if my IT dept wants to remove them. Agreed - we've already discussed the current problem of unwanted TAs being silently put back into browsers. It's also much easier to move from a point of less privledge to granting more, rather than the other way around. >> In your consumer space example, I again don't think SalesForce.com should >> be able to delete bankofamerica.com's trust anchor. Perhaps there should be >> exception, such as if Microsoft learns that the bankofamerica.com TA really >> belongs to a phishing company, but I think each TAA should manage its own >> as a general rule, and this should be enforced. > > This example seems to suggest that a home user might have lots of TAAs, not > just a lot of TAs. I'd worry that the result would be unmanageable for most > home users. Did I misunderstand your example? If I recall correctly, the expectation was that home users might have lots of TAAs, but the likely situation would be that they'd take a default trust set, and only dive down into the fine bits in a limited number of circumstances (namely users like us...) 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 Aug 16 09:21: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 l7GGLKmn025308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 09:21: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 l7GGLJNk025307; Thu, 16 Aug 2007 09:21: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 l7GGLIWq025301 for ; Thu, 16 Aug 2007 09:21: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 1ILi60-0004tu-3M; Thu, 16 Aug 2007 12:21:16 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070814222421.Y34125@gecko.reptiles.org> References: <20070814222421.Y34125@gecko.reptiles.org> Date: Thu, 16 Aug 2007 12:21:22 -0400 To: Cat Okita From: Stephen Kent Subject: RE: Issue with the requirements document: PKIX-centric terminology 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:28 PM -0400 8/14/07, Cat Okita wrote: >On Fri, 10 Aug 2007, Stephen Kent wrote: >>I think we should make decisions about what work to do in the IETF >>based on who participates in the IETF work, not based on who we >>believe may benefit. > >I think this is the attitude that leads many people to believe that the >IETF is a pointless waste of time. > >My understanding was that the goals of the IETF include producing well >considered and designed protocols that are a benefit to all, and readily >used by all, not a group of inbred pedants intent only on self-gratification. > >cheers! A great many folks who are not part of the IETF process benefit from the standards we generate. However, unless folks actively participate in the process, there is no way to ensure that external constituencies are well represented. Moreover, someone who claims to represent such a constituency is not intrinsically credible. Thus when we decide the scope of work for a WG, it is common to make decisions based on who chooses to contribute, and to focus on the IETF context. For example, the IETF does not develop security standards targeting the LAN environment unless the IEEE asks us to do so. A closer to home example arises in the message Thomas sent recently. He gave several good examples of uses cases for TAM. Included in his list was the TCM context (use case #2) and mobile phones (UC #4). The TCM case might be problematic because the TCG defines how TCMs work and TCG is a closed group (one has to pay a fee and sign an HDA to be a member.) So, only if all of the relevant documents from TCG are publicly available could we reasonably address this use case. (Having Thomas as a contributor helps since he is the editor of one or more TCG documents that deal with this area!) The mobile phone use case is likely to be more problematic, as I believe there are no public standards for ALL mobile phones re managing signed code validation, etc. It may not make sense for us to try to address problems in areas where the IETF has no standing, where there are no public standards, etc. Steve From owner-ietf-trust-anchor Thu Aug 16 10:58: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 l7GHwsQb038167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 10:58: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 l7GHwsDI038166; Thu, 16 Aug 2007 10:58: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 l7GHwp0g038155 for ; Thu, 16 Aug 2007 10:58:52 -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 1ILjcQ-0005qb-54; Thu, 16 Aug 2007 13:58:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070816114559.A34125@gecko.reptiles.org> References: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.com> <20070816114559.A34125@gecko.reptiles.org> Date: Thu, 16 Aug 2007 12:25:10 -0400 To: Cat Okita From: Stephen Kent Subject: Re: Draft Charter 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:49 AM -0400 8/16/07, Cat Okita wrote: >>... >>This example seems to suggest that a home user might have lots of >>TAAs, not just a lot of TAs. I'd worry that the result would be >>unmanageable for most home users. Did I misunderstand your example? > >If I recall correctly, the expectation was that home users might >have lots of TAAs, but the likely situation would be that they'd >take a >default trust set, and only dive down into the fine bits in a limited >number of circumstances (namely users like us...) I'm not sure that we agree on this. The current situation is that there is one TAA (typically the browser vendor) and a lot of TAs. One might say that a browser vendor would install all the current TAs as TAAs, but there is no a priori reason to assume that model. Steve From owner-ietf-trust-anchor Thu Aug 16 11:30: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 l7GIU8mI041119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 11:30: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 l7GIU8V2041118; Thu, 16 Aug 2007 11:30: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 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 l7GIU7Yo041109 for ; Thu, 16 Aug 2007 11:30:07 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 62635 invoked from network); 16 Aug 2007 18:30:01 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.36.91 with login) by smtp108.biz.mail.re2.yahoo.com with SMTP; 16 Aug 2007 18:30:01 -0000 X-YMail-OSG: .z6rLJYVM1lJ7lK2aBc0_VOAWRYXESgi6N1UiXjtI35wpMsMPzSXpup1pCeDUHeWK12I0Gp0yIzXdznZcRe3aPozkih256GK7WVvMRTmwv27d3jW7Y7woviOxQG65FNT376xEVTlusDqplhV4GsKf9feRsm5W7W8Dg-- From: "Turner, Sean P." To: "'Stephen Kent'" , "'Cat Okita'" Cc: References: <20070814222421.Y34125@gecko.reptiles.org> Subject: RE: Issue with the requirements document: PKIX-centric terminology Date: Thu, 16 Aug 2007 14:18:45 -0400 Organization: IECA, Inc. Message-ID: <00f701c7e031$e24dd740$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcfgKE95olWcUmE8S8O3BoBX9ywdnAABzSTA 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: Thursday, August 16, 2007 12:21 PM >To: Cat Okita >Cc: ietf-trust-anchor@vpnc.org >Subject: RE: Issue with the requirements document: >PKIX-centric terminology > > >At 10:28 PM -0400 8/14/07, Cat Okita wrote: >>On Fri, 10 Aug 2007, Stephen Kent wrote: >>>I think we should make decisions about what work to do in the IETF >>>based on who participates in the IETF work, not based on who we >>>believe may benefit. >> >>I think this is the attitude that leads many people to >believe that the >>IETF is a pointless waste of time. >> >>My understanding was that the goals of the IETF include >producing well >>considered and designed protocols that are a benefit to all, and >>readily used by all, not a group of inbred pedants intent >only on self-gratification. >> >>cheers! > >A great many folks who are not part of the IETF process >benefit from the standards we generate. However, unless folks >actively participate in the process, there is no way to ensure >that external constituencies are well represented. Moreover, >someone who claims to represent such a constituency is not >intrinsically credible. Thus when we decide the scope of work >for a WG, it is common to make decisions based on who chooses >to contribute, and to focus on the IETF context. For example, >the IETF does not develop security standards targeting the LAN >environment unless the IEEE asks us to do so. > >A closer to home example arises in the message Thomas sent recently. >He gave several good examples of uses cases for TAM. Included >in his list was the TCM context (use case #2) and mobile >phones (UC #4). >The TCM case might be problematic because the TCG defines how >TCMs work and TCG is a closed group (one has to pay a fee and >sign an HDA to be a member.) So, only if all of the relevant >documents from TCG are publicly available could we reasonably >address this use case. >(Having Thomas as a contributor helps since he is the editor >of one or more TCG documents that deal with this area!) The >mobile phone use case is likely to be more problematic, as I >believe there are no public standards for ALL mobile phones re >managing signed code validation, etc. It may not make sense >for us to try to address problems in areas where the IETF has >no standing, where there are no public standards, etc. > >Steve Steve, If we don't include their documents as a normative reference does this still hold true? We don't expect everybody that might use TAM deliverables to have publiclly available documents for their architectures, etc. We do expect and want people to come and contribute to the work - but the oneous is on them to see that it supports their use cases. spt From owner-ietf-trust-anchor Thu Aug 16 11:52:29 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 l7GIqT6q043103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 11:52:29 -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 l7GIqTce043102; Thu, 16 Aug 2007 11:52: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 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 l7GIqS8w043095 for ; Thu, 16 Aug 2007 11:52:28 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 67935 invoked from network); 16 Aug 2007 18:52:22 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.36.91 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 16 Aug 2007 18:52:22 -0000 X-YMail-OSG: T6q6SzoVM1nZxzrBJVc2DHkyhV5oBizhwx0RFA7IiAkhHQ0IVxD3TvNsVmU1_x__J9GOfXnIL5fP5to9RNv7Iw7dXch7x0w0lk69g1HXDfBh7jVeyqMG4BJCffZ9Wyr7xjcc1oe6oeGIpPI- From: "Turner, Sean P." To: References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C87908C9C5FC@EXVS01.ex.dslextreme.net> Subject: RE: Draft Charter Date: Thu, 16 Aug 2007 14:41:06 -0400 Organization: IECA, Inc. Message-ID: <00f801c7e035$01bb9e70$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <82D5657AE1F54347A734BDD33637C87908C9C5FC@EXVS01.ex.dslextreme.net> Thread-Index: AcfbikY5o6WD6Zc5T5G/BbaIAISlcwAJsl/AASCKZrA= Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (sorry I'm jumping back to this) I think we should add the following as the first sentence: "A trust anchor is an established point of trust, which is usually based on the authority of some person, office or organization." [Shirey] I think we should do this because we jumped right in to how it's used not what it is. I used Rob's definition because I think it hit the mark. (I think) The rest of the argument about the TA definition is then based on the context in which you want to use the TA. As the basis of trust for a PKI, the Relying Party (RP) uses the TA to verify signatures on public key certificates. As the basis of trust for object X (which happens to be directly signed by a TA), the RP uses the TA to verify the signatures on object X. If we added the first sentence and modified what was below to: "In a PKI context, a relying party uses a trust anchor to verify the signature on the first certificate in a certification path or a CRL signed directly by the TA. In other contexts, a relying party uses a trust anchor directly to verify the signature on a signed object when no certification path is involved." ? spt [Shirey] Shirey, R., "Internet Security Glossary, Version 2", work-in-progress, November 2006. ________________________________ From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Santosh Chokhani Sent: Friday, August 10, 2007 8:47 PM To: Stephen Kent Cc: ietf-trust-anchor@vpnc.org Subject: RE: Draft Charter Steve, Sounds good. ________________________________ From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, August 10, 2007 3:58 PM To: Santosh Chokhani Cc: ietf-trust-anchor@vpnc.org Subject: RE: Draft Charter At 12:26 PM -0700 8/10/07, Santosh Chokhani wrote: Steve, Would the following do? slightly re-worded, to reflect the notion that a TA consists of both a public key and associated info, and that one verifies a signature with a TA, vs. signing an object with a TA: "A relying party uses a trust anchor to verify the signature on the first certificate in a certification path, or is used to directly verify the signature on a signed object when no certification path is involved." From owner-ietf-trust-anchor Thu Aug 16 11:54: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 l7GIsu0r043325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 11:54: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 l7GIsu8U043324; Thu, 16 Aug 2007 11:54: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 smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7GIsqJI043306 for ; Thu, 16 Aug 2007 11:54:55 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 86717 invoked from network); 16 Aug 2007 18:54:52 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.36.91 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 16 Aug 2007 18:54:52 -0000 X-YMail-OSG: Wla9A7AVM1kH8GZrBiXvo.XsacUScWCef46RNofKN6acG1U9aspL3KwskuyX4ziCTs1WY5PmM_U1fyoqIZWa3pAWAACqSI2Zz3fwlRdAoa6gZ_.c9DM- From: "Turner, Sean P." To: "'Paul Hoffman'" , References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> Subject: RE: Draft Charter Date: Thu, 16 Aug 2007 14:43:36 -0400 Organization: IECA, Inc. Message-ID: <00fe01c7e035$5af40ae0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcfbXuBOTXdrCyk+Svu2WCL+/VSDgAE1lrng Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Draft 02 of the charter captures these, which I will distribute after some more discussion on the TA definition. >-----Original Message----- >From: owner-ietf-trust-anchor@mail.vpnc.org >[mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of >Paul Hoffman >Sent: Friday, August 10, 2007 10:51 AM >To: ietf-trust-anchor@vpnc.org >Subject: Re: Draft Charter > > >At 6:55 PM -0400 8/9/07, Turner, Sean P. wrote: >>Strawman charter for trust anchor management (tam) BoF >> >>Version: 01, July 9th 2007 >> >>Chair(s) >> >>TBD >> >>Security Area Director(s): >> >>- Tim Polk >>- Sam Hartman >> >>Security Area Advisor: >> >>TBD >> >>Mailing Lists: >> >>General Discussion: ietf-trust-anchor@vpnc.org To Subscribe: >>http://www.vpnc.org/ietf-trust-anchor/ >>Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/ >> >>Description of Working Group: >> >>The need for a standard protocol for trust anchor management has been >>recognized for some time. Many groups within the IETF, >including PKIX, >>Kerberos, TLS and SIDR have a dependency on trust anchors, >yet provide >>no generic mechanism for the their management. > >Editorial nit: a comma is needed after "SIDR". > >> >> >>A trust anchor is a public key and associated data used by a relying >>party to begin the process of validating a signature on a >signed object. >>Associated data >>is used to define the scope of the use of the trust anchor for >>validating signatures; for example, associated data might limit the >>types of identifiers in certificates that a trust anchor is >allowed to validate. >> >>Despite the wide-spread use of trust anchors, there is no standard >>means for managing these security-critical data. This Working Group >>will develop a specification to fill this gap. >> >>The initial problem statement for this work is to be based on: >> >>- draft-wallace-ta-mgmt-problem-statement >> >>The scope of the work is to include: >> >><> > >Chicago is now in the past; elide that. > >>- Supporting a single trust anchor administrator, such as in a typical >> enterprise, who may be administering multiple trust >anchors in her domain, >> where those trust anchors can be either local or "foreign" >>- Supporting multiple trust anchor administrators, such as is >typical for home >> users >>- Supporting devices with limited or no user interface that >may or may >>not have >> connected to the Internet > >Some of the questions at the mic made it clear that people had >issues with user interface. It might be better to separate >that out into two bullet items: > >- Supporting systems with limited or no user interface > >- Supporting devices that may or many not be connected to the >Internet at the time of management > >> >>The following are out of scope of this work: >> >><> >>- TBD > >I think this is non-controversial for out-of-scope: > >- Management of non-anchor signature validation objects such >as intermediate certificates in a validation path. > >This might be more controversial, but should be considered as >out-of-scope: > >- Mandating whether the recipient of trust anchors from a >trust anchor manager will use those anchors > >> >>The deliverables will be: >> >>- An informational problem statement/requirements specification >> for a trust anchor management protocol >>- A standards track trust anchor management protocol >> specification >> >>Goals and Milestones: >> >>+6 months WG last call on problem >statement/requirements >>+9 months Adoption of WG draft protocol spec. >>+15 months WG last call for protocol spec. >> >> > >--Paul Hoffman, Director >--VPN Consortium > From owner-ietf-trust-anchor Thu Aug 16 11:53: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 l7GIrruu043239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 11:53: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 l7GIrrBG043238; Thu, 16 Aug 2007 11:53: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 smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7GIrqp8043223 for ; Thu, 16 Aug 2007 11:53:52 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 7053 invoked from network); 16 Aug 2007 18:53:51 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.36.91 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 16 Aug 2007 18:53:51 -0000 X-YMail-OSG: .dQa2rwVM1kSMr2GEI9fzE2Y.Esvgh_tEa7e4JVYHD0vz07DMBWE6N3_4F1EurUo26f_a1HWvA-- From: "Turner, Sean P." To: "'Stephen Kent'" , "'Paul Hoffman'" Cc: References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> Subject: RE: Draft Charter Date: Thu, 16 Aug 2007 14:42:35 -0400 Organization: IECA, Inc. Message-ID: <00f901c7e035$369d1060$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FA_01C7E013.AF8B7060" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcfbjuIwRI6GJ3wxQ9KrbP/Fzz2MzwEpjHog 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_000_00FA_01C7E013.AF8B7060 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Working on draft #2 of the charter and captured these. _____ From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, August 10, 2007 4:42 PM To: Paul Hoffman Cc: turners@ieca.com; ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter At 1:21 PM -0700 8/10/07, Paul Hoffman wrote: ... the TAA. - Supporting multiple trust anchor administrators, such as is typical for home users Why do we believe it is common for a home user to need multiple TA administrators? I would be happy if we swapped "individual" for "home". If needed, we can add text such as "For example, they may want their employers and their banks to act as trust anchor administrators." Ah, I see your point. If I can appropriately constrain the impact of what a TAA can do, I can safely let others be TAAs for my machine. That seems right for my home machine, but for a company-owned machine the roles probably are reversed, i.e., the employer is in charge and will allow the employee limited control over TAs. - Supporting devices with limited or no user interface that may or may not have connectivity to the Internet a simple typo fix, but if a deliverable is a TA management protocol, then why do we worry about devices that have no Internet connectivity? Protocols do not require Internet connectivity. End-to-end email is a good example of that. Good point. We may want to define protocols that can use staged delivery, even if there is no network involved. If that's the intent, the bullet could be a bit clearer, e.g., if we want to define protocols that work even if we deliver messages via a USB token from a source to a destination. However, I note that a protocol of that sort is likely to be more complex than one that assumes use of lower layer network protocols, even staged delivery ones. Steve ------=_NextPart_000_00FA_01C7E013.AF8B7060 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: Draft Charter
Working on draft #2 of the charter and captured = these.

From: Stephen Kent = [mailto:kent@bbn.com]=20
Sent: Friday, August 10, 2007 4:42 PM
To: Paul=20 Hoffman
Cc: turners@ieca.com;=20 ietf-trust-anchor@vpnc.org
Subject: Re: Draft=20 Charter

At 1:21 PM -0700 8/10/07, Paul Hoffman wrote:
... the TAA.

- = Supporting multiple=20 trust anchor administrators, such as is typical for = home
 =20 users

Why do we = believe it=20 is common for a home user to need multiple TA=20 administrators?

I would be happy if we swapped = "individual"=20 for "home". If needed, we can add text such as "For example, they = may want=20 their employers and their banks to act as trust anchor=20 administrators."

Ah, I see your point. If I can appropriately constrain the impact = of what=20 a TAA can do, I can safely let others be TAAs for my machine. That = seems right=20 for my home machine, but for a company-owned machine the roles = probably are=20 reversed, i.e., the employer is in charge and will allow the employee = limited=20 control over TAs.


- = Supporting devices=20 with limited or no user interface that may or may not have=20 connectivity to the Internet

a simple typo fix, but if a = deliverable is=20 a TA management protocol, then why do we worry about = devices that=20 have no Internet connectivity?

Protocols do not require Internet=20 connectivity. End-to-end email is a good example of = that.

Good point.  We may want to define protocols that can use = staged=20 delivery, even if there is no network involved.  If that's the = intent,=20 the bullet could be a bit clearer, e.g., if we want to define = protocols that=20 work even if we deliver messages via a USB token from a source to a=20 destination. However, I note that a protocol of that sort is likely to = be more=20 complex than one that assumes use of lower layer network protocols, = even=20 staged delivery ones.

Steve
------=_NextPart_000_00FA_01C7E013.AF8B7060-- From owner-ietf-trust-anchor Thu Aug 16 12:04: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 l7GJ4hGq044253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 12:04: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 l7GJ4h3A044252; Thu, 16 Aug 2007 12:04: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7GJ4fLF044244 for ; Thu, 16 Aug 2007 12:04:42 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1ILke8-000874-5q; Thu, 16 Aug 2007 15:04:40 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <00f701c7e031$e24dd740$0301a8c0@Wylie> References: <20070814222421.Y34125@gecko.reptiles.org> <00f701c7e031$e24dd740$0301a8c0@Wylie> Date: Thu, 16 Aug 2007 15:00:10 -0400 To: "Turner, Sean P." From: Stephen Kent Subject: RE: Issue with the requirements document: PKIX-centric terminology 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: >... >Steve, > >If we don't include their documents as a normative reference does this still >hold true? We don't expect everybody that might use TAM deliverables to >have publiclly available documents for their architectures, etc. We do >expect and want people to come and contribute to the work - but the oneous >is on them to see that it supports their use cases. > >spt Sean, Certainly someone may make use of TAM even if we never know about their context, protocol constraints, etc. The question I was raising is whether we consciously try to accommodate use cases that depend on standards controlled by other organizations (without a liaison relationship) or in areas where there are no standards and where proprietary mechanisms are the rule. A secondary question is, if we do try to accommodate use cases from such contexts, do we give them equal weight relative to use cases that reside within the IETF purview. For example, if we have X.509, OPGP, and DNSSEC-based use cases, do we pay more attention to them? Steve From owner-ietf-trust-anchor Thu Aug 16 12:35: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 l7GJZJgc047053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 12:35: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 l7GJZJK4047052; Thu, 16 Aug 2007 12:35: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 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 l7GJZIik047045 for ; Thu, 16 Aug 2007 12:35:18 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 11263 invoked from network); 16 Aug 2007 19:35:16 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.36.91 with login) by smtp101.biz.mail.re2.yahoo.com with SMTP; 16 Aug 2007 19:35:16 -0000 X-YMail-OSG: bdXa0i4VM1m6Jvo.cowqfNRn.ofrhR0FYi1ioU0wMqx54drMlJDuTpsR117QMB7mrGSn5KoXW.NO_WV1rPNnhSZ7RoRIwt4.Cv8ohrjlOQAYXl0Q8bYfDBRMs53hmWneSiiVC3QxDUBn9ME- From: "Turner, Sean P." To: "'Stephen Kent'" Cc: References: <20070814222421.Y34125@gecko.reptiles.org> <00f701c7e031$e24dd740$0301a8c0@Wylie> Subject: RE: Issue with the requirements document: PKIX-centric terminology Date: Thu, 16 Aug 2007 15:24:00 -0400 Organization: IECA, Inc. Message-ID: <016701c7e03a$ffb93000$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcfgOEyG9ES5knUhSleEo5AZlEq9eAAAQB+g Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >-----Original Message----- >From: Stephen Kent [mailto:kent@bbn.com] >Sent: Thursday, August 16, 2007 3:00 PM >To: Turner, Sean P. >Cc: ietf-trust-anchor@vpnc.org >Subject: RE: Issue with the requirements document: >PKIX-centric terminology > >>... >>Steve, >> >>If we don't include their documents as a normative reference >does this >>still hold true? We don't expect everybody that might use TAM >>deliverables to have publiclly available documents for their >>architectures, etc. We do expect and want people to come and >contribute >>to the work - but the oneous is on them to see that it >supports their use cases. >> >>spt > >Sean, > >Certainly someone may make use of TAM even if we never know >about their context, protocol constraints, etc. > >The question I was raising is whether we consciously try to >accommodate use cases that depend on standards controlled by >other organizations (without a liaison relationship) or in >areas where there are no standards and where proprietary >mechanisms are the rule. >A secondary question is, if we do try to accommodate use cases >from such contexts, do we give them equal weight relative to >use cases that reside within the IETF purview. For example, >if we have X.509, OPGP, and DNSSEC-based use cases, do we pay >more attention to them? > >Steve I think we should consciously try to accommodate use cases even if they're based on non-public scenarios - if the folks "representing" those other organizations/standards want to work on TAM. Some of this might be growing pains for the IETF, but maybe a liaison should be formed with groups like TCG/TPM that want to work on it and that want to use the outcome? The second question is the interesting one. Doesn't it come down to if you want to play with the sand in the IETF sandbox, then the IETF wins the arguments? I guess I think it does. It would be hard for me to swallow a decision that threw an IETF "requirement" off the raft for a non-IETF "requirement." Then again - if we design a basic protocol with extensions I guess I could see a scenario where it wouldn't work for everyone, but I can also see lots of other scenarios where they (who ever didn't win the argument) take some kind of "hit" (i.e., they don't get it exactly their way) to do the "standard" TAM. spt From owner-ietf-trust-anchor Fri Aug 17 00:20:49 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 l7H7KnCK002435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 00:20:49 -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 l7H7Kno6002434; Fri, 17 Aug 2007 00:20:49 -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 mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7H7Kk05002425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Aug 2007 00:20:48 -0700 (MST) (envelope-from seppo.lindborg@ericsson.com) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 84E3B207AD; Fri, 17 Aug 2007 09:20:37 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-5a-46c54c45ed26 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6D9612065A; Fri, 17 Aug 2007 09:20:37 +0200 (CEST) Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 09:20:37 +0200 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: Draft Charter Date: Fri, 17 Aug 2007 09:20:36 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Charter Thread-Index: AcfgL8uH1Kbvy8icSvG+olt5j9i/AAAbyDew References: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.com> <20070816114559.A34125@gecko.reptiles.org> From: "Seppo Lindborg (JO/LMF)" To: "Stephen Kent" Cc: X-OriginalArrivalTime: 17 Aug 2007 07:20:37.0562 (UTC) FILETIME=[1BE2D1A0:01C7E09F] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7H7Km04002429 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This the current situation, but is it OK, or even acceptable? Wouldn't it be more appropriate approach that there were no ready trust assumptions or settings in the tool, and the user would add his, either from some ready file, or case-by-case when he surfs? Seppo Lindborg > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of > Stephen Kent > Sent: 16. elokuuta 2007 19:25 > To: Cat Okita > Cc: ietf-trust-anchor@vpnc.org > Subject: Re: Draft Charter > > > I'm not sure that we agree on this. The current situation is > that there is one TAA (typically the browser vendor) and a > lot of TAs. One might say that a browser vendor would install > all the current TAs as TAAs, but there is no a priori reason > to assume that model. > > Steve > > From owner-ietf-trust-anchor Fri Aug 17 06:33: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 l7HDXPB6043475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 06:33: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 l7HDXPJK043474; Fri, 17 Aug 2007 06:33: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HDXOlO043467 for ; Fri, 17 Aug 2007 06:33:25 -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 1IM1x3-00081e-4X; Fri, 17 Aug 2007 09:33:21 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.com> <20070816114559.A34125@gecko.reptiles.org> Date: Fri, 17 Aug 2007 09:30:38 -0400 To: "Seppo Lindborg (JO/LMF)" From: Stephen Kent Subject: RE: Draft Charter 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 9:18 AM +0200 8/17/07, Seppo Lindborg (JO/LMF) wrote: >This the current situation, but is it OK, or even acceptable? Wouldn't >it be more appropriate approach that there were no ready trust >assumptions or settings in the tool, and the user would add his, either >from some ready file, or case-by-case when he surfs? > >Seppo Lindborg For some, sophisticated users this could be a great improvement. For 99% of the users it would likely create more opportunities for social engineering. We have years of experience, plus a nice study by folks at CMU, showing that the average user is clueless about SSL/TLS, lock icons, etc. and is easily fooled. That's why phishing is so successful. Steve From owner-ietf-trust-anchor Fri Aug 17 09:12: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 l7HGC7cr061210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 09:12: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 l7HGC7FB061209; Fri, 17 Aug 2007 09:12: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 mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HGC4TF061196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Aug 2007 09:12:06 -0700 (MST) (envelope-from Black_David@emc.com) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7HGBJbA009844; Fri, 17 Aug 2007 12:11:19 -0400 (EDT) Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7HGA9KC013880; Fri, 17 Aug 2007 12:11:16 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 12:11:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: Multiple TAAs Date: Fri, 17 Aug 2007 12:11:13 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple TAAs Thread-Index: AcfgG0jKps1QwVJ4QHe2KWRrlOpI0QAy8E1Q References: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.com> To: , Cc: X-OriginalArrivalTime: 17 Aug 2007 16:11:13.0986 (UTC) FILETIME=[3BDF9A20:01C7E0E9] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7HGC6TE061204 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I want to expand on something I said at the microphone in Chicago - I think the easiest (and likely to be the most common) solution to multiple TAAs that don't have the same management privileges is separate trust anchor stores and that an operational model of all TAAs for a trust anchor store having the same management privileges is the easiest to cope with. I think any use case that postulates different TAAs with different privileges for the *same* trust anchor store needs to have a strong justification for the difference in privileges. Let me start by applying this to Yoav's enterprise browser example: > >I think what's typical for an Enterprise depends on the application. > >If we're talking about browsers, then I think it's perfectly > >acceptable to have two TAAs - one from the browser vendor (it > >shouldn't be my employer's task to tell me that Verisign has a new > >root CA certificate - that's Microsoft's job) and the other being > >the corporate IT department. That's why I think each TAA should be > >able to manage its own (and only its own) trust anchors. > > Even in this case I can see problems, I think several folks have > noted that the default TAs currently installed in browsers ought to > be subject to local management, especially deletion! So, as a browser > user in an enterprise context, I would not want a TAA installed by MS > (or, in my case, Apple) to be able to maintain the presence of TAs > even if my IT dept wants to remove them. I agree with Steve, and my employer behaves in exactly this way with respect to *all* MS updates, not just browser trust anchors - all of MS's automatic updates flow through a server maintained by the corporate IT folks, hence there's only one TAA. I do not see the need for multiple TAAs with different privileges - either the IT folks trust MS to do whatever MS wants to (both TAAs have the same privileges) or they don't (MS updates redirected through IT, IT is the only TAA). > >In your consumer space example, I again don't think SalesForce.com > >should be able to delete bankofamerica.com's trust anchor. Perhaps > >there should be exception, such as if Microsoft learns that the > >bankofamerica.com TA really belongs to a phishing company, but I > >think each TAA should manage its own as a general rule, and this > >should be enforced. If SalesForce.com needs to manage browser trust anchors, then it needs its own trust anchor store (perhaps even its own copy of the browser) on the end user's system, and then SalesForce.com can do whatever it wants with those anchors. I suspect SalesForce.com is unlikely to want to do this, and probably has limited in managing trust anchors of its customers/users, as it's very easy to break things this way. One specific point is that trust anchor changes don't strike me as a good way to deal with phishing - encouraging or forcing an updated CRL into the browser before allowing site access is likely to be considerably more effective. My preference is that managing different privileges for multiple TAAs administering the same trust anchor store ought to be out of scope, unless someone has a compelling use case with which to argue otherwise. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ietf-trust-anchor Fri Aug 17 10:14: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 l7HHEO80068808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 10:14: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 l7HHEOPr068806; Fri, 17 Aug 2007 10:14: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HHENmE068791 for ; Fri, 17 Aug 2007 10:14:23 -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 1IM5Ox-0004TH-3V; Fri, 17 Aug 2007 13:14:23 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <016701c7e03a$ffb93000$0301a8c0@Wylie> References: <20070814222421.Y34125@gecko.reptiles.org> <00f701c7e031$e24dd740$0301a8c0@Wylie> <016701c7e03a$ffb93000$0301a8c0@Wylie> Date: Fri, 17 Aug 2007 13:08:46 -0400 To: "Turner, Sean P." From: Stephen Kent Subject: RE: Issue with the requirements document: PKIX-centric terminology 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 3:24 PM -0400 8/16/07, Turner, Sean P. wrote: >... > >I think we should consciously try to accommodate use cases even if they're >based on non-public scenarios - if the folks "representing" those other >organizations/standards want to work on TAM. Some of this might be growing >pains for the IETF, but maybe a liaison should be formed with groups like >TCG/TPM that want to work on it and that want to use the outcome? The IETF does establish liaisons with other SDOs, prior to doing work. We have such relationships with ITU, IEEE, and, I think, the W3C, for example. I don't think we have one with TCG. I couldn't tell from the text above if you were aware of these relationships. One problem is that, absent such a relationship, it can be hard to determine if someone really represents another group, although there are exceptions. For example, PKIX has worked with "representatives" from ETSI, where I believe no formal IETF liaison exists. However, if the individual chairs a relevant ETSI group, or is the author of several ETSI documents and wants to coordinate another such document with PKIX, we have sufficient basis for treating the individual as a valid representative, informally. I would expect other WGs operate similarly. >The second question is the interesting one. Doesn't it come down to if you >want to play with the sand in the IETF sandbox, then the IETF wins the >arguments? I guess I think it does. It would be hard for me to swallow a >decision that threw an IETF "requirement" off the raft for a non-IETF >"requirement." no disagreement there. >Then again - if we design a basic protocol with extensions I guess I could >see a scenario where it wouldn't work for everyone, but I can also see lots >of other scenarios where they (who ever didn't win the argument) take some >kind of "hit" (i.e., they don't get it exactly their way) to do the >"standard" TAM. Extensions are the bane of security protocols. For example, we have had bad experiences with them in OCSP. We see that X.509 extensions can either be focused and useful, or committee compromises that add complexity but are rarely used or supported. If we create a protocol that is largely a shell, to be broadly accommodating, and one has to define context-specific extensions for X.509, OPGP, DNSSEC, etc., then it remains to be seen how useful the common shell will be. Steve From owner-ietf-trust-anchor Fri Aug 17 10:14: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 l7HHEONQ068807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 10:14: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 l7HHEO06068805; Fri, 17 Aug 2007 10:14: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HHEMlo068789 for ; Fri, 17 Aug 2007 10:14:23 -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 1IM5Ow-0004TH-3m; Fri, 17 Aug 2007 13:14:22 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <00f801c7e035$01bb9e70$0301a8c0@Wylie> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C87908C9C5FC@EXVS01.ex.dslextreme.net> <00f801c7e035$01bb9e70$0301a8c0@Wylie> Date: Fri, 17 Aug 2007 13:07:13 -0400 To: "Turner, Sean P." From: Stephen Kent Subject: RE: Draft Charter 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:41 PM -0400 8/16/07, Turner, Sean P. wrote: >(sorry I'm jumping back to this) > >I think we should add the following as the first sentence: "A trust anchor >is an established point of trust, which is usually based on the authority of >some person, office or organization." [Shirey] I think we should do this >because we jumped right in to how it's used not what it is. I used Rob's >definition because I think it hit the mark. > Although Rob worked for me for many years, and I generally like his security glossary, I can't say that I find this definition great. The definition uses the word "trust," which is generally mushy. It tries to qualify that by alluding to authority, which I think is really is central to the issue, especially for TAM. This may be an example of how an attempt to be very general produces a watered-down definition. Also, absent the further examples you give, but describe as context-specific, the quoted text is not technically useful, i.e., without the examples the definition doesn't tell me if a TA is a public key or a fruit :-). Steve From owner-ietf-trust-anchor Fri Aug 17 11:26: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 l7HIQ0jZ077244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 11:26: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 l7HIQ033077243; Fri, 17 Aug 2007 11:26: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 woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7HIPu2Y077232 for ; Fri, 17 Aug 2007 11:25:59 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200708171825.l7HIPu2Y077232@balder-227.proper.com> Received: (qmail 17130 invoked by uid 0); 17 Aug 2007 18:25:51 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.247) by woodstock.binhost.com with SMTP; 17 Aug 2007 18:25:51 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Aug 2007 14:19:28 -0400 To: Black_David@emc.com From: Russ Housley Subject: Re: Multiple TAAs Cc: ietf-trust-anchor@vpnc.org In-Reply-To: References: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.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: David: I think we need to think about the degree of delegation that we want to permit. I can imagine an enterprise permitting a contracted service to provide some support here. However, the one thing that the do not want the contracted service to do is remove the enterprise from the picture. That would prevent the enterprise from changing providers. So, I can imagine the enterprise holding an all-powerful TA, and using this to add and delete TA administration privileges for the trust anchor stores in the devices and software packages that are used in the enterprise. The TA administration privilege must not be sufficient to become the all-powerful TA. I see no reason for there to me more than one all-powerful TA as long as the all-powerful TA can be used to make updates to the all-powerful TA, say when two enterprises merge. Russ At 12:11 PM 8/17/2007, Black_David@emc.com wrote: >My preference is that managing different privileges for multiple >TAAs administering the same trust anchor store ought to be out of >scope, unless someone has a compelling use case with which to argue >otherwise. From owner-ietf-trust-anchor Fri Aug 17 13:14: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 l7HKEVge087893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 13:14: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 l7HKEVvO087892; Fri, 17 Aug 2007 13:14: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 l7HKEU5Y087886 for ; Fri, 17 Aug 2007 13:14:30 -0700 (MST) (envelope-from thardjono@wavesys.com) Subject: RE: Issue with the requirements document: PKIX-centric terminology Date: Fri, 17 Aug 2007 13:15:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: In-Reply-To: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue with the requirements document: PKIX-centric terminology Thread-Index: AcfgIutVHmICDmcpROSYhaxCiDRFmAA5wVdw From: "Thomas Hardjono" To: "Stephen Kent" , "Cat Okita" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7HKEU5Y087887 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: Thursday, August 16, 2007 9:21 AM > To: Cat Okita > Cc: ietf-trust-anchor@vpnc.org > Subject: RE: Issue with the requirements document: > PKIX-centric terminology > > > At 10:28 PM -0400 8/14/07, Cat Okita wrote: > >On Fri, 10 Aug 2007, Stephen Kent wrote: > >>I think we should make decisions about what work to do in the IETF > >>based on who participates in the IETF work, not based on who we > >>believe may benefit. > > > >I think this is the attitude that leads many people to > believe that the > >IETF is a pointless waste of time. > > > >My understanding was that the goals of the IETF include > producing well > >considered and designed protocols that are a benefit to all, and > >readily used by all, not a group of inbred pedants intent > only on self-gratification. > > > >cheers! > > A great many folks who are not part of the IETF process > benefit from the standards we generate. However, unless folks > actively participate in the process, there is no way to > ensure that external constituencies are well represented. > Moreover, someone who claims to represent such a constituency > is not intrinsically credible. Thus when we decide the scope > of work for a WG, it is common to make decisions based on who > chooses to contribute, and to focus on the IETF context. For > example, the IETF does not develop security standards > targeting the LAN environment unless the IEEE asks us to do so. > > A closer to home example arises in the message Thomas sent recently. > He gave several good examples of uses cases for TAM. > Included in his list was the TCM context (use case #2) and > mobile phones (UC #4). > The TCM case might be problematic because the TCG defines how > TCMs work and TCG is a closed group (one has to pay a fee and > sign an HDA to be a member.) So, only if all of the relevant > documents from TCG are publicly available could we reasonably > address this use case. > (Having Thomas as a contributor helps since he is the editor > of one or more TCG documents that deal with this area!) The > mobile phone use case is likely to be more problematic, as I > believe there are no public standards for ALL mobile phones > re managing signed code validation, etc. It may not make > sense for us to try to address problems in areas where the > IETF has no standing, where there are no public standards, etc. > > Steve Thanks Steve. In my several years experience with the TCG, the TCG community typically prefers to use existing standards from other bodies/organizations like the IETF and Oasis (instead of re-inventing the wheel). This is why the TCG several years ago decided on the X.509 standard for the TPM-related certificates and profiles. Most (if not all) of the relevant documents for UC#2 are now published documents (available at the TCG website, under the Specs tab). No need to sign/enter anything to download :) In the mobile phone/carrier community, I believe that the Open Mobile Alliance (OMA) and 3GPP also uses X.509. /thomas/ From owner-ietf-trust-anchor Fri Aug 17 13:31: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 l7HKVNwK089370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 13:31: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 l7HKVNsd089369; Fri, 17 Aug 2007 13:31: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 michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HKVLZ4089360 for ; Fri, 17 Aug 2007 13:31:22 -0700 (MST) (envelope-from ynir@checkpoint.com) Received: from [172.31.21.132] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l7HKVJRL008846; Fri, 17 Aug 2007 23:31:19 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CEB41D8-B168-4168-ACD4-F189DBAD01D6@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: Multiple TAAs Date: Fri, 17 Aug 2007 23:31:10 +0300 To: ietf-trust-anchor@vpnc.org, Black_David@emc.com X-Mailer: Apple Mail (2.752.3) Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I, for one, don't have a compelling case. I think the enterprise has the browser TA store holding exactly Microsoft's (or Apple's or Mozilla's) regular store plus one more enterprise TA. Maybe there could be two extra TAs right after a merger. What Stephen Kent suggested, that the IT department appoint itself as the one and only TAA and then repeat all of Microsoft's changes, may be the way enterprises choose to handle this (either that or outsourcing it like all other IT). but then you don't need multiple TAAs at all. You may want to allow them for high availability and such, but they're all the same. To get a real requirement for separation of powers or for a hierarchy of authority, we'll need to look for an example where the computer, or more specifically - the application associated with the TA store (TAS?) is somehow controlled by more than one entity. The example where a bank requires you to allow it to manage your browser sounds forced to me. Real banks would like you to connect from anywhere, so they'll buy a certificate from one of the >100 TA vendors that everybody's got in their browser. Someone suggested an example of a contractor or consultant who works for several companies such as in the enterprise example, so she needs to have each IT department as TAA. I'm not sure I buy this either, but it could be. Perhaps one of the non-browser examples might have a more compelling case? On Aug 17, 2007, at 7:11 PM, Black_David@emc.com wrote: > > My preference is that managing different privileges for multiple > TAAs administering the same trust anchor store ought to be out of > scope, unless someone has a compelling use case with which to argue > otherwise. From owner-ietf-trust-anchor Sat Aug 18 09:21: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 l7IGLtA1005189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Aug 2007 09:21: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 l7IGLtDI005188; Sat, 18 Aug 2007 09:21: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 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 l7IGLUoA005133 for ; Sat, 18 Aug 2007 09:21:51 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 60805 invoked from network); 18 Aug 2007 16:21:25 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.15.110 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 18 Aug 2007 16:21:25 -0000 X-YMail-OSG: T2F83boVM1nD6Q8jZPrgeiIBClVA8_mZyfFEj9.dEY5T0rMjEoNosiCKYqMMSOLArTjZ5bNvGr3ofPDQWYsCf9O9qTq2lYVTBvuEG5konLgv5qWkeLBZG1pqVHSquFhVFWk70lbh_GgB6pc- From: "Turner, Sean P." To: "'Stephen Kent'" Cc: References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C87908C9C5FC@EXVS01.ex.dslextreme.net> <00f801c7e035$01bb9e70$0301a8c0@Wylie> Subject: RE: Draft Charter Date: Sat, 18 Aug 2007 12:09:56 -0400 Organization: IECA, Inc. Message-ID: <00bf01c7e1b2$3a620880$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: Acfg86HTumsqbRseStCENwmI851/rwAvWeZg 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: >-----Original Message----- >At 2:41 PM -0400 8/16/07, Turner, Sean P. wrote: >>(sorry I'm jumping back to this) >> >>I think we should add the following as the first sentence: "A trust >>anchor is an established point of trust, which is usually >based on the >>authority of some person, office or organization." [Shirey] I >think we >>should do this because we jumped right in to how it's used >not what it >>is. I used Rob's definition because I think it hit the mark. >> > >Although Rob worked for me for many years, and I generally >like his security glossary, I can't say that I find this >definition great. > >The definition uses the word "trust," which is generally >mushy. It tries to qualify that by alluding to authority, >which I think is really is central to the issue, especially >for TAM. This may be an example of how an attempt to be very >general produces a watered-down definition. > >Also, absent the further examples you give, but describe as >context-specific, the quoted text is not technically useful, >i.e., without the examples the definition doesn't tell me if a >TA is a public key or a fruit :-). > >Steve I thought there might have been some connection with you and Rob ;) The glossary's definition had more in the 1st sentence which basically said what the suggested second sentence said - so I get your point about mushy fruit. I agree that the authority is a central concept to TAM and that's what I was alluding to with my context comment. I think it ought to be in the definition. How about: A trust anchor is a public key and associated data that represents an authoritative source of some type of information. Associated data is used to define the scope of the use of the trust anchor including the authorized type of information. spt From owner-ietf-trust-anchor Sat Aug 18 10:27: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 l7IHRqit010869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Aug 2007 10:27: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 l7IHRquL010868; Sat, 18 Aug 2007 10:27: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 mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7IHRU9I010844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 18 Aug 2007 10:27:51 -0700 (MST) (envelope-from Black_David@emc.com) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7IHRSTP028105; Sat, 18 Aug 2007 13:27:28 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7IHRPjF004862; Sat, 18 Aug 2007 13:27:25 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Aug 2007 13:27:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Multiple TAAs Date: Sat, 18 Aug 2007 13:27:24 -0400 Message-ID: In-Reply-To: <200708171825.l7HIPu2Y077232@balder-227.proper.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple TAAs Thread-Index: Acfg/Oaw23TqupsiSwKZgI1lk0mztgAu5Fhg References: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.com> <200708171825.l7HIPu2Y077232@balder-227.proper.com> To: Cc: X-OriginalArrivalTime: 18 Aug 2007 17:27:25.0046 (UTC) FILETIME=[0AD9C160:01C7E1BD] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P2 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7IHRp9H010863 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Russ, > At 12:11 PM 8/17/2007, Black_David@emc.com wrote: > >My preference is that managing different privileges for multiple > >TAAs administering the same trust anchor store ought to be out of > >scope, unless someone has a compelling use case with which to argue > >otherwise. > > I think we need to think about the degree of delegation that we want > to permit. I can imagine an enterprise permitting a contracted > service to provide some support here. However, the one thing that > the do not want the contracted service to do is remove the enterprise > from the picture. That would prevent the enterprise from changing > providers. I definitely agree that we need to think about delegation - IMHO, delegation is second only to policy in its ability to introduce complexities, subtleties and the concomitant opportunity for implementation and user mistakes that cause security issues in practice. > So, I can imagine the enterprise holding an all-powerful TA, and > using this to add and delete TA administration privileges for the > trust anchor stores in the devices and software packages that are > used in the enterprise. The TA administration privilege must not > be sufficient to become the all-powerful TA. All of the TAs in the above paragraph are the anchors for the trust stores which in turn contain trust anchors for use by applications. For clarity, let's use the term Trust Store Anchor (TSA) to refer to an anchor that confers the ability to manage application trust anchors in a trust store, and use the term Application Trust Anchors (ATAs) if/as necessary for clarity. Using this terminology, the scenario that Russ is concerned about boils down to controlling which TSAs can manage the TSAs for a trust store. Both TSAs can manage all the application TAs, as the enterprise presumably trusts the contracted service to correctly manage the enterprise-specific ATAs (and if the enterprise doesn't, I strongly suggest that it should resort to the "send all your updates through me" solution described for Microsoft updates in earlier messages). I think it would be fine for every TSA entry in a trust store to have a boolean property indicating whether it can manage the TSAs for the trust store, as long as all the TSAs for a trust store can manage all of the application trust anchors in that trust store. Given all of this, Russ's issue is then how the enterprise retains control over its trust stores (e.g., so it can switch to another trust anchor management service provider without the existing provider's cooperation). With the "can manage TSAs" boolean property, the solution is reasonably straightforward - each trust store has two Trust Store Anchors: - The (all-powerful) enterprise TSA with its "can manage TSAs" property set to True. - The contracted service TSA with its "can manage TSAs" property set to False. Both TSAs can manage all the application trust anchors in the trust store, and if a (contractual) conflict arises, the enterprise TSA is used to delete the contracted service TSA and clean up whatever mess it left behind. One more item. Russ wrote: > I see no reason for there to me more than one all-powerful TA as > long as the all-powerful TA can be used to make updates to the > all-powerful TA, say when two enterprises merge. The reason may be dealing with private key compromise in a tractable fashion - if an all-powerful TA needs to be revoked (e.g., via a CRL), it would be more than convenient to have another one to use. Two should be enough. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ietf-trust-anchor Sat Aug 18 11:36: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 l7IIaStY017815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Aug 2007 11:36: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 l7IIaSd5017814; Sat, 18 Aug 2007 11:36: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7IIa45g017786 for ; Sat, 18 Aug 2007 11:36:27 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 13243 invoked from network); 18 Aug 2007 18:33:02 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;18 Aug 2007 18:33:02 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 18 Aug 2007 18:33:01 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Sat, 18 Aug 2007 14:36:03 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31D667@scygmxs1.cygnacom.com> From: Carl Wallace To: housley@vigilsec.com, Black_David@emc.com Cc: ietf-trust-anchor@vpnc.org Subject: RE: Multiple TAAs Date: Sat, 18 Aug 2007 14:35:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E1C6.9D5DD0AE" 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_01C7E1C6.9D5DD0AE Content-Type: text/plain > > At 12:11 PM 8/17/2007, Black_David@emc.com wrote: > > >My preference is that managing different privileges for > multiple TAAs > > >administering the same trust anchor store ought to be out > of scope, > > >unless someone has a compelling use case with which to argue > > >otherwise. Requiring separate trust stores to accommodate multiple trust anchor managers with different privileges is one approach, but it might not be the easiest to manage. Depending on how it is supported, routine rekey may be one example for allowing multiple TAAs with different privileges. For example, a TA that is authoritative for namespace X could generate a management message that could be used to add its new key to a trust store and remove its old key. Assuming the trust store has multiple TAs for different namespaces, there would be multiple TAAs with different privileges. > > So, I can imagine the enterprise holding an all-powerful > TA, and using > > this to add and delete TA administration privileges for the trust > > anchor stores in the devices and software packages that are used in > > the enterprise. The TA administration privilege must not be > > sufficient to become the all-powerful TA. > > All of the TAs in the above paragraph are the anchors for the > trust stores which in turn contain trust anchors for use by > applications. > > For clarity, let's use the term Trust Store Anchor (TSA) to > refer to an anchor that confers the ability to manage > application trust anchors in a trust store, and use the term > Application Trust Anchors > (ATAs) if/as necessary for clarity. > > Using this terminology, the scenario that Russ is concerned > about boils down to controlling which TSAs can manage the > TSAs for a trust store. Both TSAs can manage all the > application TAs, as the enterprise presumably trusts the > contracted service to correctly manage the > enterprise-specific ATAs (and if the enterprise doesn't, I > strongly suggest that it should resort to the "send all your > updates through me" solution described for Microsoft updates > in earlier messages). Why limit the arrangement such that the contracted service can manage everything? It doesn't seem like much of a stretch to use constraints similar to those we've discussed for application TAs, i.e., name constraints or usage constraints. > One more item. Russ wrote: > > > I see no reason for there to me more than one all-powerful > TA as long > > as the all-powerful TA can be used to make updates to the > all-powerful > > TA, say when two enterprises merge. > > The reason may be dealing with private key compromise in a > tractable fashion - if an all-powerful TA needs to be revoked > (e.g., via a CRL), it would be more than convenient to have > another one to use. Two should be enough. This suggests we need to be able to represent: a pair all powerful TSAs, if for no other reason than recovery from compromise or loss; one or more(?) less-powerful TSAs; and a set of ATAs. ------_=_NextPart_001_01C7E1C6.9D5DD0AE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Multiple TAAs

 
<snip>
> > At 12:11 PM 8/17/2007, Black_David@emc.com = wrote:
> > >My preference is that managing = different privileges for
> multiple TAAs
> > >administering the same trust anchor = store ought to be out
> of scope,
> > >unless someone has a compelling use = case with which to argue
> > >otherwise.

Requiring separate trust stores to accommodate = multiple trust anchor managers with different privileges is one = approach, but it might not be the easiest to manage.  Depending on = how it is supported, routine rekey may be one example for allowing = multiple TAAs with different privileges.  For example, a TA that = is authoritative for namespace X could generate a management message = that could be used to add its new key to a trust store and remove its = old key.  Assuming the trust store has multiple TAs for different = namespaces, there would be multiple TAAs with different = privileges.

<snip>
> > So, I can imagine the enterprise holding = an all-powerful
> TA, and using
> > this to add and delete TA administration = privileges for the trust
> > anchor stores in the devices and software = packages that are used in
> > the enterprise.  The TA = administration privilege must not be
> > sufficient to become the all-powerful = TA.
>
> All of the TAs in the above paragraph are the = anchors for the
> trust stores which in turn contain trust = anchors for use by
> applications.
>
> For clarity, let's use the term Trust Store = Anchor (TSA) to
> refer to an anchor that confers the ability to = manage
> application trust anchors in a trust store, and = use the term
> Application Trust Anchors
> (ATAs) if/as necessary for clarity.
>
> Using this terminology, the scenario that Russ = is concerned
> about boils down to controlling which TSAs can = manage the
> TSAs for a trust store.  Both TSAs can = manage all the
> application TAs, as the enterprise presumably = trusts the
> contracted service to correctly manage the =
> enterprise-specific ATAs (and if the enterprise = doesn't, I
> strongly suggest that it should resort to the = "send all your
> updates through me" solution described for = Microsoft updates
> in earlier messages).

Why limit the arrangement such that the contracted = service can manage everything?  It doesn't seem like much of a = stretch to use constraints similar to those we've discussed for = application TAs, i.e., name constraints or usage = constraints.

 
<snip>
> One more item.  Russ wrote:
>
> > I see no reason for there to me more than = one all-powerful
> TA as long
> > as the all-powerful TA can be used to make = updates to the
> all-powerful
> > TA, say when two enterprises merge.
>
> The reason may be dealing with private key = compromise in a
> tractable fashion - if an all-powerful TA needs = to be revoked
> (e.g., via a CRL), it would be more than = convenient to have
> another one to use.  Two should be = enough.

This suggests we need to be able to represent: a pair = all powerful TSAs, if for no other reason than recovery from compromise = or loss; one or more(?) less-powerful TSAs; and a set of = ATAs.

------_=_NextPart_001_01C7E1C6.9D5DD0AE-- From owner-ietf-trust-anchor Sat Aug 18 11:50: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 l7IIoVlI018745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Aug 2007 11:50: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 l7IIoVpP018744; Sat, 18 Aug 2007 11:50: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 mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7IIoUqs018738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 18 Aug 2007 11:50:30 -0700 (MST) (envelope-from Black_David@emc.com) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7IIoTOa017507; Sat, 18 Aug 2007 14:50:29 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7IIoQD7022886; Sat, 18 Aug 2007 14:50:26 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Aug 2007 14:50:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Multiple TAAs Date: Sat, 18 Aug 2007 14:50:25 -0400 Message-ID: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31D667@scygmxs1.cygnacom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple TAAs Thread-Index: AcfhxqkPhNaGaNXuRpuWRod70QsYJQAAKt5A References: <886F5D4C78AFB14D87261206BFB9612E1D31D667@scygmxs1.cygnacom.com> To: Cc: X-OriginalArrivalTime: 18 Aug 2007 18:50:26.0126 (UTC) FILETIME=[A3CE3EE0:01C7E1C8] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_BADTHINGS 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7IIoVqr018739 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Carl, > Why limit the arrangement such that the contracted service can manage everything? Why not? In particular, I see profound contractual difficulties if the enterprise can't trust the contracted service to manage all the trust anchors - if it's not trusted for that, what else is it not trusted for, and how are we going to express that? > It doesn't seem like much of a stretch to use constraints similar to those we've > discussed for application TAs, i.e., name constraints or usage constraints. The proverbial road to (complexity) is paved with exactly these sorts of good intentions (e.g., "nice to have" features). The moment TSAs have to be configured with name and usage constraints, the administrative problems of managing trust anchor management have gone up significantly (the trust anchors are already hard enough to manage - we should strive to avoid making that problem significantly worse). I'm interested in "must have" arguments, but my response to "nice to have" arguments about features for managing trust anchor management is going to be to complain (whine if necessary) about administrative complexity - i.e., if in doubt, leave it out. I have use cases in mind in which this is used by non-security- experts (i.e., people trying to accomplish something else) to centralize trust anchor management - I don't want this "cure" to be worse than the "disease". Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ________________________________ From: Carl Wallace [mailto:CWallace@cygnacom.com] Sent: Saturday, August 18, 2007 2:36 PM To: housley@vigilsec.com; Black, David Cc: ietf-trust-anchor@vpnc.org Subject: RE: Multiple TAAs > > At 12:11 PM 8/17/2007, Black_David@emc.com wrote: > > >My preference is that managing different privileges for > multiple TAAs > > >administering the same trust anchor store ought to be out > of scope, > > >unless someone has a compelling use case with which to argue > > >otherwise. Requiring separate trust stores to accommodate multiple trust anchor managers with different privileges is one approach, but it might not be the easiest to manage. Depending on how it is supported, routine rekey may be one example for allowing multiple TAAs with different privileges. For example, a TA that is authoritative for namespace X could generate a management message that could be used to add its new key to a trust store and remove its old key. Assuming the trust store has multiple TAs for different namespaces, there would be multiple TAAs with different privileges. > > So, I can imagine the enterprise holding an all-powerful > TA, and using > > this to add and delete TA administration privileges for the trust > > anchor stores in the devices and software packages that are used in > > the enterprise. The TA administration privilege must not be > > sufficient to become the all-powerful TA. > > All of the TAs in the above paragraph are the anchors for the > trust stores which in turn contain trust anchors for use by > applications. > > For clarity, let's use the term Trust Store Anchor (TSA) to > refer to an anchor that confers the ability to manage > application trust anchors in a trust store, and use the term > Application Trust Anchors > (ATAs) if/as necessary for clarity. > > Using this terminology, the scenario that Russ is concerned > about boils down to controlling which TSAs can manage the > TSAs for a trust store. Both TSAs can manage all the > application TAs, as the enterprise presumably trusts the > contracted service to correctly manage the > enterprise-specific ATAs (and if the enterprise doesn't, I > strongly suggest that it should resort to the "send all your > updates through me" solution described for Microsoft updates > in earlier messages). Why limit the arrangement such that the contracted service can manage everything? It doesn't seem like much of a stretch to use constraints similar to those we've discussed for application TAs, i.e., name constraints or usage constraints. > One more item. Russ wrote: > > > I see no reason for there to me more than one all-powerful > TA as long > > as the all-powerful TA can be used to make updates to the > all-powerful > > TA, say when two enterprises merge. > > The reason may be dealing with private key compromise in a > tractable fashion - if an all-powerful TA needs to be revoked > (e.g., via a CRL), it would be more than convenient to have > another one to use. Two should be enough. This suggests we need to be able to represent: a pair all powerful TSAs, if for no other reason than recovery from compromise or loss; one or more(?) less-powerful TSAs; and a set of ATAs. From owner-ietf-trust-anchor Sat Aug 18 12:59: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 l7IJx0F0026056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Aug 2007 12:59: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 l7IJx0Qm026055; Sat, 18 Aug 2007 12:59: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 woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7IJwdGd026023 for ; Sat, 18 Aug 2007 12:58:59 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200708181958.l7IJwdGd026023@balder-227.proper.com> Received: (qmail 12294 invoked by uid 0); 18 Aug 2007 19:57:16 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.247) by woodstock.binhost.com with SMTP; 18 Aug 2007 19:57:16 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 18 Aug 2007 15:56:55 -0400 To: Black_David@emc.com From: Russ Housley Subject: RE: Multiple TAAs Cc: ietf-trust-anchor@vpnc.org In-Reply-To: References: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.com> <200708171825.l7HIPu2Y077232@balder-227.proper.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: David: I think we have reached agreement on the vast bulk of the things in my message and your reply. One exception: >One more item. Russ wrote: > > > I see no reason for there to me more than one all-powerful TA as > > long as the all-powerful TA can be used to make updates to the > > all-powerful TA, say when two enterprises merge. > >The reason may be dealing with private key compromise in a tractable >fashion - if an all-powerful TA needs to be revoked (e.g., via a CRL), >it would be more than convenient to have another one to use. Two >should be enough. You cannot deal with trust anchor compromise with CRLs. Trust anchors represent the beginning of a certification path, and thus they do not have a parent to issue the CRL. I agree that trust anchor compromise deserves some attention. SET offered a solution, which may be covered by a patent held by VISA International. I am aware of at least one other solution, but it is not clear if a patent is in the works or not. I'm trying to find out. Russ From owner-ietf-trust-anchor Sat Aug 18 13:48: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 l7IKmKs1029905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Aug 2007 13:48: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 l7IKmKSI029904; Sat, 18 Aug 2007 13:48:20 -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 l7IKmJx7029888 for ; Sat, 18 Aug 2007 13:48:20 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200708182048.l7IKmJx7029888@balder-227.proper.com> Received: (qmail 31743 invoked by uid 0); 18 Aug 2007 20:48:13 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.247) by woodstock.binhost.com with SMTP; 18 Aug 2007 20:48:13 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 18 Aug 2007 16:44:29 -0400 To: Carl Wallace , Black_David@emc.com From: Russ Housley Subject: RE: Multiple TAAs Cc: ietf-trust-anchor@vpnc.org In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31D667@scygmxs1.cygnacom .com> References: <886F5D4C78AFB14D87261206BFB9612E1D31D667@scygmxs1.cygnacom.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I strongly support Carl's point.  In performing delegation, it might be very useful to apply limits to the delegation.  X.509 already has a very good set of certification path validation constraints that will work nicely.  However, there seems to be one missing in this context.  It would be very useful to constrain the applications that the delegated-to trust anchor could impact.

Russ

Carl Wallace wrote:

 
<snip>
> > At 12:11 PM 8/17/2007, Black_David@emc.com wrote:
> > >My preference is that managing different privileges for
> multiple TAAs
> > >administering the same trust anchor store ought to be out
> of scope,
> > >unless someone has a compelling use case with which to argue
> > >otherwise.

Requiring separate trust stores to accommodate multiple trust anchor managers with different privileges is one approach, but it might not be the easiest to manage.  Depending on how it is supported, routine rekey may be one example for allowing multiple TAAs with different privileges.  For example, a TA that is authoritative for namespace X could generate a management message that could be used to add its new key to a trust store and remove its old key.  Assuming the trust store has multiple TAs for different namespaces, there would be multiple TAAs with different privileges.

<snip>
> > So, I can imagine the enterprise holding an all-powerful
> TA, and using
> > this to add and delete TA administration privileges for the trust
> > anchor stores in the devices and software packages that are used in
> > the enterprise.  The TA administration privilege must not be
> > sufficient to become the all-powerful TA.
>
> All of the TAs in the above paragraph are the anchors for the
> trust stores which in turn contain trust anchors for use by
> applications.
>
> For clarity, let's use the term Trust Store Anchor (TSA) to
> refer to an anchor that confers the ability to manage
> application trust anchors in a trust store, and use the term
> Application Trust Anchors
> (ATAs) if/as necessary for clarity.
>
> Using this terminology, the scenario that Russ is concerned
> about boils down to controlling which TSAs can manage the
> TSAs for a trust store.  Both TSAs can manage all the
> application TAs, as the enterprise presumably trusts the
> contracted service to correctly manage the
> enterprise-specific ATAs (and if the enterprise doesn't, I
> strongly suggest that it should resort to the "send all your
> updates through me" solution described for Microsoft updates
> in earlier messages).

Why limit the arrangement such that the contracted service can manage everything?  It doesn't seem like much of a stretch to use constraints similar to those we've discussed for application TAs, i.e., name constraints or usage constraints.

 
<snip>
> One more item.  Russ wrote:
>
> > I see no reason for there to me more than one all-powerful
> TA as long
> > as the all-powerful TA can be used to make updates to the
> all-powerful
> > TA, say when two enterprises merge.
>
> The reason may be dealing with private key compromise in a
> tractable fashion - if an all-powerful TA needs to be revoked
> (e.g., via a CRL), it would be more than convenient to have
> another one to use.  Two should be enough.

This suggests we need to be able to represent: a pair all powerful TSAs, if for no other reason than recovery from compromise or loss; one or more(?) less-powerful TSAs; and a set of ATAs.
From owner-ietf-trust-anchor Mon Aug 20 10:49: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 l7KHnvjA050270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 10:49: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 l7KHnvsq050267; Mon, 20 Aug 2007 10:49: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 l7KHnupF050257 for ; Mon, 20 Aug 2007 10:49: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 1INBNz-0000cL-3d; Mon, 20 Aug 2007 13:49:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <00bf01c7e1b2$3a620880$0301a8c0@Wylie> References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C87908C9C5FC@EXVS01.ex.dslextreme.net> <00f801c7e035$01bb9e70$0301a8c0@Wylie> <00bf01c7e1b2$3a620880$0301a8c0@Wylie> Date: Mon, 20 Aug 2007 13:49:59 -0400 To: "Turner, Sean P." From: Stephen Kent Subject: RE: Draft Charter 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 12:09 PM -0400 8/18/07, Turner, Sean P. wrote: >... > >The glossary's definition had more in the 1st sentence which basically said >what the suggested second sentence said - so I get your point about mushy >fruit. I agree that the authority is a central concept to TAM and that's >what I was alluding to with my context comment. I think it ought to be in >the definition. How about: > >A trust anchor is a public key and associated data that represents an >authoritative source of some type of information. Associated data is used >to define the scope of the use of the trust anchor including the authorized >type of information. > >spt Sean, I still find this too mushy :-). I'd like to see some mention of digital signatures in the definition. That seems to be an essential feature of TAs, irrespective of the use of certs (of any type) vs. raw keys. Steve From owner-ietf-trust-anchor Mon Aug 20 11:39: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 l7KIdYRu055390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 11:39: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 l7KIdYCB055389; Mon, 20 Aug 2007 11:39: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 rediris.es (chico.rediris.es [130.206.1.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7KIdXf9055380 for ; Mon, 20 Aug 2007 11:39:33 -0700 (MST) (envelope-from diego.lopez@rediris.es) Received: from [10.8.0.22] (lampara.rediris.es [130.206.1.13]) by chico.rediris.es (Postfix) with ESMTP id BDE3D45362 for ; Mon, 20 Aug 2007 20:39:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <000801c7dad8$6ee87e30$0301a8c0@Wylie> <82D5657AE1F54347A734BDD33637C87908C4E04C@EXVS01.ex.dslextreme.net> <82D5657AE1F54347A734BDD33637C87908C9C5FC@EXVS01.ex.dslextreme.net> <00f801c7e035$01bb9e70$0301a8c0@Wylie> <00bf01c7e1b2$3a620880$0301a8c0@Wylie> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E4C5C07-3D1D-43A3-8C51-EFC462129AAE@rediris.es> Content-Transfer-Encoding: 7bit From: "Diego R. Lopez" Subject: Re: Draft Charter Date: Mon, 20 Aug 2007 20:39:31 +0200 To: ietf-trust-anchor@vpnc.org X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 20 Aug 2007, at 19:49, Stephen Kent wrote: > At 12:09 PM -0400 8/18/07, Turner, Sean P. wrote: >> ... >> >> The glossary's definition had more in the 1st sentence which >> basically said >> what the suggested second sentence said - so I get your point >> about mushy >> fruit. I agree that the authority is a central concept to TAM and >> that's >> what I was alluding to with my context comment. I think it ought >> to be in >> the definition. How about: >> >> A trust anchor is a public key and associated data that represents an >> authoritative source of some type of information. Associated data >> is used >> to define the scope of the use of the trust anchor including the >> authorized >> type of information. > I still find this too mushy :-). I'd like to see some mention of > digital signatures in the definition. That seems to be an essential > feature of TAs, irrespective of the use of certs (of any type) vs. > raw keys. Ditto. In despite of the format used (certificates or whatever), a TA deals with the verification of digital signatures. -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Red.es - RedIRIS The Spanish NREN e-mail: diego.lopez@rediris.es jid: drlopez@im.rediris.es Tel: +34 955 056 621 Mobile: +34 669 898 094 ----------------------------------------- From owner-ietf-trust-anchor Mon Aug 20 13:52: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 l7KKqSdl066205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 13:52: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 l7KKqSXx066204; Mon, 20 Aug 2007 13:52: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7KKqRCq066196 for ; Mon, 20 Aug 2007 13:52:27 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 2526 invoked from network); 20 Aug 2007 20:49:21 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;20 Aug 2007 20:49:21 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 20 Aug 2007 20:49:20 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Mon, 20 Aug 2007 16:52:25 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: Draft Charter Date: Mon, 20 Aug 2007 16:52:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E36C.02BAED5C" 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_01C7E36C.02BAED5C Content-Type: text/plain Here's a variation that references digital signatures: A trust anchor represents an authoritative source of one or more types of information. Trust anchors are comprised of a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. Relying parties use trust anchors to determine if digitally signed information objects are valid by verifying digital signatures using the trust anchor's public key and by enforcing the constraints expressed in the associated data. > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of > Diego R. Lopez > Sent: Monday, August 20, 2007 2:40 PM > To: ietf-trust-anchor@vpnc.org > Subject: Re: Draft Charter > > > > On 20 Aug 2007, at 19:49, Stephen Kent wrote: > > At 12:09 PM -0400 8/18/07, Turner, Sean P. wrote: > >> ... > >> > >> The glossary's definition had more in the 1st sentence which > >> basically said what the suggested second sentence said - so I get > >> your point about mushy fruit. I agree that the authority > is a central > >> concept to TAM and that's what I was alluding to with my context > >> comment. I think it ought to be in the definition. How about: > >> > >> A trust anchor is a public key and associated data that > represents an > >> authoritative source of some type of information. > Associated data is > >> used to define the scope of the use of the trust anchor > including the > >> authorized type of information. > > I still find this too mushy :-). I'd like to see some mention of > > digital signatures in the definition. That seems to be an essential > > feature of TAs, irrespective of the use of certs (of any type) vs. > > raw keys. > > Ditto. In despite of the format used (certificates or > whatever), a TA deals with the verification of digital signatures. > > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > > Red.es - RedIRIS > The Spanish NREN > > e-mail: diego.lopez@rediris.es > jid: drlopez@im.rediris.es > Tel: +34 955 056 621 > Mobile: +34 669 898 094 > ----------------------------------------- > > ------_=_NextPart_001_01C7E36C.02BAED5C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Charter

Here's a variation that references digital = signatures:

A trust anchor represents an authoritative source of = one or more types of information.  Trust anchors are comprised of = a public key and associated data.  The public key is used to = verify digital signatures and the associated data is used to constrain = the types of information for which the trust anchor is = authoritative.  Relying parties use trust anchors to determine if = digitally signed information objects are valid by verifying digital = signatures using the trust anchor's public key and by enforcing the = constraints expressed in the associated data.  

> -----Original Message-----
> From: owner-ietf-trust-anchor@mail.vpnc.org =
> [mailto:owner-ietf-= trust-anchor@mail.vpnc.org] On Behalf Of
> Diego R. Lopez
> Sent: Monday, August 20, 2007 2:40 PM
> To: ietf-trust-anchor@vpnc.org
> Subject: Re: Draft Charter
>
>
>
> On 20 Aug 2007, at 19:49, Stephen Kent = wrote:
> > At 12:09 PM -0400 8/18/07, Turner, Sean P. = wrote:
> >> ...
> >>
> >> The glossary's definition had more in = the 1st sentence which
> >> basically said what the suggested = second sentence said - so I get
> >> your point about mushy fruit. I agree = that the authority
> is a central
> >> concept to TAM and that's what I was = alluding to with my context
> >> comment.  I think it ought to be = in the definition.  How about:
> >>
> >> A trust anchor is a public key and = associated data that
> represents an
> >> authoritative source of some type of = information. 
> Associated data is
> >> used to define the scope of the use of = the trust anchor
> including the
> >> authorized type of information.
> >  I still find this too mushy :-). I'd = like to see some mention of
> > digital signatures in the definition. That = seems to be an essential
> > feature of TAs, irrespective of the use of = certs (of any type) vs.
> > raw keys.
>
> Ditto. In despite of the format used = (certificates or
> whatever), a TA deals with the verification of = digital signatures.
>
>
>
> --
> "Esta vez no fallaremos, Doctor = Infierno"
>
> Dr Diego R. Lopez
>
> Red.es - RedIRIS
> The Spanish NREN
>
> e-mail: diego.lopez@rediris.es
> jid:    = drlopez@im.rediris.es
> Tel:    +34 955 056 621
> Mobile: +34 669 898 094
> = -----------------------------------------
>
>

------_=_NextPart_001_01C7E36C.02BAED5C-- From owner-ietf-trust-anchor Mon Aug 20 17:07: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 l7L076wV079242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 17:07: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 l7L076xB079241; Mon, 20 Aug 2007 17:07: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7L073Fw079224 for ; Mon, 20 Aug 2007 17:07:05 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.77.11.99]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1INHGw-0007lI-4X; Mon, 20 Aug 2007 20:07:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> Date: Mon, 20 Aug 2007 20:05:07 -0400 To: Carl Wallace From: Stephen Kent Subject: RE: Draft Charter 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 4:52 PM -0400 8/20/07, Carl Wallace wrote: >Here's a variation that references digital signatures: > >A trust anchor represents an authoritative source of one or more >types of information. Trust anchors are comprised of a public key >and associated data. The public key is used to verify digital >signatures and the associated data is used to constrain the types of >information for which the trust anchor is authoritative. Relying >parties use trust anchors to determine if digitally signed >information objects are valid by verifying digital signatures using >the trust anchor's public key and by enforcing the constraints >expressed in the associated data. > Carl, That's much better, but I don't see why the first sentence has to be so broad. How about: "A trust anchor represents an authoritative entity represented by a public key and associated data." Steve From owner-ietf-trust-anchor Mon Aug 20 17:44: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 l7L0iPIl082904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 17:44: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 l7L0iPQ0082903; Mon, 20 Aug 2007 17:44: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 mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7L0iNE3082893 for ; Mon, 20 Aug 2007 17:44:24 -0700 (MST) (envelope-from franks@mcs.anl.gov) Received: from FranksPB.local (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id l7L0iCN149240; Mon, 20 Aug 2007 19:44:12 -0500 Message-ID: <46CA355A.6040704@mcs.anl.gov> Date: Mon, 20 Aug 2007 17:44:10 -0700 From: Frank Siebenlist User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Stephen Kent CC: Carl Wallace , ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Why do we need the emphasis on "public key" and "digitally signing" with respect to trust anchors? I can think of trust anchors that could be identified through a kerberos principal name or a DN, and online trust anchors that can be queried for info over an authenticated tls connection... -Frank. Stephen Kent wrote: > > At 4:52 PM -0400 8/20/07, Carl Wallace wrote: >> Here's a variation that references digital signatures: >> >> A trust anchor represents an authoritative source of one or more types >> of information. Trust anchors are comprised of a public key and >> associated data. The public key is used to verify digital signatures >> and the associated data is used to constrain the types of information >> for which the trust anchor is authoritative. Relying parties use >> trust anchors to determine if digitally signed information objects are >> valid by verifying digital signatures using the trust anchor's public >> key and by enforcing the constraints expressed in the associated data. > > > Carl, > > That's much better, but I don't see why the first sentence has to be so > broad. How about: "A trust anchor represents an authoritative entity > represented by a public key and associated data." > > Steve > -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory From owner-ietf-trust-anchor Mon Aug 20 18:27: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 l7L1RCqO086842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 18:27: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 l7L1RCP0086841; Mon, 20 Aug 2007 18:27: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7L1RBkQ086834 for ; Mon, 20 Aug 2007 18:27:12 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.77.11.99]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1INIWU-0000Q7-41; Mon, 20 Aug 2007 21:27:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <46CA355A.6040704@mcs.anl.gov> References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> Date: Mon, 20 Aug 2007 21:26:52 -0400 To: Frank Siebenlist From: Stephen Kent Subject: Re: Draft Charter Cc: Carl Wallace , 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 5:44 PM -0700 8/20/07, Frank Siebenlist wrote: >Why do we need the emphasis on "public key" and "digitally signing" with >respect to trust anchors? > >I can think of trust anchors that could be identified through a kerberos >principal name or a DN, and online trust anchors that can be queried for >info over an authenticated tls connection... > >-Frank. Frank, The notion of trust anchors has been, for the last 15 years or so, a purely public key notion. So yes, I would argue that if we want to work on what it going to be called a trust anchor management protocol, it needs to be based on public keys and signature validation. If folks want to do something else, make up a new name, this one is taken :-). Steve From owner-ietf-trust-anchor Mon Aug 20 19:39: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 l7L2daqt091250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 19:39: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 l7L2daWH091249; Mon, 20 Aug 2007 19:39: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 [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 l7L2dKak091233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 19:39:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> Date: Mon, 20 Aug 2007 19:38:51 -0700 To: Stephen Kent , Frank Siebenlist From: Paul Hoffman Subject: Re: Draft Charter Cc: Carl Wallace , 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:26 PM -0400 8/20/07, Stephen Kent wrote: >The notion of trust anchors has been, for the last 15 years or so, a >purely public key notion. So yes, I would argue that if we want to >work on what it going to be called a trust anchor management >protocol, it needs to be based on public keys and signature >validation. If folks want to do something else, make up a new name, >this one is taken :-). I agree with Steve. Everyone involved so far has been talking about public keys, which if nothing else shows that this is the common theme. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Mon Aug 20 22:39: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 l7L5dgaD004630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 22:39: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 l7L5dgSq004629; Mon, 20 Aug 2007 22:39: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 mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7L5dfIx004604; Mon, 20 Aug 2007 22:39:41 -0700 (MST) (envelope-from franks@mcs.anl.gov) Received: from FranksPB.local (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id l7L5ddN19728; Tue, 21 Aug 2007 00:39:39 -0500 Message-ID: <46CA7A99.8010103@mcs.anl.gov> Date: Mon, 20 Aug 2007 22:39:37 -0700 From: Frank Siebenlist User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Paul Hoffman CC: Stephen Kent , Carl Wallace , ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Too bad as in general the overall policy enforcement requires other "trust anchors", "roots of trust", "assertion authorities", to be pre-configured, like attribute- and authorization authorities. Furthermore, it also would disallow the use of other authentication and key exchange mechanism to bootstrap from, like secure-password/shared-secret protocols with online CAs, in which case there would be no need for any trust-anchor's public key and no digital signature. Just to support x509/pkix style identity certs based on only public keys and only dsigs makes it just as "useful" as x509/pkix... maybe this trust-anchor protocol shouldn't deserve its own wg and should instead be used to "revive" pkix as it clearly deals with a deficiency not addressed in pkix's gazillion rfcs ;-) -FS. Paul Hoffman wrote: > At 9:26 PM -0400 8/20/07, Stephen Kent wrote: >> The notion of trust anchors has been, for the last 15 years or so, a >> purely public key notion. So yes, I would argue that if we want to >> work on what it going to be called a trust anchor management protocol, >> it needs to be based on public keys and signature validation. If >> folks want to do something else, make up a new name, this one is taken >> :-). > > I agree with Steve. Everyone involved so far has been talking about > public keys, which if nothing else shows that this is the common theme. > > --Paul Hoffman, Director > --VPN Consortium > -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory From owner-ietf-trust-anchor Tue Aug 21 04:30: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 l7LBUCn0042892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 04:30: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 l7LBUCCh042891; Tue, 21 Aug 2007 04:30: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 l7LBUBoZ042884 for ; Tue, 21 Aug 2007 04:30: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: Draft Charter Date: Tue, 21 Aug 2007 04:31:14 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> In-Reply-To: <46CA7A99.8010103@mcs.anl.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Charter Thread-Index: AcfjuOSa8DlUkOL7Tme0cYhlM8TNfQALy24g References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> From: "Santosh Chokhani" To: "Frank Siebenlist" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7LBUCoZ042886 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank, I agree with Steve. I will be willing to expand the notion a bit. But, in my thinking this deals with cryptographic protocols. These protocols require a public or secret key to establish the trust for authentication and integrity checks. Thus, it must be a key. As it so happens, we have been dealing with PKI related matters and hence the starting key for authentication and integrity is a public key. In short, any idea for trust anchor that does not deal with a crypto key is a loser from crypto viewpoint. -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Frank Siebenlist Sent: Tuesday, August 21, 2007 1:40 AM To: Paul Hoffman Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter Too bad as in general the overall policy enforcement requires other "trust anchors", "roots of trust", "assertion authorities", to be pre-configured, like attribute- and authorization authorities. Furthermore, it also would disallow the use of other authentication and key exchange mechanism to bootstrap from, like secure-password/shared-secret protocols with online CAs, in which case there would be no need for any trust-anchor's public key and no digital signature. Just to support x509/pkix style identity certs based on only public keys and only dsigs makes it just as "useful" as x509/pkix... maybe this trust-anchor protocol shouldn't deserve its own wg and should instead be used to "revive" pkix as it clearly deals with a deficiency not addressed in pkix's gazillion rfcs ;-) -FS. Paul Hoffman wrote: > At 9:26 PM -0400 8/20/07, Stephen Kent wrote: >> The notion of trust anchors has been, for the last 15 years or so, a >> purely public key notion. So yes, I would argue that if we want to >> work on what it going to be called a trust anchor management protocol, >> it needs to be based on public keys and signature validation. If >> folks want to do something else, make up a new name, this one is taken >> :-). > > I agree with Steve. Everyone involved so far has been talking about > public keys, which if nothing else shows that this is the common theme. > > --Paul Hoffman, Director > --VPN Consortium > -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory From owner-ietf-trust-anchor Tue Aug 21 08:12: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 l7LFC2Ko072267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 08:12: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 l7LFC2t5072266; Tue, 21 Aug 2007 08:12: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 mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LFC1XN072254 for ; Tue, 21 Aug 2007 08:12:01 -0700 (MST) (envelope-from franks@mcs.anl.gov) Received: from FranksPB.local (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id l7LFBwN105204; Tue, 21 Aug 2007 10:11:58 -0500 Message-ID: <46CB00BC.8020700@mcs.anl.gov> Date: Tue, 21 Aug 2007 08:11:56 -0700 From: Frank Siebenlist User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Santosh Chokhani CC: ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> In-Reply-To: <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In our deployments, we see more and more that PKI is not the primary authentication mechanism and that online-CAs are used to obtain pk-credentials, which means that this pki-trust is derived from other already pre-configured primary authentication mechanisms, like shared secrets, username/password, kerberos, OTP, etc. In those cases, there already are ways to establish a secure authenticated communication context with a trust-anchor provisioning service, and the requirement to use only public key and dsig is not very "helpful" in those scenarios. -FS. Santosh Chokhani wrote: > Frank, > > I agree with Steve. I will be willing to expand the notion a bit. But, > in my thinking this deals with cryptographic protocols. These protocols > require a public or secret key to establish the trust for authentication > and integrity checks. Thus, it must be a key. As it so happens, we > have been dealing with PKI related matters and hence the starting key > for authentication and integrity is a public key. > > In short, any idea for trust anchor that does not deal with a crypto key > is a loser from crypto viewpoint. > > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Frank > Siebenlist > Sent: Tuesday, August 21, 2007 1:40 AM > To: Paul Hoffman > Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor@vpnc.org > Subject: Re: Draft Charter > > > Too bad as in general the overall policy enforcement requires other > "trust anchors", "roots of trust", "assertion authorities", to be > pre-configured, like attribute- and authorization authorities. > > Furthermore, it also would disallow the use of other authentication and > key exchange mechanism to bootstrap from, like > secure-password/shared-secret protocols with online CAs, in which case > there would be no need for any trust-anchor's public key and no digital > signature. > > Just to support x509/pkix style identity certs based on only public keys > and only dsigs makes it just as "useful" as x509/pkix... maybe this > trust-anchor protocol shouldn't deserve its own wg and should instead be > used to "revive" pkix as it clearly deals with a deficiency not > addressed in pkix's gazillion rfcs ;-) > > -FS. > > > > Paul Hoffman wrote: >> At 9:26 PM -0400 8/20/07, Stephen Kent wrote: >>> The notion of trust anchors has been, for the last 15 years or so, a >>> purely public key notion. So yes, I would argue that if we want to >>> work on what it going to be called a trust anchor management > protocol, >>> it needs to be based on public keys and signature validation. If >>> folks want to do something else, make up a new name, this one is > taken >>> :-). >> I agree with Steve. Everyone involved so far has been talking about >> public keys, which if nothing else shows that this is the common > theme. >> --Paul Hoffman, Director >> --VPN Consortium >> > -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory From owner-ietf-trust-anchor Tue Aug 21 11:29: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 l7LITFEP095268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 11:29: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 l7LITF6b095267; Tue, 21 Aug 2007 11:29: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7LITCLG095259 for ; Tue, 21 Aug 2007 11:29:14 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 11597 invoked from network); 21 Aug 2007 18:26:05 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Aug 2007 18:26:05 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 21 Aug 2007 18:26:04 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Tue, 21 Aug 2007 14:29:11 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31D740@scygmxs1.cygnacom.com> From: Carl Wallace To: Stephen Kent Cc: ietf-trust-anchor@vpnc.org Subject: RE: Draft Charter Date: Tue, 21 Aug 2007 14:29:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E421.2AAEE6D0" 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_01C7E421.2AAEE6D0 Content-Type: text/plain > Carl, > > That's much better, but I don't see why the first sentence > has to be so broad. How about: "A trust anchor represents an > authoritative entity represented by a public key and associated data." > > Steve > That works for me. Carl ------_=_NextPart_001_01C7E421.2AAEE6D0 Content-Type: text/html RE: Draft Charter

> Carl,
>
> That's much better, but I don't see why the first sentence
> has to be so broad.  How about: "A trust anchor represents an
> authoritative entity represented by a public key and associated data."
>
> Steve
>

That works for me.

Carl

------_=_NextPart_001_01C7E421.2AAEE6D0-- From owner-ietf-trust-anchor Tue Aug 21 12:08: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 l7LJ8EWV098937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 12:08: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 l7LJ8Emo098935; Tue, 21 Aug 2007 12:08: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 smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7LJ8Cln098924 for ; Tue, 21 Aug 2007 12:08:12 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 46181 invoked from network); 21 Aug 2007 19:08:06 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.2.163 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 21 Aug 2007 19:08:06 -0000 X-YMail-OSG: _52kMcEVM1kux_ExvE5zsUhacc443A4yfjgbaI0CBUEOTyqWVX.iXdw5VIEFMHriHic6lV_gZaZfl7hN_8ah0ogArqSOXrduQtt74cq4Urlc3vKzQWv7z5kxg.atVKopjvnT0ROf3JLlObk- From: "Turner, Sean P." To: Subject: Revised draft charter Date: Tue, 21 Aug 2007 15:08:36 -0400 Organization: IECA, Inc. Message-ID: <004901c7e426$ad24f8c0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004A_01C7E405.261358C0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfkJqy8EKiV6MQmTEK5geef+zoZqg== 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_000_004A_01C7E405.261358C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Attached is an updated version of the draft charter. It incorporates comments sent to the list. spt ------=_NextPart_000_004A_01C7E405.261358C0 Content-Type: text/plain; name="charter-02.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="charter-02.txt" Strawman charter for trust anchor management (tam) Version: 02, August 16th 2007 Chair(s)=20 TBD Security Area Director(s): - Tim Polk - Sam Hartman Security Area Advisor: TBD Mailing Lists: General Discussion: ietf-trust-anchor@vpnc.org To Subscribe: http://www.vpnc.org/ietf-trust-anchor/ Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/ Description of Working Group: The need for a standard protocol for trust anchor management has been = recognized for some time. Many groups within the IETF, including PKIX, = Kerberos, TLS and SIDR have a dependency on trust anchors, yet provide = no generic mechanism for the their management. A trust anchor represents an authoritative entity represented by a = public key and associated data. Trust anchors are comprised of a public = key and associated data. The public key is used to verify digital = signatures and the associated data is used to constrain the types of = information for which the trust anchor is authoritative. Relying = parties use trust anchors to determine if digitally signed information = objects are valid by verifying digital signatures using the trust = anchor's public key and by enforcing the constraints expressed in the = associated data. Despite the wide-spread use of trust anchors, there is no standard means = for managing these security-critical data. This Working Group will = develop a specification to fill this gap. The initial problem statement for this work is to be based on: - draft-wallace-ta-mgmt-problem-statement The scope of the work is to include: - Supporting a single trust anchor administrator, such as in a typical = enterprise, who may be administering multiple trust anchors in her = domain - Supporting multiple trust anchor administrators, such as is typical = for home users - Supporting systems with limited or no user interface - Supporting devices that may or many not be connected to the Internet = at the time of management (e.g., physical delivery) The following are out of scope of this work: - Supporting systems with limited or no user interface - Supporting devices that may or many not be connected to the Internet = at the time of management The deliverables will be: - An informational problem statement/requirements specification for a = trust anchor management protocol - A standards track trust anchor management protocol specification Goals and Milestones: +6 months WG last call on problem statement/requirements +9 months Adoption of WG draft protocol spec. +15 months WG last call for protocol spec. ------=_NextPart_000_004A_01C7E405.261358C0-- From owner-ietf-trust-anchor Tue Aug 21 14:35: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 l7LLZgAO012942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 14:35: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 l7LLZg7I012941; Tue, 21 Aug 2007 14:35: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 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 l7LLZfKL012934 for ; Tue, 21 Aug 2007 14:35:42 -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: Draft Charter Date: Tue, 21 Aug 2007 14:35:18 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87908E8722A@EXVS01.ex.dslextreme.net> In-Reply-To: <46CB00BC.8020700@mcs.anl.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Charter Thread-Index: AcfkBcYKXNPp5GOLQHKxMVOwR2rrYwANNB+w References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> <46CB00BC.8020700@mcs.anl.gov> From: "Santosh Chokhani" To: "Frank Siebenlist" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7LLZgKL012935 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank, In your scenario, it seems you do not need trust anchor albeit it is not clear how communication to online CA is secured and how trust is extended beyond on-line CA. You say, "In those cases, there already are ways to establish a secure authenticated communication context with a trust-anchor provisioning service". What is this trust-anchor provisioning service; what is trust anchor contents in your context; Is the trust anchor local, enterprise wide or covers multiple enterprises; and how do you (I assume meaning client or relying parties) establish secure authenticated communication with the trust-anchor provisioning service. -----Original Message----- From: Frank Siebenlist [mailto:franks@mcs.anl.gov] Sent: Tuesday, August 21, 2007 11:12 AM To: Santosh Chokhani Cc: ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter In our deployments, we see more and more that PKI is not the primary authentication mechanism and that online-CAs are used to obtain pk-credentials, which means that this pki-trust is derived from other already pre-configured primary authentication mechanisms, like shared secrets, username/password, kerberos, OTP, etc. In those cases, there already are ways to establish a secure authenticated communication context with a trust-anchor provisioning service, and the requirement to use only public key and dsig is not very "helpful" in those scenarios. -FS. Santosh Chokhani wrote: > Frank, > > I agree with Steve. I will be willing to expand the notion a bit. But, > in my thinking this deals with cryptographic protocols. These protocols > require a public or secret key to establish the trust for authentication > and integrity checks. Thus, it must be a key. As it so happens, we > have been dealing with PKI related matters and hence the starting key > for authentication and integrity is a public key. > > In short, any idea for trust anchor that does not deal with a crypto key > is a loser from crypto viewpoint. > > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Frank > Siebenlist > Sent: Tuesday, August 21, 2007 1:40 AM > To: Paul Hoffman > Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor@vpnc.org > Subject: Re: Draft Charter > > > Too bad as in general the overall policy enforcement requires other > "trust anchors", "roots of trust", "assertion authorities", to be > pre-configured, like attribute- and authorization authorities. > > Furthermore, it also would disallow the use of other authentication and > key exchange mechanism to bootstrap from, like > secure-password/shared-secret protocols with online CAs, in which case > there would be no need for any trust-anchor's public key and no digital > signature. > > Just to support x509/pkix style identity certs based on only public keys > and only dsigs makes it just as "useful" as x509/pkix... maybe this > trust-anchor protocol shouldn't deserve its own wg and should instead be > used to "revive" pkix as it clearly deals with a deficiency not > addressed in pkix's gazillion rfcs ;-) > > -FS. > > > > Paul Hoffman wrote: >> At 9:26 PM -0400 8/20/07, Stephen Kent wrote: >>> The notion of trust anchors has been, for the last 15 years or so, a >>> purely public key notion. So yes, I would argue that if we want to >>> work on what it going to be called a trust anchor management > protocol, >>> it needs to be based on public keys and signature validation. If >>> folks want to do something else, make up a new name, this one is > taken >>> :-). >> I agree with Steve. Everyone involved so far has been talking about >> public keys, which if nothing else shows that this is the common > theme. >> --Paul Hoffman, Director >> --VPN Consortium >> > -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory From owner-ietf-trust-anchor Tue Aug 21 15:26: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 l7LMQA94016117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 15:26: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 l7LMQAS8016116; Tue, 21 Aug 2007 15:26: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 michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LMQ7Du016110 for ; Tue, 21 Aug 2007 15:26:09 -0700 (MST) (envelope-from ynir@checkpoint.com) Received: from [172.31.21.132] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l7LML4RL012196; Wed, 22 Aug 2007 01:21:04 +0300 (IDT) In-Reply-To: <004901c7e426$ad24f8c0$0301a8c0@Wylie> References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4AAE3537-5583-4AA7-BCB6-746564B9723A@checkpoint.com> Cc: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: Revised draft charter Date: Wed, 22 Aug 2007 01:20:54 +0300 To: "Turner, Sean P." X-Mailer: Apple Mail (2.752.3) Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Two comments: 1. "Supporting multiple trust anchor administrators, such as is typical for home users" - I would not say that the typical home user has multiple TAAs. From the discussion here it's not even clear if there is a real case for multiple TAAs. I would just drop everything after the comma. 2. I suggest we add to the list of deliverables a document (TBD if it should be standards track, informational or BCP) that specifies the operations of a trust anchor store. I think all the debate here shows that this is a large enough can of worms to warrant a separate document, rather than including a section in the protocol document. Yoav On Aug 21, 2007, at 10:08 PM, Turner, Sean P. wrote: > Attached is an updated version of the draft charter. It incorporates > comments sent to the list. > > spt > > From owner-ietf-trust-anchor Tue Aug 21 15: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 l7LMPQGx016085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 15: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 l7LMPQRv016084; Tue, 21 Aug 2007 15: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 mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LMPPmv016077 for ; Tue, 21 Aug 2007 15:25:25 -0700 (MST) (envelope-from franks@mcs.anl.gov) Received: from FranksPB.local (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id l7LMP6N145468; Tue, 21 Aug 2007 17:25:06 -0500 Message-ID: <46CB6641.5050204@mcs.anl.gov> Date: Tue, 21 Aug 2007 15:25:05 -0700 From: Frank Siebenlist User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Santosh Chokhani CC: ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> <46CB00BC.8020700@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E8722A@EXVS01.ex.dslextreme.net> In-Reply-To: <82D5657AE1F54347A734BDD33637C87908E8722A@EXVS01.ex.dslextreme.net> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Two scenarios: * Kerberos is already deployed, which implies that any all principals can communicate securely with each other. Through a Kerberized Certificate Authority, a user can obtain short-lived certs. It could also obtain all the trust root info from another kerberized service, including all the root CAs that can be trusted outside of that domain (not implemented yet...). No need for any pre-configured public key on the clients, and no need for dsig. (kx509/KCA; http://www.citi.umich.edu/projects/kerb_pki/) * Use TLS with a pre-shared secret and key-exchange authentication protocol, which doesn't require any server cert or pre-configured public key for the mutually-authenticated trust establishment. Use this primary authN mechanism to front-end an online-CA and trust-root provisioning service, and again no need for any pre-configured public key, and no need for dsig. http://www.rfc-zone.org/rfc4279.html (or the SRP/AuthA equivalent) Myproxy is a good example of a credential issuing service that can work as an online-CA, has a pluggable primary authentication (no pre-shared secret support yet...), and transparent provisioning capabilities. (http://grid.ncsa.uiuc.edu/myproxy/) Another example is caBIG's Grid Trust Service (GTS), which is such a trust-root provisioning service that relies on a pre-configured public-key/x509cert (but we plan/dream to enhance it in the future to support other bootstrapping mechanisms) (http://www.cagrid.org/mwiki/index.php?title=GTS:Main) In all cases, we would like to standardize the trust root provisioning protocol without having to mandate any boots-trapping public key. Just having the message exchange protocol with standardized formats for the trust-anchor info including meta-data for the anchor's issuing constraints would be great. The security mechanism to use relies on the pre-configured shared-secrets/OTP/Kerberos/password/public-key, and should not be mandated IMHO. Hope that explains. -Frank. Santosh Chokhani wrote: > Frank, > > In your scenario, it seems you do not need trust anchor albeit it is not > clear how communication to online CA is secured and how trust is > extended beyond on-line CA. > > You say, "In those cases, there already are ways to establish a secure > authenticated communication context with a trust-anchor provisioning > service". What is this trust-anchor provisioning service; what is trust > anchor contents in your context; Is the trust anchor local, enterprise > wide or covers multiple enterprises; and how do you (I assume meaning > client or relying parties) establish secure authenticated communication > with the trust-anchor provisioning service. > > -----Original Message----- > From: Frank Siebenlist [mailto:franks@mcs.anl.gov] > Sent: Tuesday, August 21, 2007 11:12 AM > To: Santosh Chokhani > Cc: ietf-trust-anchor@vpnc.org > Subject: Re: Draft Charter > > In our deployments, we see more and more that PKI is not the primary > authentication mechanism and that online-CAs are used to obtain > pk-credentials, which means that this pki-trust is derived from other > already pre-configured primary authentication mechanisms, like shared > secrets, username/password, kerberos, OTP, etc. > > In those cases, there already are ways to establish a secure > authenticated communication context with a trust-anchor provisioning > service, and the requirement to use only public key and dsig is not very > "helpful" in those scenarios. > > -FS. > > > Santosh Chokhani wrote: >> Frank, >> >> I agree with Steve. I will be willing to expand the notion a bit. > But, >> in my thinking this deals with cryptographic protocols. These > protocols >> require a public or secret key to establish the trust for > authentication >> and integrity checks. Thus, it must be a key. As it so happens, we >> have been dealing with PKI related matters and hence the starting key >> for authentication and integrity is a public key. >> >> In short, any idea for trust anchor that does not deal with a crypto > key >> is a loser from crypto viewpoint. >> >> -----Original Message----- >> From: owner-ietf-trust-anchor@mail.vpnc.org >> [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Frank >> Siebenlist >> Sent: Tuesday, August 21, 2007 1:40 AM >> To: Paul Hoffman >> Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor@vpnc.org >> Subject: Re: Draft Charter >> >> >> Too bad as in general the overall policy enforcement requires other >> "trust anchors", "roots of trust", "assertion authorities", to be >> pre-configured, like attribute- and authorization authorities. >> >> Furthermore, it also would disallow the use of other authentication > and >> key exchange mechanism to bootstrap from, like >> secure-password/shared-secret protocols with online CAs, in which case >> there would be no need for any trust-anchor's public key and no > digital >> signature. >> >> Just to support x509/pkix style identity certs based on only public > keys >> and only dsigs makes it just as "useful" as x509/pkix... maybe this >> trust-anchor protocol shouldn't deserve its own wg and should instead > be >> used to "revive" pkix as it clearly deals with a deficiency not >> addressed in pkix's gazillion rfcs ;-) >> >> -FS. >> >> >> >> Paul Hoffman wrote: >>> At 9:26 PM -0400 8/20/07, Stephen Kent wrote: >>>> The notion of trust anchors has been, for the last 15 years or so, a >>>> purely public key notion. So yes, I would argue that if we want to >>>> work on what it going to be called a trust anchor management >> protocol, >>>> it needs to be based on public keys and signature validation. If >>>> folks want to do something else, make up a new name, this one is >> taken >>>> :-). >>> I agree with Steve. Everyone involved so far has been talking about >>> public keys, which if nothing else shows that this is the common >> theme. >>> --Paul Hoffman, Director >>> --VPN Consortium >>> > -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory From owner-ietf-trust-anchor Tue Aug 21 16:13: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 l7LNDDTF020430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 16:13: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 l7LNDDVe020429; Tue, 21 Aug 2007 16:13: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 [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 l7LND6Am020417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 16:13:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4AAE3537-5583-4AA7-BCB6-746564B9723A@checkpoint.com> References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> <4AAE3537-5583-4AA7-BCB6-746564B9723A@checkpoint.com> Date: Tue, 21 Aug 2007 16:11:34 -0700 To: Yoav Nir , "Turner, Sean P." From: Paul Hoffman Subject: Re: Revised draft charter 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 1:20 AM +0300 8/22/07, Yoav Nir wrote: >Two comments: > >1. "Supporting multiple trust anchor administrators, such as is >typical for home users" - I would not say that the typical home >user has multiple TAAs. From the discussion here it's not even clear >if there is a real case for multiple TAAs. I would just drop >everything after the comma. Agree. The "home users" bit still sticks out. There are many scenarios for multiple trust anchor administrators. I brought up a few in Chicago, and people at the mic give more. The above scope item might instead read: - Supporting multiple trust anchor administrators, each of whom is independent >2. I suggest we add to the list of deliverables a document (TBD if >it should be standards track, informational or BCP) that specifies >the operations of a trust anchor store. I think all the debate here >shows that this is a large enough can of worms to warrant a separate >document, rather than including a section in the protocol document. Fully disagree. That is not an interoperability issue. Having said that, I think it is fine for someone to do that as an individual submission. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Aug 21 16: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 l7LNSZs5021430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 16: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 l7LNSZZ0021429; Tue, 21 Aug 2007 16:28: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 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 l7LNSTad021413 for ; Tue, 21 Aug 2007 16:28:33 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 61810 invoked from network); 21 Aug 2007 23:28:21 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.40.10 with login) by smtp101.biz.mail.re2.yahoo.com with SMTP; 21 Aug 2007 23:28:21 -0000 X-YMail-OSG: H5RHD74VM1mTthE.Q7GK7nPcWqgLCz5KuxTmkSKprKPXY8WrwYR6CFeJPSIuVAKdAYiq5riuzLUza29RhK6yx.WwDSKsX8ymOwKLBOFkXi6leGjUcv3vtAXbvZ_k1mYbPoNKNs7EeMtQHso- From: "Turner, Sean P." To: References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> Subject: RE: Revised draft charter (redux) Date: Tue, 21 Aug 2007 19:28:51 -0400 Organization: IECA, Inc. Message-ID: <000c01c7e44b$083464c0$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: <004901c7e426$ad24f8c0$0301a8c0@Wylie> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfkJqy8EKiV6MQmTEK5geef+zoZqgAIzHPg Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It's been brought to my attention that I messed up the scope items. Here's an updated draft. -------------------------------------------- Strawman charter for trust anchor management (tam) Version: 03, August 21st 2007 Chair(s) TBD Security Area Director(s): - Tim Polk - Sam Hartman Security Area Advisor: TBD Mailing Lists: General Discussion: ietf-trust-anchor@vpnc.org To Subscribe: http://www.vpnc.org/ietf-trust-anchor/ Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/ Description of Working Group: The need for a standard protocol for trust anchor management has been recognized for some time. Many groups within the IETF, including PKIX, Kerberos, TLS and SIDR have a dependency on trust anchors, yet provide no generic mechanism for the their management. A trust anchor represents an authoritative entity represented by a public key and associated data. Trust anchors are comprised of a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. Relying parties use trust anchors to determine if digitally signed information objects are valid by verifying digital signatures using the trust anchor's public key and by enforcing the constraints expressed in the associated data. Despite the wide-spread use of trust anchors, there is no standard means for managing these security-critical data. This Working Group will develop a specification to fill this gap. The initial problem statement for this work is to be based on: - draft-wallace-ta-mgmt-problem-statement The scope of the work is to include: - Supporting a single trust anchor administrator, such as in a typical enterprise, who may be administering multiple trust anchors in her domain - Supporting multiple trust anchor administrators, each of whom is independant - Supporting systems with limited or no user interface - Supporting devices that may or many not be connected to the Internet at the time of management (e.g., physical delivery) - Supporting systems with limited or no user interface - Supporting devices that may or many not be connected to the Internet at the time of management The following were suggested as out of scope: - Management of non-anchor signature validation objects such as intermediate certificates in a validation path. - Mandating whether the recipient of trust anchors from a trust anchor manager will use those anchors The deliverables will be: - An informational problem statement/requirements specification for a trust anchor management protocol - A standards track trust anchor management protocol specification Goals and Milestones: +6 months WG last call on problem statement/requirements +9 months Adoption of WG draft protocol spec. +15 months WG last call for protocol spec. From owner-ietf-trust-anchor Tue Aug 21 16:29: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 l7LNTqrb021503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 16:29: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 l7LNTqbe021502; Tue, 21 Aug 2007 16:29: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LNTof5021483 for ; Tue, 21 Aug 2007 16:29:50 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.130.222]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1INdAT-0006sY-3R; Tue, 21 Aug 2007 19:29:49 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <46CB00BC.8020700@mcs.anl.gov> References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> <46CB00BC.8020700@mcs.anl.gov> Date: Tue, 21 Aug 2007 19:24:29 -0400 To: Frank Siebenlist From: Stephen Kent Subject: Re: Draft Charter Cc: 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:11 AM -0700 8/21/07, Frank Siebenlist wrote: >In our deployments, we see more and more that PKI is not the primary >authentication mechanism and that online-CAs are used to obtain >pk-credentials, which means that this pki-trust is derived from other >already pre-configured primary authentication mechanisms, like shared >secrets, username/password, kerberos, OTP, etc. I believe your experience is an accurate characterization for the grid computing community, but not most other communities who make use of PKI. Steve From owner-ietf-trust-anchor Tue Aug 21 16:31: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 l7LNVYGr021672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 16:31: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 l7LNVXdQ021671; Tue, 21 Aug 2007 16:31: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 mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LNVRw9021662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Aug 2007 16:31:33 -0700 (MST) (envelope-from Black_David@emc.com) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7LNVKlW008008; Tue, 21 Aug 2007 19:31:20 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7LNUbCG004250; Tue, 21 Aug 2007 19:31:16 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 19:30:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Draft Charter Date: Tue, 21 Aug 2007 19:30:20 -0400 Message-ID: In-Reply-To: <46CB6641.5050204@mcs.anl.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Charter Thread-Index: AcfkQo552vCCJF2HRD2uF7ur/RoRqQAATcFQ References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> <46CB00BC.8020700@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E8722A@EXVS01.ex.dslextreme.net> <46CB6641.5050204@mcs.anl.gov> To: Cc: X-OriginalArrivalTime: 21 Aug 2007 23:30:21.0538 (UTC) FILETIME=[3DE3FC20:01C7E44B] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7LNVXw8021666 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > In all cases, we would like to standardize the trust root provisioning > protocol without having to mandate any boots-trapping public key. Just > having the message exchange protocol with standardized formats for the > trust-anchor info including meta-data for the anchor's issuing > constraints would be great. The security mechanism to use relies on the > pre-configured shared-secrets/OTP/Kerberos/password/public-key, and > should not be mandated IMHO. If this is primarily about bootstrapping, it concerns only the TSAs (Trust Store Anchors), and it looks like Frank would like it to be possible for them to be something other than public keys, while the actual application trust anchors provisioned into the trust stores would be public keys. In all the scenarios Frank outlines, the trust anchor management has to be online - the trust anchor operations have to come down the secure channel that was authenticated by non-PKI means (i.e., store and forward via something like a USB key is a non-starter - digital signatures are needed for that sort of scenario). With this restriction, I could envision a TSA being a Kerberos realm and principal. OTOH, I'm not enthusiastic about pre-shared secret (e.g., for TLS) and pluggable authentication because the notion of identity of the TSA is unclear. I think requiring the TAA to have a public/private key pair is reasonable, and then the bootstrapping mechanism for these cases would be: 1) Set up a secure channel authenticated by some means (sneaker-net if necessary). 2) Get the TAA's public key and install that as the TSA. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: owner-ietf-trust-anchor@mail.vpnc.org > [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of > Frank Siebenlist > Sent: Tuesday, August 21, 2007 6:25 PM > To: Santosh Chokhani > Cc: ietf-trust-anchor@vpnc.org > Subject: Re: Draft Charter > > > Two scenarios: > > * Kerberos is already deployed, which implies that any all principals > can communicate securely with each other. Through a Kerberized > Certificate Authority, a user can obtain short-lived certs. It could > also obtain all the trust root info from another kerberized service, > including all the root CAs that can be trusted outside of that domain > (not implemented yet...). No need for any pre-configured public key on > the clients, and no need for dsig. > (kx509/KCA; http://www.citi.umich.edu/projects/kerb_pki/) > > * Use TLS with a pre-shared secret and key-exchange authentication > protocol, which doesn't require any server cert or pre-configured public > key for the mutually-authenticated trust establishment. Use this primary > authN mechanism to front-end an online-CA and trust-root provisioning > service, and again no need for any pre-configured public key, and no > need for dsig. > http://www.rfc-zone.org/rfc4279.html (or the SRP/AuthA equivalent) > Myproxy is a good example of a credential issuing service that can work > as an online-CA, has a pluggable primary authentication (no pre-shared > secret support yet...), and transparent provisioning capabilities. > (http://grid.ncsa.uiuc.edu/myproxy/) > Another example is caBIG's Grid Trust Service (GTS), which is such a > trust-root provisioning service that relies on a pre-configured > public-key/x509cert (but we plan/dream to enhance it in the future to > support other bootstrapping mechanisms) > (http://www.cagrid.org/mwiki/index.php?title=GTS:Main) > > In all cases, we would like to standardize the trust root provisioning > protocol without having to mandate any boots-trapping public key. Just > having the message exchange protocol with standardized formats for the > trust-anchor info including meta-data for the anchor's issuing > constraints would be great. The security mechanism to use relies on the > pre-configured shared-secrets/OTP/Kerberos/password/public-key, and > should not be mandated IMHO. > > Hope that explains. > > -Frank. > > > > > Santosh Chokhani wrote: > > Frank, > > > > In your scenario, it seems you do not need trust anchor albeit it is not > > clear how communication to online CA is secured and how trust is > > extended beyond on-line CA. > > > > You say, "In those cases, there already are ways to establish a secure > > authenticated communication context with a trust-anchor provisioning > > service". What is this trust-anchor provisioning service; what is trust > > anchor contents in your context; Is the trust anchor local, enterprise > > wide or covers multiple enterprises; and how do you (I assume meaning > > client or relying parties) establish secure authenticated communication > > with the trust-anchor provisioning service. > > > > -----Original Message----- > > From: Frank Siebenlist [mailto:franks@mcs.anl.gov] > > Sent: Tuesday, August 21, 2007 11:12 AM > > To: Santosh Chokhani > > Cc: ietf-trust-anchor@vpnc.org > > Subject: Re: Draft Charter > > > > In our deployments, we see more and more that PKI is not the primary > > authentication mechanism and that online-CAs are used to obtain > > pk-credentials, which means that this pki-trust is derived from other > > already pre-configured primary authentication mechanisms, like shared > > secrets, username/password, kerberos, OTP, etc. > > > > In those cases, there already are ways to establish a secure > > authenticated communication context with a trust-anchor provisioning > > service, and the requirement to use only public key and dsig is not very > > "helpful" in those scenarios. > > > > -FS. > > > > > > Santosh Chokhani wrote: > >> Frank, > >> > >> I agree with Steve. I will be willing to expand the notion a bit. But, > >> in my thinking this deals with cryptographic protocols. These protocols > >> require a public or secret key to establish the trust for authentication > >> and integrity checks. Thus, it must be a key. As it so happens, we > >> have been dealing with PKI related matters and hence the starting key > >> for authentication and integrity is a public key. > >> > >> In short, any idea for trust anchor that does not deal with a crypto key > >> is a loser from crypto viewpoint. > >> > >> -----Original Message----- > >> From: owner-ietf-trust-anchor@mail.vpnc.org > >> [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Frank > >> Siebenlist > >> Sent: Tuesday, August 21, 2007 1:40 AM > >> To: Paul Hoffman > >> Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor@vpnc.org > >> Subject: Re: Draft Charter > >> > >> > >> Too bad as in general the overall policy enforcement requires other > >> "trust anchors", "roots of trust", "assertion authorities", to be > >> pre-configured, like attribute- and authorization authorities. > >> > >> Furthermore, it also would disallow the use of other authentication and > >> key exchange mechanism to bootstrap from, like > >> secure-password/shared-secret protocols with online CAs, in which case > >> there would be no need for any trust-anchor's public key and no digital > >> signature. > >> > >> Just to support x509/pkix style identity certs based on only public keys > >> and only dsigs makes it just as "useful" as x509/pkix... maybe this > >> trust-anchor protocol shouldn't deserve its own wg and should instead be > >> used to "revive" pkix as it clearly deals with a deficiency not > >> addressed in pkix's gazillion rfcs ;-) > >> > >> -FS. > >> > >> > >> > >> Paul Hoffman wrote: > >>> At 9:26 PM -0400 8/20/07, Stephen Kent wrote: > >>>> The notion of trust anchors has been, for the last 15 years or so, a > >>>> purely public key notion. So yes, I would argue that if we want to > >>>> work on what it going to be called a trust anchor management protocol, > >>>> it needs to be based on public keys and signature validation. If > >>>> folks want to do something else, make up a new name, this one is taken > >>>> :-). > >>> I agree with Steve. Everyone involved so far has been talking about > >>> public keys, which if nothing else shows that this is the common > >> theme. > >>> --Paul Hoffman, Director > >>> --VPN Consortium > >>> > > > > -- > Frank Siebenlist franks@mcs.anl.gov > The Globus Alliance - Argonne National Laboratory > > > From owner-ietf-trust-anchor Tue Aug 21 16:29: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 l7LNTqwg021505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 16:29: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 l7LNTqQf021504; Tue, 21 Aug 2007 16:29: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LNTotB021484; Tue, 21 Aug 2007 16:29:50 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.130.222]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1INdAT-0006sY-5V; Tue, 21 Aug 2007 19:29:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <46CA7A99.8010103@mcs.anl.gov> References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> Date: Tue, 21 Aug 2007 19:28:18 -0400 To: Frank Siebenlist From: Stephen Kent Subject: Re: Draft Charter Cc: Paul Hoffman , Carl Wallace , 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:39 PM -0700 8/20/07, Frank Siebenlist wrote: >Too bad as in general the overall policy enforcement requires other >"trust anchors", "roots of trust", "assertion authorities", to be >pre-configured, like attribute- and authorization authorities. if we make the definition very general, we can include DHCP, since it clearly is a source of authority for data, e.g., first hop router, DNS server, ... Howeverm I don't think that is what most of the folks on this mailing list had in mind when they signed up for a discussion of trust anchor management. Steve From owner-ietf-trust-anchor Tue Aug 21 20:10: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 l7M3AhJ9036242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 20:10: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 l7M3AhZD036241; Tue, 21 Aug 2007 20:10: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 mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7M3AfRp036229 for ; Tue, 21 Aug 2007 20:10:42 -0700 (MST) (envelope-from franks@mcs.anl.gov) Received: from FranksPB.local (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id l7M3AVN98270; Tue, 21 Aug 2007 22:10:31 -0500 Message-ID: <46CBA924.3040604@mcs.anl.gov> Date: Tue, 21 Aug 2007 20:10:28 -0700 From: Frank Siebenlist User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Stephen Kent CC: Santosh Chokhani , ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> <46CB00BC.8020700@mcs.anl.gov> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen Kent wrote: > At 8:11 AM -0700 8/21/07, Frank Siebenlist wrote: >> In our deployments, we see more and more that PKI is not the primary >> authentication mechanism and that online-CAs are used to obtain >> pk-credentials, which means that this pki-trust is derived from other >> already pre-configured primary authentication mechanisms, like shared >> secrets, username/password, kerberos, OTP, etc. > > I believe your experience is an accurate characterization for the grid > computing community, but not most other communities who make use of PKI. Well...I wouldn't dismiss our experience too fast. The grid community has a lot of experience with the old fashion, heavy weight PKI infrastructure with "real" CAs issuing long-lived certs to users - probably more than most other commercial applications as the last time I checked real PKI never lived up to its promise (who are all those other communities that you are referring to ?). The reasons why there is a push towards online CAs is because the heavy administrative burden associated with running a double authN infrastructure, and because of security concerns. Our experience is that most organizations already have (at least...) one identity management systems in place, which is "never" based on PKI and they will not and cannot abandon that for a PKI. Being able to leverage an existing identity management system is very compelling. Lastly, issuing short-lived certs also removes the revocation issues; dealing with those was never a strong point of PKI (it actually leaves the revocation issue with the other Id management system). The security issue with long lived certs has to do with the fact that we cannot trust the desktops anymore because of all the compromises through worms, viruses, bots, etc. Storing private keys on desktops protected by pass-phrases is a loosing proposition and compromised keys are expensive from a revocation, recovery, and management point of view. So unless you can rely on smartcards for your private key store and signing, your deployment is saver and recovery is easier when you rely on passwords/OTP with onlineCAs+sortlived-certs. I wouldn't be surprised if the grid communities' pki-experience could be applied to many other communities in the (near) future, which would make it too bad if this effort wouldn't accommodate a more broader view on "PKI". -Frank. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory From owner-ietf-trust-anchor Tue Aug 21 20:29: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 l7M3Tgre037522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 20:29: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 l7M3TgGs037521; Tue, 21 Aug 2007 20:29: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 mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7M3TfhX037515 for ; Tue, 21 Aug 2007 20:29:41 -0700 (MST) (envelope-from franks@mcs.anl.gov) Received: from FranksPB.local (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id l7M3TbN129140; Tue, 21 Aug 2007 22:29:37 -0500 Message-ID: <46CBAD9E.2050307@mcs.anl.gov> Date: Tue, 21 Aug 2007 20:29:34 -0700 From: Frank Siebenlist User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Black_David@emc.com CC: ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> <46CB00BC.8020700@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E8722A@EXVS01.ex.dslextreme.net> <46CB6641.5050204@mcs.anl.gov> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Your "translation" sounds good ;-) I just don't understand your concern about tls with pre-shared secret - kerberos' security would be enhanced when it would deploy that for it's password-based authN+keyexchange - it seems to me like a better authN protocol to use for any password/OTP-based mechanism... Your solution: > 1) Set up a secure channel authenticated by some means > (sneaker-net if necessary). > 2) Get the TAA's public key and install that as the TSA. is less efficient and less secure (one more unnecessary chain) than simply using the already established security context to provision the client... -Frank. PS. Note that any of these online-PKIs which is derived/bootstrapped from another primary authN mechanism is less "trusted/secure" than that primary authN mechanism - it's up to the organization's policy whether that is "secure enough" for their deployment (...and in most cases it is). Black_David@emc.com wrote: >> In all cases, we would like to standardize the trust root provisioning >> protocol without having to mandate any boots-trapping public key. Just >> having the message exchange protocol with standardized formats for the >> trust-anchor info including meta-data for the anchor's issuing >> constraints would be great. The security mechanism to use relies on > the >> pre-configured shared-secrets/OTP/Kerberos/password/public-key, and >> should not be mandated IMHO. > > If this is primarily about bootstrapping, it concerns only the > TSAs (Trust Store Anchors), and it looks like Frank would like > it to be possible for them to be something other than public > keys, while the actual application trust anchors provisioned > into the trust stores would be public keys. > > In all the scenarios > Frank outlines, the trust anchor management has to be online - > the trust anchor operations have to come down the secure channel > that was authenticated by non-PKI means (i.e., store and forward > via something like a USB key is a non-starter - digital signatures > are needed for that sort of scenario). With this restriction, I > could envision a TSA being a Kerberos realm and principal. > > OTOH, I'm not enthusiastic about pre-shared secret (e.g., for > TLS) and pluggable authentication because the notion of identity > of the TSA is unclear. I think requiring the TAA to have a > public/private key pair is reasonable, and then the bootstrapping > mechanism for these cases would be: > 1) Set up a secure channel authenticated by some means > (sneaker-net if necessary). > 2) Get the TAA's public key and install that as the TSA. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > >> -----Original Message----- >> From: owner-ietf-trust-anchor@mail.vpnc.org >> [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of >> Frank Siebenlist >> Sent: Tuesday, August 21, 2007 6:25 PM >> To: Santosh Chokhani >> Cc: ietf-trust-anchor@vpnc.org >> Subject: Re: Draft Charter >> >> >> Two scenarios: >> >> * Kerberos is already deployed, which implies that any all principals >> can communicate securely with each other. Through a Kerberized >> Certificate Authority, a user can obtain short-lived certs. It could >> also obtain all the trust root info from another kerberized service, >> including all the root CAs that can be trusted outside of that domain >> (not implemented yet...). No need for any pre-configured public key on >> the clients, and no need for dsig. >> (kx509/KCA; http://www.citi.umich.edu/projects/kerb_pki/) >> >> * Use TLS with a pre-shared secret and key-exchange authentication >> protocol, which doesn't require any server cert or pre-configured > public >> key for the mutually-authenticated trust establishment. Use this > primary >> authN mechanism to front-end an online-CA and trust-root provisioning >> service, and again no need for any pre-configured public key, and no >> need for dsig. >> http://www.rfc-zone.org/rfc4279.html (or the SRP/AuthA equivalent) >> Myproxy is a good example of a credential issuing service that can > work >> as an online-CA, has a pluggable primary authentication (no pre-shared >> secret support yet...), and transparent provisioning capabilities. >> (http://grid.ncsa.uiuc.edu/myproxy/) >> Another example is caBIG's Grid Trust Service (GTS), which is such a >> trust-root provisioning service that relies on a pre-configured >> public-key/x509cert (but we plan/dream to enhance it in the future to >> support other bootstrapping mechanisms) >> (http://www.cagrid.org/mwiki/index.php?title=GTS:Main) >> >> In all cases, we would like to standardize the trust root provisioning >> protocol without having to mandate any boots-trapping public key. Just >> having the message exchange protocol with standardized formats for the >> trust-anchor info including meta-data for the anchor's issuing >> constraints would be great. The security mechanism to use relies on > the >> pre-configured shared-secrets/OTP/Kerberos/password/public-key, and >> should not be mandated IMHO. >> >> Hope that explains. >> >> -Frank. >> >> >> >> >> Santosh Chokhani wrote: >>> Frank, >>> >>> In your scenario, it seems you do not need trust anchor albeit it is > not >>> clear how communication to online CA is secured and how trust is >>> extended beyond on-line CA. >>> >>> You say, "In those cases, there already are ways to establish a > secure >>> authenticated communication context with a trust-anchor provisioning >>> service". What is this trust-anchor provisioning service; what is > trust >>> anchor contents in your context; Is the trust anchor local, > enterprise >>> wide or covers multiple enterprises; and how do you (I assume > meaning >>> client or relying parties) establish secure authenticated > communication >>> with the trust-anchor provisioning service. >>> >>> -----Original Message----- >>> From: Frank Siebenlist [mailto:franks@mcs.anl.gov] >>> Sent: Tuesday, August 21, 2007 11:12 AM >>> To: Santosh Chokhani >>> Cc: ietf-trust-anchor@vpnc.org >>> Subject: Re: Draft Charter >>> >>> In our deployments, we see more and more that PKI is not the primary >>> authentication mechanism and that online-CAs are used to obtain >>> pk-credentials, which means that this pki-trust is derived from > other >>> already pre-configured primary authentication mechanisms, like > shared >>> secrets, username/password, kerberos, OTP, etc. >>> >>> In those cases, there already are ways to establish a secure >>> authenticated communication context with a trust-anchor provisioning >>> service, and the requirement to use only public key and dsig is not > very >>> "helpful" in those scenarios. >>> >>> -FS. >>> >>> >>> Santosh Chokhani wrote: >>>> Frank, >>>> >>>> I agree with Steve. I will be willing to expand the notion a bit. > But, >>>> in my thinking this deals with cryptographic protocols. These > protocols >>>> require a public or secret key to establish the trust for > authentication >>>> and integrity checks. Thus, it must be a key. As it so happens, > we >>>> have been dealing with PKI related matters and hence the starting > key >>>> for authentication and integrity is a public key. >>>> >>>> In short, any idea for trust anchor that does not deal with a > crypto key >>>> is a loser from crypto viewpoint. >>>> >>>> -----Original Message----- >>>> From: owner-ietf-trust-anchor@mail.vpnc.org >>>> [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Frank >>>> Siebenlist >>>> Sent: Tuesday, August 21, 2007 1:40 AM >>>> To: Paul Hoffman >>>> Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor@vpnc.org >>>> Subject: Re: Draft Charter >>>> >>>> >>>> Too bad as in general the overall policy enforcement requires other >>>> "trust anchors", "roots of trust", "assertion authorities", to be >>>> pre-configured, like attribute- and authorization authorities. >>>> >>>> Furthermore, it also would disallow the use of other authentication > and >>>> key exchange mechanism to bootstrap from, like >>>> secure-password/shared-secret protocols with online CAs, in which > case >>>> there would be no need for any trust-anchor's public key and no > digital >>>> signature. >>>> >>>> Just to support x509/pkix style identity certs based on only public > keys >>>> and only dsigs makes it just as "useful" as x509/pkix... maybe this >>>> trust-anchor protocol shouldn't deserve its own wg and should > instead be >>>> used to "revive" pkix as it clearly deals with a deficiency not >>>> addressed in pkix's gazillion rfcs ;-) >>>> >>>> -FS. >>>> >>>> >>>> >>>> Paul Hoffman wrote: >>>>> At 9:26 PM -0400 8/20/07, Stephen Kent wrote: >>>>>> The notion of trust anchors has been, for the last 15 years or > so, a >>>>>> purely public key notion. So yes, I would argue that if we want > to >>>>>> work on what it going to be called a trust anchor management > protocol, >>>>>> it needs to be based on public keys and signature validation. If >>>>>> folks want to do something else, make up a new name, this one is > taken >>>>>> :-). >>>>> I agree with Steve. Everyone involved so far has been talking > about >>>>> public keys, which if nothing else shows that this is the common >>>> theme. >>>>> --Paul Hoffman, Director >>>>> --VPN Consortium >>>>> >> -- >> Frank Siebenlist franks@mcs.anl.gov >> The Globus Alliance - Argonne National Laboratory >> >> >> > -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory From owner-ietf-trust-anchor Wed Aug 22 04:18: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 l7MBIMkk081679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2007 04:18: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 l7MBIMQC081678; Wed, 22 Aug 2007 04:18: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7MBIL0R081672 for ; Wed, 22 Aug 2007 04:18:22 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 18654 invoked from network); 22 Aug 2007 11:15:13 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;22 Aug 2007 11:15:13 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 22 Aug 2007 11:15:13 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Aug 2007 07:17:56 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31D775@scygmxs1.cygnacom.com> From: Carl Wallace To: Frank Siebenlist , Santosh Chokhani Cc: ietf-trust-anchor@vpnc.org Subject: RE: Draft Charter Date: Wed, 22 Aug 2007 07:16:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E4AD.EE2907EA" 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_01C7E4AD.EE2907EA Content-Type: text/plain > In all cases, we would like to standardize the trust root > provisioning protocol without having to mandate any > boots-trapping public key. Just having the message exchange > protocol with standardized formats for the trust-anchor info > including meta-data for the anchor's issuing constraints > would be great. The security mechanism to use relies on the > pre-configured > shared-secrets/OTP/Kerberos/password/public-key, and should > not be mandated IMHO. > > Hope that explains. > > -Frank. > It seems like the issue is more with a comment in section 4 of the problem statement regarding the placement of at least one public key in a device during initialization than with the TA definition that preceded this discussion. I propose we adopt a public key/signature-focused TA definition, soften the language in the problem statement regarding the bootstrap public key and address these issues when we define the security mechanisms for TA mgmt messages. There may be some additional tweaks to the problem statement resulting from this discussion as well. ------_=_NextPart_001_01C7E4AD.EE2907EA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft Charter

> In all cases, we would like to standardize the = trust root
> provisioning protocol without having to mandate = any
> boots-trapping public key. Just having the = message exchange
> protocol with standardized formats for the = trust-anchor info
> including meta-data for the anchor's issuing = constraints
> would be great. The security mechanism to use = relies on the
> pre-configured
> = shared-secrets/OTP/Kerberos/password/public-key, and should
> not be mandated IMHO.
>
> Hope that explains.
>
> -Frank.
>

It seems like the issue is more with a comment in = section 4 of the problem statement regarding the placement of at least = one public key in a device during initialization than with the TA = definition that preceded this discussion.  I propose we adopt a = public key/signature-focused TA definition, soften the language in the = problem statement regarding the bootstrap public key and address these = issues when we define the security mechanisms for TA mgmt = messages.  There may be some additional tweaks to the problem = statement resulting from this discussion as well. 

------_=_NextPart_001_01C7E4AD.EE2907EA-- From owner-ietf-trust-anchor Wed Aug 22 08:00: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 l7MF02at008438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2007 08:00: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 l7MF02fq008435; Wed, 22 Aug 2007 08:00: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 mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7MExxgx008373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2007 08:00:01 -0700 (MST) (envelope-from Black_David@emc.com) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7MExuEH022285; Wed, 22 Aug 2007 10:59:56 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7MExC2Q026366; Wed, 22 Aug 2007 10:59:54 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 10:59:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Draft Charter Date: Wed, 22 Aug 2007 10:59:51 -0400 Message-ID: In-Reply-To: <46CBAD9E.2050307@mcs.anl.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Charter Thread-Index: AcfkbLJq4FVuGpe9TCymQnM2oeIkeQAW7cwg References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> <46CB00BC.8020700@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E8722A@EXVS01.ex.dslextreme.net> <46CB6641.5050204@mcs.anl.gov> <46CBAD9E.2050307@mcs.anl.gov> To: Cc: X-OriginalArrivalTime: 22 Aug 2007 14:59:52.0484 (UTC) FILETIME=[17F6FE40:01C7E4CD] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7MF01gw008426 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank, > Your "translation" sounds good ;-) > > I just don't understand your concern about tls with pre-shared secret - > kerberos' security would be enhanced when it would deploy that for it's > password-based authN+keyexchange - it seems to me like a better authN > protocol to use for any password/OTP-based mechanism... There may be some confusion about who/what is being authenticated/ authorized. The point of the Trust Store Anchor (TSA) is to authorize the Trust Anchor Administrator (TAA) to manage the local store of trust anchors. Note that the local client/user does not need to be authenticated as part of authorizing this management - the local authentication is only needed to bootstrap the trust store authorization mechanism. Once the authorization is in place, only the TAA's identity has to be verified in order to determine whether to permit or deny trust anchor management operations. > Your solution: > > > 1) Set up a secure channel authenticated by some means > > (sneaker-net if necessary). > > 2) Get the TAA's public key and install that as the TSA. > > is less efficient and less secure (one more unnecessary chain) than > simply using the already established security context to provision the > client... I disagree with both "less efficient" and "less secure". If the client (holder of the password, OTP, etc.) has to be authenticated as part of every trust anchor management action performed by the TAA, I would agree with you. That's not the situation here - the installation of the TAA's public key as a TSA is an enrollment-like scenario - it only needs to be done once, after which it is not necessary to re-authenticate the client. There are two important consequences: (1) Once the TAA's public key is installed, a secure channel to the TAA is no longer needed to perform trust anchor management - the TAA can sign the ops and not have to worry about how they're delivered. This may be an efficiency gain (one digital signature vs. all the work in setting up and using a secure channel). It may also be a security gain, as the TAA can have its signing key offline with respect to the trust anchor management operations - in contrast, whatever is used to authenticate a secure channel has to be online with respect to setup of that channel. (2) Loss of the client's authentication credentials does not expose the trust store as long as no TSA change has been made using the compromised credentials. In particular, if the client has no ability to change TSAs (makes sense in an enterprise scenario), then the trust store depends only on the TAA's private key, which was not lost when the client lost her authentication credentials, and that's probably a security gain. For Kerberos, I see no problem in using a principal, because I expect the client to always have that infrastructure set up for other reasons, and because Kerberos isolates the password (vs. having to use it every time for everything). > PS. Note that any of these online-PKIs which is derived/bootstrapped > from another primary authN mechanism is less "trusted/secure" than that > primary authN mechanism - it's up to the organization's policy whether > that is "secure enough" for their deployment (...and in most cases it is). If I take that argument to its logical conclusion, there's no point in using TSAs at all, as the local trust store is at the client's mercy, but there are scenarios in which that is definitely *not* the case. The definition of trust anchor management operations (unsigned) might be useful in the absence of TSAs, but also see the above discussion of one-time installation of a public key as a TSA vs. relying on client authentication every time. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ietf-trust-anchor Wed Aug 22 13:35: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 l7MKZcBe037665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2007 13:35: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 l7MKZc40037664; Wed, 22 Aug 2007 13:35: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7MKZYiX037656 for ; Wed, 22 Aug 2007 13:35:34 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-071.bbn.com ([128.89.89.71] helo=[10.84.130.222]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1INwvL-0000PT-3l; Wed, 22 Aug 2007 16:35:31 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <46CBA924.3040604@mcs.anl.gov> References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> <46CB00BC.8020700@mcs.anl.gov> <46CBA924.3040604@mcs.anl.gov> Date: Wed, 22 Aug 2007 16:35:42 -0400 To: Frank Siebenlist From: Stephen Kent Subject: Re: Draft Charter Cc: 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:10 PM -0700 8/21/07, Frank Siebenlist wrote: >Stephen Kent wrote: >> At 8:11 AM -0700 8/21/07, Frank Siebenlist wrote: >>> In our deployments, we see more and more that PKI is not the primary >>> authentication mechanism and that online-CAs are used to obtain >>> pk-credentials, which means that this pki-trust is derived from other >>> already pre-configured primary authentication mechanisms, like shared >>> secrets, username/password, kerberos, OTP, etc. >> >> I believe your experience is an accurate characterization for the grid >> computing community, but not most other communities who make use of PKI. > >Well...I wouldn't dismiss our experience too fast. > >The grid community has a lot of experience with the old fashion, heavy >weight PKI infrastructure with "real" CAs issuing long-lived certs to >users - probably more than most other commercial applications as the >last time I checked real PKI never lived up to its promise (who are all >those other communities that you are referring to ?). The U.S. DoD, in issuing CACs as well as certs for use with software is an obvious example of a large scale CA issuing long-lived certs. A number of large enterprises have issued certs to employees. Tens of millions of smart card users in Europe and Asia are holders of long lived certs too, although most don't know it. >The reasons why there is a push towards online CAs is because the heavy >administrative burden associated with running a double authN >infrastructure, and because of security concerns. I'm not sure I know what you mean by "running a double authN infrastructure." Is this an allusion to folks who run Kerberos or RADIUS server, and who then decide to add a PKI because these don't support some apps that make use of PKI? >Our experience is that most organizations already have (at least...) one >identity management systems in place, which is "never" based on PKI and >they will not and cannot abandon that for a PKI. First, the term "identity management system" is a neologism created by marketing folks :-). But yes, there is always resistance to change, and not everyone will benefit enough from a PKI to warrant the change. > Being able to leverage >an existing identity management system is very compelling. Leveragng can take the form of using an extant system to issue certs, and then moving on. But, if "leveraging" means never changing out the old system, then of course there is a price to pay. >Lastly, >issuing short-lived certs also removes the revocation issues; dealing >with those was never a strong point of PKI (it actually leaves the >revocation issue with the other Id management system). yes, short-lived certs avoid revocation worries, as well as precluding use of certs for apps like secure e-mail. I disagree with your assertion that dealing with revocation is an inherent weak point of PKI architecture. The CRL model is reasonable if people think through validity intervals, and if they don't have sever bandwidth constraints for delivering CRLs. Yes, if one makes bad choices, then CRLs can grow to be enormous (the CAC is a poster boy for a bad design in this regard). OCSP is a reasonable alternative, although too often folks think it provide fresher info, which is often not the case. In general I believe there has been too much emphasis on the speed with which revocation data must be made available to RPs. In reality, revocation is usually a process that requires human intervention and that will be the gating aspect of the process. >The security issue with long lived certs has to do with the fact that we >cannot trust the desktops anymore because of all the compromises through >worms, viruses, bots, etc. Storing private keys on desktops protected by >pass-phrases is a loosing proposition and compromised keys are expensive >from a revocation, recovery, and management point of view. So unless you >can rely on smartcards for your private key store and signing, your >deployment is saver and recovery is easier when you rely on >passwords/OTP with onlineCAs+sortlived-certs. First, if one is serious about user authentication, some form of hardware assist is needed, period. This could be a TPM, a smart card, a USB token, or even a SecurID fob. When one constrains the solution space to make use only of software, then you're already in trouble. Your argument about the advantages of short-lived certs (and private keys) vs. long-lived certs has merit, but lacks important details. For example, if issuance of a short-lived cert relies on purely password-based authentication, you're still in trouble. if you use an OTP token, then you are better off because of the use of that hardware. However, persistent, malicious software will be able to grab the resulting private key every time it is created, and send it to a bad guy. Worese yet, if you rely on PRNG software on the desktop, a smart adversary might replace it with something that makes it easy to predict the private keys you will generate. So, the bottom line security differences between long and short-lived certs and keys is less dramatic than you suggest. Steve From owner-ietf-trust-anchor Thu Aug 23 03:22: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 l7NAMoEv094433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2007 03:22:50 -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 l7NAModa094432; Thu, 23 Aug 2007 03:22:50 -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 smtp3.su.se (smtp3.su.se [130.237.93.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7NAMmQY094426 for ; Thu, 23 Aug 2007 03:22:50 -0700 (MST) (envelope-from leifj@it.su.se) Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 0C6373BF0F; Thu, 23 Aug 2007 12:22:48 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08498-01-85; Thu, 23 Aug 2007 12:22:47 +0200 (CEST) Received: from [130.237.95.248] (it-vista01.it.su.se [130.237.95.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 8A0AD3BEC3; Thu, 23 Aug 2007 12:22:46 +0200 (CEST) Message-ID: <46CD600A.5040505@it.su.se> Date: Thu, 23 Aug 2007 12:23:06 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Stephen Kent CC: Frank Siebenlist , Santosh Chokhani , ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> <46CB00BC.8020700@mcs.anl.gov> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.897 tagged_above=-99 required=7 tests=[AWL=0.415, BAYES_00=-2.312] X-Spam-Level: Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen Kent wrote: > > At 8:11 AM -0700 8/21/07, Frank Siebenlist wrote: >> In our deployments, we see more and more that PKI is not the primary >> authentication mechanism and that online-CAs are used to obtain >> pk-credentials, which means that this pki-trust is derived from other >> already pre-configured primary authentication mechanisms, like shared >> secrets, username/password, kerberos, OTP, etc. > > I believe your experience is an accurate characterization for the grid > computing community, but not most other communities who make use of PKI. > > Steve > Steve, This use-case is not at all limited to the grid-community. In fact the kx509 tool Frank mentioned wasn't originally a "grid thing". Cheers Leif From owner-ietf-trust-anchor Thu Aug 23 03:34: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 l7NAYbRF095744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2007 03:34: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 l7NAYb7S095743; Thu, 23 Aug 2007 03:34: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 smtp3.su.se (smtp3.su.se [130.237.93.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7NAYarr095737 for ; Thu, 23 Aug 2007 03:34:37 -0700 (MST) (envelope-from leifj@it.su.se) Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 7395A3BFFC; Thu, 23 Aug 2007 12:34:36 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10908-01-75; Thu, 23 Aug 2007 12:34:36 +0200 (CEST) Received: from [130.237.95.248] (it-vista01.it.su.se [130.237.95.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id BC3EA3BFEE; Thu, 23 Aug 2007 12:34:35 +0200 (CEST) Message-ID: <46CD62CF.20004@it.su.se> Date: Thu, 23 Aug 2007 12:34:55 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Stephen Kent CC: Frank Siebenlist , Santosh Chokhani , ietf-trust-anchor@vpnc.org Subject: Re: Draft Charter References: <886F5D4C78AFB14D87261206BFB9612E1D31D6DF@scygmxs1.cygnacom.com> <46CA355A.6040704@mcs.anl.gov> <46CA7A99.8010103@mcs.anl.gov> <82D5657AE1F54347A734BDD33637C87908E86AC2@EXVS01.ex.dslextreme.net> <46CB00BC.8020700@mcs.anl.gov> <46CBA924.3040604@mcs.anl.gov> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.897 tagged_above=-99 required=7 tests=[AWL=0.415, BAYES_00=-2.312] X-Spam-Level: Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >> Our experience is that most organizations already have (at least...) one >> identity management systems in place, which is "never" based on PKI and >> they will not and cannot abandon that for a PKI. > > First, the term "identity management system" is a neologism created by > marketing folks :-). But yes, there is always resistance to change, > and not everyone will benefit enough from a PKI to warrant the change. Stephen, With all due respect... Perhaps with your experience Franks argument don't make sense but I should not be so quick to dismiss him based on wording alone. The situations he describes are everyday reality for many of us in the higher- ed community and not just because we are all lazy bums who haven't figured out that we need to convert our processes from issuing kerberos identities to issuing smart-cards with certs. I don't believe your characterization of identity management as a marketing ploy contributes much to figuring out the merit of the use-cases Frank has presented. Cheers Leif From owner-ietf-trust-anchor Thu Aug 23 10:41: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 l7NHf9u4039677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2007 10:41: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 l7NHf9dP039676; Thu, 23 Aug 2007 10:41: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7NHf7YB039665 for ; Thu, 23 Aug 2007 10:41:08 -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 1IOGg6-0008VI-56; Thu, 23 Aug 2007 13:41:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <004901c7e426$ad24f8c0$0301a8c0@Wylie> References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> Date: Thu, 23 Aug 2007 13:41:21 -0400 To: "Turner, Sean P." From: Stephen Kent Subject: Re: Revised draft charter Cc: ietf-trust-anchor@vpnc.org Content-Type: multipart/alternative; boundary="============_-1024231613==_ma============" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --============_-1024231613==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sean, I made some suggested edits, and inserted a couple of comments, in red. Steve ---- Security Area Director(s): - Tim Polk - Sam Hartman Security Area Advisor: TBD Mailing Lists: General Discussion: ietf-trust-anchor@vpnc.org To Subscribe: http://www.vpnc.org/ietf-trust-anchor/ Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/ Description of Working Group: The need for a standard protocol for trust anchor management has been recognized for some time. Many groups within the IETF, including PKIX, Kerberos, TLS and SIDR have a dependency on trust anchors, yet provide no generic mechanism for the their management. A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. Relying parties use trust anchors to determine if digitally signed objects are valid by verifying digital signatures using the trust anchor's public key and by enforcing the constraints expressed in the associated data. Despite the wide-spread use of trust anchors, there is no standard means for managing these security-critical data. This Working Group will develop a specification to fill this gap. The initial problem statement for this work is to be based on: - draft-wallace-ta-mgmt-problem-statement The scope of the work is to include: - Supporting a single trust anchor administrator , such as in a typical enterprise, who may be administering multiple trust anchors in her domain - Supporting multiple trust anchor administrators, such as is typical for home users - Supporting systems with limited or no user interface - Supporting devices that may or many not be connected to the Internet at the time of management (e.g., relying on physical delivery of trust anchor management messages) The following are out of scope of this work: - Supporting systems with limited or no user interface - Supporting devices that may or many not be connected to the Internet at the time of management The deliverables will be: - An informational problem statement/requirements specification for a trust anchor management protocol - A standards track trust anchor management protocol specification Goals and Milestones: +6 months WG last call on problem statement/requirements +9 months Adoption of WG draft protocol spec. +15 months WG last call for protocol spec. --============_-1024231613==_ma============ Content-Type: text/html; charset="us-ascii" Re: Revised draft charter
Sean,

I made some suggested edits, and inserted a couple of comments, in red.

Steve
----

Security Area Director(s):

-  Tim Polk <tim.polk@nist.gov>
-  Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

TBD

Mailing Lists:

General Discussion: ietf-trust-anchor@vpnc.org
To Subscribe: http://www.vpnc.org/ietf-trust-anchor/
Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/

Description of Working Group:

The need for a standard protocol for trust anchor management has been recognized for some time.  Many groups within the IETF, including PKIX, Kerberos, TLS and SIDR have a dependency on trust anchors, yet provide no generic mechanism for the their management.

A trust anchor represents an authoritative entity via a public key and associated data. <deleted redundant definition> The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative.  Relying parties use trust anchors to determine if digitally signed objects are valid by verifying digital signatures using the trust anchor's public key and by enforcing the constraints expressed in the associated data.

Despite the wide-spread use of trust anchors, there is no standard means for managing these security-critical data.  This Working Group will develop a specification to fill this gap.

The initial problem statement for this work is to be based on:

- draft-wallace-ta-mgmt-problem-statement

The scope of the work is to include:

- Supporting a single trust anchor administrator <no definition of a TAA>, such as in a typical   enterprise, who may be administering multiple trust anchors in her domain
- Supporting multiple trust anchor administrators, such as is typical for home  users
- Supporting systems with limited or no user interface
- Supporting devices that may or many not be connected to the Internet at the time of management (e.g., relying on physical delivery of trust anchor management messages)

The following are out of scope of this work:

- Supporting systems with limited or no user interface <contradicts bullet above!>
- Supporting devices that may or many not be connected to the Internet at the time of management <contradicts bullet above!>

The deliverables will be:

- An informational problem statement/requirements specification for a trust anchor management protocol
- A standards track trust anchor management protocol specification

Goals and Milestones:

+6 months                 WG last call on problem statement/requirements
+9 months                 Adoption of WG draft protocol spec.
+15 months                WG last call for protocol spec.
--============_-1024231613==_ma============-- From owner-ietf-trust-anchor Fri Aug 24 04:30: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 l7OBU7En037453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 04:30: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 l7OBU6E4037452; Fri, 24 Aug 2007 04:30: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 smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7OBU5ng037444 for ; Fri, 24 Aug 2007 04:30:05 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 55673 invoked from network); 24 Aug 2007 11:30:04 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.21.206 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 24 Aug 2007 11:30:04 -0000 X-YMail-OSG: PoPHYdwVM1miyc1zUf7_89v01lmU58UnbX.cx5d4kL3aIJ3YZ6qyLJowN1NuZG9oo8jn53io4A-- From: "Turner, Sean P." To: "'Stephen Kent'" Cc: References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> Subject: RE: Revised draft charter Date: Fri, 24 Aug 2007 07:30:21 -0400 Organization: IECA, Inc. Message-ID: <01fd01c7e642$2832db00$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcflrMjWcobU24/wT9ipe7BwNAHOPQAK+Vgw Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I did a really bad cut and paste job on version 2 when I was incorporating comments from the list. I posted version 3 (on 8/21) that addressed some off-line comments (including your scope comment). I also added out-of-scope ideas suggested on the list. I missed deleting the redundant sentence, but it will be gone in version 4. I'll also make the other changes you suggested to the trust anchor definition. As for the TAA definition, how about: A Trust Anchor Administrator (TAA) is the entity represented by the trust anchor. The TAA controls the private key of the trust anchor. The following is the new suggested scope paragraphs: The scope of the work is to include: - Supporting a single trust anchor administrator, such as in a typical enterprise, who may be administering multiple trust anchors in her domain - Supporting multiple trust anchor administrators, each of whom is independant - Supporting systems with limited or no user interface - Supporting devices that may or many not be connected to the Internet at the time of management (e.g., relying on physical delivery of delivery trust anchor management messages) The scope of work will not include: - Management of non-anchor signature validation objects such as intermediate certificates in a validation path. - Mandating whether the recipient of trust anchors from a trust anchor manager will use those anchors spt From owner-ietf-trust-anchor Fri Aug 24 07:50: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 l7OEohwB061393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 07:50: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 l7OEohfp061392; Fri, 24 Aug 2007 07:50: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 [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 l7OEoUrY061372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 07:50:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <01fd01c7e642$2832db00$0301a8c0@Wylie> References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> <01fd01c7e642$2832db00$0301a8c0@Wylie> Date: Fri, 24 Aug 2007 07:49:25 -0700 To: "Turner, Sean P." , "'Stephen Kent'" From: Paul Hoffman Subject: TAA definition 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 7:30 AM -0400 8/24/07, Turner, Sean P. wrote: >As for the TAA definition, how about: > >A Trust Anchor Administrator (TAA) is the entity represented by the trust >anchor. The TAA controls the private key of the trust anchor. A public key with associated crypto parameters and associated restrictions do not "represent" anyone. Further, this definition breaks the model we have been discussing, where a TAA gives the client one or more TAs for the client to install. This definition causes the client to now have many TAAs, one for each TA they installed. Going back to the definition presented in Chicago: A Trust Anchor Administrator (TAA) is an entity which gives trust anchor instructions to clients. This says that anyone can be a TAA, although obviously a particular client will only listen to one or a small number of TAAs. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Aug 24 08:13: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 l7OFDrjJ065639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 08:13: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 l7OFDrcH065638; Fri, 24 Aug 2007 08:13: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 mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7OFDp3e065621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 08:13:53 -0700 (MST) (envelope-from Black_David@emc.com) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7OFDd8x021375; Fri, 24 Aug 2007 11:13:39 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7OFDDHn024847; Fri, 24 Aug 2007 11:13:37 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 11:12:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: TAA definition Date: Fri, 24 Aug 2007 11:12:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TAA definition Thread-Index: AcfmXs6vDC0TB1L9Rb+1yIh1K0Bc2QAAYMLA References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> <01fd01c7e642$2832db00$0301a8c0@Wylie> To: , , Cc: X-OriginalArrivalTime: 24 Aug 2007 15:12:49.0128 (UTC) FILETIME=[3BB4F680:01C7E661] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7OFDr3d065624 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >As for the TAA definition, how about: > > > >A Trust Anchor Administrator (TAA) is the entity represented by the trust > >anchor. The TAA controls the private key of the trust anchor. > > A public key with associated crypto parameters and associated > restrictions do not "represent" anyone. > > Further, this definition breaks the model we have been discussing, > where a TAA gives the client one or more TAs for the client to > install. This definition causes the client to now have many TAAs, one > for each TA they installed. I agree. A Trust Store Anchor may correspond to a TAA, but the trust anchors that are installed clearly do not (e.g., Verisign's trust anchors will be installed by a lot of entities that aren't part of Verisign). > Going back to the definition presented in Chicago: > > A Trust Anchor Administrator (TAA) is an entity which gives trust > anchor instructions to clients. > > This says that anyone can be a TAA, although obviously a particular > client will only listen to one or a small number of TAAs. And if we want to formalize local identification and authorization of the TAA, I suggest introducing the concept of a Trust Store Anchor. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ietf-trust-anchor Fri Aug 24 08:41:49 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 l7OFfnqR067469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 08:41:49 -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 l7OFfnDj067468; Fri, 24 Aug 2007 08:41:49 -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 l7OFfmtw067455 for ; Fri, 24 Aug 2007 08:41:48 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 7444 invoked from network); 24 Aug 2007 15:38:36 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;24 Aug 2007 15:38:36 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 24 Aug 2007 15:38:36 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Aug 2007 11:41:47 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31D8D9@scygmxs1.cygnacom.com> From: Carl Wallace To: Black_David@emc.com, paul.hoffman@vpnc.org, turners@ieca.com, kent@bbn.com Cc: ietf-trust-anchor@vpnc.org Subject: RE: TAA definition Date: Fri, 24 Aug 2007 11:41:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E665.474BC9EC" 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_01C7E665.474BC9EC Content-Type: text/plain > I agree. A Trust Store Anchor may correspond to a TAA, but > the trust anchors that are installed clearly do not (e.g., > Verisign's trust anchors will be installed by a lot of > entities that aren't part of Verisign). I don't think we should preclude the use of application TAs as TSAs. An application TA could function a trust store anchor in cases where an enterprise TA is be used to sign TA management requests and serves as the root of a PKI, for example. ------_=_NextPart_001_01C7E665.474BC9EC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: TAA definition

> I agree.  A Trust Store Anchor may = correspond to a TAA, but
> the trust anchors that are installed clearly do = not (e.g.,
> Verisign's trust anchors will be installed by a = lot of
> entities that aren't part of Verisign).

I don't think we should preclude the use of = application TAs as TSAs.  An application TA could function a trust = store anchor in cases where an enterprise TA is be used to sign TA = management requests and serves as the root of a PKI, for = example.

------_=_NextPart_001_01C7E665.474BC9EC-- From owner-ietf-trust-anchor Fri Aug 24 08:57: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 l7OFvk0u068634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 08:57: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 l7OFvk8C068633; Fri, 24 Aug 2007 08:57: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 [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 l7OFvWRp068617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 08:57:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31D8D9@scygmxs1.cygnacom.com> References: <886F5D4C78AFB14D87261206BFB9612E1D31D8D9@scygmxs1.cygnacom.com> Date: Fri, 24 Aug 2007 08:56:57 -0700 To: Carl Wallace , Black_David@emc.com, turners@ieca.com, kent@bbn.com From: Paul Hoffman Subject: RE: TAA definition 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:41 AM -0400 8/24/07, Carl Wallace wrote: > > I agree. A Trust Store Anchor may correspond to a TAA, but >> the trust anchors that are installed clearly do not (e.g., >> Verisign's trust anchors will be installed by a lot of >> entities that aren't part of Verisign). > >I don't think we should preclude the use of application TAs as TSAs. >An application TA could function a trust store anchor in cases where >an enterprise TA is be used to sign TA management requests and >serves as the root of a PKI, for example. I don't think David was precluding application TAs as TSAs. He was saying that they all not all TA owners should be TAAs. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Fri Aug 24 09:23: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 l7OGNNIO070551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 09:23: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 l7OGNNZO070550; Fri, 24 Aug 2007 09:23: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7OGNIs0070526 for ; Fri, 24 Aug 2007 09:23:23 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 7695 invoked from network); 24 Aug 2007 16:20:07 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;24 Aug 2007 16:20:07 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 24 Aug 2007 16:20:07 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Aug 2007 12:23:18 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31D8E6@scygmxs1.cygnacom.com> From: Carl Wallace To: Paul Hoffman , Black_David@emc.com, turners@ieca.com, kent@bbn.com Cc: ietf-trust-anchor@vpnc.org Subject: RE: TAA definition Date: Fri, 24 Aug 2007 12:23:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E66B.140DADC6" 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_01C7E66B.140DADC6 Content-Type: text/plain > I don't think David was precluding application TAs as TSAs. > He was saying that they all not all TA owners should be TAAs. OK. I have no issue with that. ------_=_NextPart_001_01C7E66B.140DADC6 Content-Type: text/html RE: TAA definition

> I don't think David was precluding application TAs as TSAs.
> He was saying that they all not all TA owners should be TAAs.

OK.  I have no issue with that.

------_=_NextPart_001_01C7E66B.140DADC6-- From owner-ietf-trust-anchor Fri Aug 24 12:32: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 l7OJWQPi086823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 12:32: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 l7OJWQvZ086822; Fri, 24 Aug 2007 12:32: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 mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7OJWKTf086804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Aug 2007 12:32:23 -0700 (MST) (envelope-from Black_David@emc.com) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7OJWFpw017208; Fri, 24 Aug 2007 15:32:15 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7OJW76k023723; Fri, 24 Aug 2007 15:32:14 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 15:32:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E685.78784110" Subject: RE: TAA definition Date: Fri, 24 Aug 2007 15:32:12 -0400 Message-ID: In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31D8E6@scygmxs1.cygnacom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TAA definition Thread-Index: AcfmaxmX7P2VuLHQSRKvJkGrbBYWqAAGkIHg References: <886F5D4C78AFB14D87261206BFB9612E1D31D8E6@scygmxs1.cygnacom.com> To: Cc: X-OriginalArrivalTime: 24 Aug 2007 19:32:13.0827 (UTC) FILETIME=[78FD8D30:01C7E685] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, HTML_50_70 0.1, HTML_NO_HTTP 0.1, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' 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_01C7E685.78784110 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable That's correct, and I'm in favor of calling out the concept of a TSA explicitly in order to avoid some of the confusion we've gotten into on the list. =20 Thanks, --David ----------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 176 South St., Hopkinton, MA 01748=20 +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 black_david@emc.com Mobile: +1 (978) 394-7754=20 ----------------------------------------------------=20 ________________________________ From: Carl Wallace [mailto:CWallace@cygnacom.com]=20 Sent: Friday, August 24, 2007 12:23 PM To: Paul Hoffman; Black, David; turners@ieca.com; kent@bbn.com Cc: ietf-trust-anchor@vpnc.org Subject: RE: TAA definition =09 =09 > I don't think David was precluding application TAs as TSAs.=20 > He was saying that they all not all TA owners should be TAAs.=20 OK. I have no issue with that.=20 ------_=_NextPart_001_01C7E685.78784110 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: TAA definition
That's correct, and I'm in favor of calling out the=20 concept
of a TSA explicitly in order to avoid some of = the=20 confusion
we've gotten into on the list.
 
Thanks,
--David

----------------------------------------------------=20
David L. = Black, Senior=20 Technologist
EMC Corporation, 176 South St., Hopkinton, MA  = 01748=20
+1 (508)=20 293-7953           = ; =20 FAX: +1 (508) 293-7786
black_david@emc.com        = Mobile: +1=20 (978) 394-7754
----------------------------------------------------=20


From: Carl Wallace=20 [mailto:CWallace@cygnacom.com]
Sent: Friday, August 24, = 2007 12:23=20 PM
To: Paul Hoffman; Black, David; turners@ieca.com;=20 kent@bbn.com
Cc: = ietf-trust-anchor@vpnc.org
Subject: RE:=20 TAA definition


> I don't think David was precluding application = TAs as=20 TSAs.
> He was saying that they all not = all TA=20 owners should be TAAs.

OK.  I have no issue with that.=20

------_=_NextPart_001_01C7E685.78784110-- From owner-ietf-trust-anchor Mon Aug 27 10:34: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 l7RHYMZK016416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 10:34: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 l7RHYMoh016415; Mon, 27 Aug 2007 10:34: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7RHYLGb016400; Mon, 27 Aug 2007 10:34:22 -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 1IPiTl-0003fk-46; Mon, 27 Aug 2007 13:34:21 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> <01fd01c7e642$2832db00$0301a8c0@Wylie> Date: Mon, 27 Aug 2007 13:34:36 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: TAA definition Cc: "Turner, Sean P." , 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:49 AM -0700 8/24/07, Paul Hoffman wrote: >At 7:30 AM -0400 8/24/07, Turner, Sean P. wrote: >>As for the TAA definition, how about: >> >>A Trust Anchor Administrator (TAA) is the entity represented by the trust >>anchor. The TAA controls the private key of the trust anchor. > >A public key with associated crypto parameters and associated >restrictions do not "represent" anyone. In many cases a TAA does represent an entity, e.g., an organization, though perhaps not always. For example, in the home context the user may be a TAA, in the enterprise context the IT organization for the enterprise may be a TAA, etc. >Further, this definition breaks the model we have been discussing, >where a TAA gives the client one or more TAs for the client to >install. This definition causes the client to now have many TAAs, >one for each TA they installed. Sorry, I guess I missed this part of our discussion. I don't tend to think of a TAA providing TAs that may or may not be installed, at the whim of a client, unless the client is a TAA with greater privilege. >Going back to the definition presented in Chicago: > >A Trust Anchor Administrator (TAA) is an entity which gives trust >anchor instructions to clients. I don't think this is a good definition, to the extent that it suggests the client may or may not act on the instructions. At least in some contexts with which I am familiar, the client does not have a say in this matter. That's why I would feel more comfortable with a definition that didn't suggest that the client has the last word here. >This says that anyone can be a TAA, although obviously a particular >client will only listen to one or a small number of TAAs. For a TA we have always said that it is up to an RP to decide whether a given entity who purports to be a TA IS accepted as a TA by the RP. The problem here is that we're talking about managing TAs, and acknowledging that the user of a computer or device may not have total control over the TAs installed in it, in all cases. Steve From owner-ietf-trust-anchor Mon Aug 27 16:04:16 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 l7RN4GQE042251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 16:04:16 -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 l7RN4G21042249; Mon, 27 Aug 2007 16:04:16 -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 l7RN3wcD042210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 16:04:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> <01fd01c7e642$2832db00$0301a8c0@Wylie> Date: Mon, 27 Aug 2007 16:03:20 -0700 To: Stephen Kent From: Paul Hoffman Subject: Re: TAA definition Cc: "Turner, Sean P." , 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:34 PM -0400 8/27/07, Stephen Kent wrote: >At 7:49 AM -0700 8/24/07, Paul Hoffman wrote: >>At 7:30 AM -0400 8/24/07, Turner, Sean P. wrote: >>>As for the TAA definition, how about: >>> >>>A Trust Anchor Administrator (TAA) is the entity represented by the trust >>>anchor. The TAA controls the private key of the trust anchor. >> >>A public key with associated crypto parameters and associated >>restrictions do not "represent" anyone. > >In many cases a TAA does represent an entity, e.g., an organization, >though perhaps not always. For example, in the home context the user >may be a TAA, in the enterprise context the IT organization for the >enterprise may be a TAA, etc. Fully agree. That does not change what I said about a public key representing someone. The current wording doesn't make sense. >>Further, this definition breaks the model we have been discussing, >>where a TAA gives the client one or more TAs for the client to >>install. This definition causes the client to now have many TAAs, >>one for each TA they installed. > >Sorry, I guess I missed this part of our discussion. It has been one of the major themes, both in Chicago and on the list. >I don't tend to think of a TAA providing TAs that may or may not be >installed, at the whim of a client, unless the client is a TAA with >greater privilege. This is the enterprise model where a single TAA essentially controls the TA store. The individual model is where the individual chooses more than one TAA and may select which of the TAAs' advice to take. More recently on this list, a hybrid model has appeared, which says that once an individual accepts a TAA, they will take whatever the TAA tells them, even if it conflicts with what another selected TAA has told them in the past. >>Going back to the definition presented in Chicago: >> >>A Trust Anchor Administrator (TAA) is an entity which gives trust >>anchor instructions to clients. > >I don't think this is a good definition, to the extent that it >suggests the client may or may not act on the instructions. At least >in some contexts with which I am familiar, the client does not have >a say in this matter. That's why I would feel more comfortable with >a definition that didn't suggest that the client has the last word >here. Do you prefer the enterprise model or the hybrid model? Or something else? --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Tue Sep 4 00:17: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 l847HcNT022151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 00:17: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 l847Hc05022150; Tue, 4 Sep 2007 00:17: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l847HbTK022139 for ; Tue, 4 Sep 2007 00:17:37 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[169.223.7.30]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1ISSfI-0004Oe-4E; Tue, 04 Sep 2007 03:17:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <96F4992C-FAD6-4513-9ABE-81F08CE2998C@checkpoint.com> Date: Tue, 4 Sep 2007 03:17:31 -0400 To: Black_David@emc.com From: Stephen Kent Subject: Re: Multiple TAAs 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: David, I agree that if multiple TAAs are completely independent of one another, the simplest approach is to treat the stores as independent. Complexity arises when different TAAs are not completely independent. If there are relationships among TAAs, then we have to be able to express the relationships. This can be quite hard, depending of what range of relationships we agree need to be supported. Moreover, if the relationships are expressed via data in the TAs themselves, then we get into the situation I have alluded to before, and for which Leif has asked me for concrete examples. See my message to Paul for an example. Steve From owner-ietf-trust-anchor Tue Sep 4 00: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 l847HaTj022137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 00:17: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 l847Haer022136; Tue, 4 Sep 2007 00:17: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l847HZMC022122; Tue, 4 Sep 2007 00:17:35 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[169.223.7.30]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1ISSfF-0004Oe-60; Tue, 04 Sep 2007 03:17:34 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> <01fd01c7e642$2832db00$0301a8c0@Wylie> Date: Tue, 4 Sep 2007 03:17:27 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: TAA definition 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: >... >>I don't tend to think of a TAA providing TAs that may or may not be >>installed, at the whim of a client, unless the client is a TAA with >>greater privilege. > >This is the enterprise model where a single TAA essentially controls >the TA store. The individual model is where the individual chooses >more than one TAA and may select which of the TAAs' advice to take. >More recently on this list, a hybrid model has appeared, which says >that once an individual accepts a TAA, they will take whatever the >TAA tells them, even if it conflicts with what another selected TAA >has told them in the past. The enterprise model probably would be an OK start for some DoD environments with which I am familiar, although it is not rich enough for all the cases I know about. The "hybrid" model seems incomplete, as briefly characterized. If TAAs exist as parallel, independent, entities, there could be considerable confusion if different TAAs install different TAs that overlap in their scope. This gets back to the issue I cited earlier, and reiterated several times. Each TAA has to have an ability to associate some scope with it. This scope may have to be imposed on TAs installed "under" each TAA. That way one can use static analysis of TAAs to determine whether there are overlaps that might cause problems. The same is true for TAs, if one has a "flatter" TA management arrangement. For example, imagine a security device that implements IPsec but also incorporates application layer proxies as well. The device vendor is the only authorized source for the IPsec software. One or more other vendors are authorized sources for the application layer proxies. The set of application proxy vendors is managed by the device vendor, because he has "qualified" them as OK providers re the device. The enterprise security administrator is the only authorized source for IPsec PAD/SPD management, which is represented as a signed file. To enforce these different authorizations I want to be able to associate different TAs with different sources. For example the only authorized source of IPsec software (and basic device software) is the device vendor. For the application proxies, I might need a TA per vendor, and maybe a TAA that allows me to manage the installation of those TAs. I would need one TA for the PAD/SPD, and a TAA for managing TAs for IKE. For the software sources (IPsec and application proxies) I could make use of the firmware wrapper format (RFC 4108) for signed software. I might use the same format for the SPD files (even though they are not software per se). In that format, the preferred firmware package name is an OID, and a version number. The fact that 4108 labels packages (files) by OID presents an opportunity for using these OIDs for authorization. One might easily structure the OIDs used here to distinguish the IPsec software from the proxy software packages (and from the PAD/SPD file). The different proxy software packages also should be labelled by vendor, to prevent one vendor from supplying a package for another. To enforce this simple policy there is a need to make sure that when one validates a signature on a package using a TA, that the TA is the right one. It is not enough that the TA is referenced by the package; the TA must be authorized to verify signatures on packages of a specific type. This can be enforced by associating with each TA an OID that is the prefix of the labels associated with the packages signed by the relevant vendor, or by the local admin. The OID confers authorization to verify firmware package signatures that have that OID as a prefix for the package name. This way if a vendor (or a sys admin) mislabels a package, the TA used to verify the package will reject it. One would like to be able to employ the same sort of authorization up one level, i.e., for TAAs. For example, if we install a TAA for managing TAs for KE, we don't want that TAA installing TAs that can be used to verify package signatures. This example is just offered to motivate the following observations: - one needs to be able to bind data to each TA to constrain the set of signed objects that the TA is authorized to verify. - one also needs to be able to express the same sort of authorization data to TAAs, so that each TAA can "flow down" these constraints - for TAAs, there also will need to be a way to express additional authorization data (if we support a hierarchy of TAAs) where this data relates to management of TAAs by other TAAs If we want to develop a standard that is applicable in a wide range of contexts, then I think we need to define the required capabilities for expressing and binding authorization data to TAs and TAAs. I think the observations above suggest that one needs to know a fair amount about what types of authorization data can be expressed via the TAA/TA data structure, in order to be able to determine if a candidate TAA/TA mechanism is sufficiently expressive for a candidate type of environment. Steve From owner-ietf-trust-anchor Wed Sep 5 20:09: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 l8639eaT080100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Sep 2007 20:09: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 l8639eph080099; Wed, 5 Sep 2007 20:09: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 mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8639cHN080091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Sep 2007 20:09:39 -0700 (MST) (envelope-from Black_David@emc.com) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l8639I6m020021; Wed, 5 Sep 2007 23:09:19 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l863913b017781; Wed, 5 Sep 2007 23:09:02 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 23:05:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Multiple TAAs Date: Wed, 5 Sep 2007 23:05:22 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple TAAs Thread-Index: AcfuxD/3/RiZsP9CSN6t8J8auMobsgBY9L/w References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> <01fd01c7e642$2832db00$0301a8c0@Wylie> To: Cc: X-OriginalArrivalTime: 06 Sep 2007 03:05:23.0550 (UTC) FILETIME=[C44907E0:01C7F032] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P3_2 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __cbl.abuseat.org_TIMEOUT , __dnsbl.njabl.org_TIMEOUT , __sbl.spamhaus.org_TIMEOUT ' Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l8639eHM080094 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steve, > I agree that if multiple TAAs are completely independent of one > another, the simplest approach is to treat the stores as independent. > > Complexity arises when different TAAs are not completely independent. > If there are relationships among TAAs, then we have to be able to > express the relationships. This can be quite hard, depending of what > range of relationships we agree need to be supported. > > Moreover, if the relationships are expressed via data in the TAs > themselves, then we get into the situation I have alluded to before, > and for which Leif has asked me for concrete examples. > > See my message to Paul for an example. Ok, here's that example: > For example, imagine a security device that implements IPsec but also > incorporates application layer proxies as well. The device vendor is > the only authorized source for the IPsec software. One or more other > vendors are authorized sources for the application layer proxies. The > set of application proxy vendors is managed by the device vendor, > because he has "qualified" them as OK providers re the device. The > enterprise security administrator is the only authorized source for > IPsec PAD/SPD management, which is represented as a signed file. And let's assume that the enterprise security administrator is also the only authorized source for IKE authentication TA management, since that comes up in the next paragraph. There are three classes of entities: - device vendor - application proxy vendors - enterprise security administrator and there's no overlap among the classes, although I could envision the device vendor supplying some initial application proxies with the device. > To enforce these different authorizations I want to be able to > associate different TAs with different sources. For example the only > authorized source of IPsec software (and basic device software) is > the device vendor. For the application proxies, I might need a TA per > vendor, and maybe a TAA that allows me to manage the installation of > those TAs. I would need one TA for the PAD/SPD, and a TAA for > managing TAs for IKE. But why do all of those TAs need to go into a single trust store? IMHO, mixing the TAs used for routine IKE authentication with the TA that allows the IPsec software to be replaced is asking for trouble. > For the software sources (IPsec and application proxies) I could make > use of the firmware wrapper format (RFC 4108) for signed software. I > might use the same format for the SPD files (even though they are not > software per se). In that format, the preferred firmware package name > is an OID, and a version number. > > The fact that 4108 labels packages (files) by OID presents an > opportunity for using these OIDs for authorization. One might easily > structure the OIDs used here to distinguish the IPsec software from > the proxy software packages (and from the PAD/SPD file). The > different proxy software packages also should be labeled by vendor, > to prevent one vendor from supplying a package for another. If that label OID is used to dispatch to one of three trust stores, life suddenly gets much simpler, and in particular, it makes it easier to put special restrictions around IPsec software replacement and application proxies by contrast to routine PAD/SPD updates because the software replacement is functionally separated. > To enforce this simple policy there is a need to make sure that when > one validates a signature on a package using a TA, that the TA is the > right one. It is not enough that the TA is referenced by the > package; the TA must be authorized to verify signatures on packages > of a specific type. This can be enforced by associating with each TA > an OID that is the prefix of the labels associated with the packages > signed by the relevant vendor, or by the local admin. The OID confers > authorization to verify firmware package signatures that have that > OID as a prefix for the package name. This way if a vendor (or a sys > admin) mislabels a package, the TA used to verify the package will > reject it. Or put these TAs into three separate trust stores (plus one for IKE) and dispatch the firmware wrapper packages to trust stores based on OID - special OID for IPsec replacement, special OID for PAD/SPD files, everything else gets treated as a possible proxy. I might be about to concede part of Steve's point by arguing that for the proxy trust store, the TA has to include a certificate signed by the device vendor and the prefix OID of the packages that TA can verify has to be in the certificate. > One would like to be able to employ the same sort of authorization up > one level, i.e., for TAAs. For example, if we install a TAA for > managing TAs for KE, we don't want that TAA installing TAs that can > be used to verify package signatures. This works fine with four trust stores and each TAA being specific to a trust store. The only headache is that there are now four TSAs to install (as IPsec software, application proxy software, PAD/SPD and IKE authentication each have their own trust store), but there's not much overlap: - IPsec software install and proxy software install might be able to share a TSA, but I'd argue for IPsec software install having its own TSA that can be offline until the device vendor's software signing key has to be replaced, and that the device vendor should use a different signing key for its base software vs. the proxies. - PAD/SPD and IKE authentication trust store updates can share the enterprise security administrator's TSA, as both are about control of policy distribution. So across the four trust stores, we need 2 or 3 TSAs, or which one or two get installed twice because there's a TSA per trust store. That seems to be within reason. Now looking at trust store TA contents, I would argue that there's limited overlap: - First of all the software install TAs should not overlap with the policy distribution TAs because the enterprise security administrator is not a software developer. - The software install TAs need to be restricted to handling the sensitive software, but the IPsec software TA might also be usable for proxies. - A TA used for PAD/SPD download might also be used to authenticate the connection on which that download is delivered, although that's does not strike me as a good idea courtesy of the signature involved in IKE authentication, as it risks the TA signing something during an IKE run that turns out to be PAD/SPD data. So across the four trust stores, the IPsec software distribution TA might be duplicated, and the few TAs used for PAD/SPD download TAs might be duplicated if the security policy is sloppy. A security administrator doing a good job duplicates at most one TA across the four trust stores. > This example is just offered to motivate the following observations: > > - one needs to be able to bind data to each TA to constrain > the set of signed objects that the TA is authorized to verify. > > - one also needs to be able to express the same sort of > authorization data to TAAs, so that each TAA can "flow down" these > constraints > > - for TAAs, there also will need to be a way to express > additional authorization data (if we support a hierarchy of TAAs) > where this data relates to management of TAAs by other TAAs > > If we want to develop a standard that is applicable in a wide range > of contexts, then I think we need to define the required capabilities > for expressing and binding authorization data to TAs and TAAs. I > think the observations above suggest that one needs to know a fair > amount about what types of authorization data can be expressed via > the TAA/TA data structure, in order to be able to determine if a > candidate TAA/TA mechanism is sufficiently expressive for a candidate > type of environment. Based on this example, I don't see that complexity as justified, when using four separate trust stores each with their own TSA(s) solves the problem with what looks like acceptable overhead, makes the mechanism simpler, and therefore (I'd argue) increases assurance that the TAs and TSAs are correctly separated by purpose/use. In the specific area of application proxy software verification, I'm pushing the complexity of determining whether a TA can verify a software package into the PKIX certificate infrastructure that can already handle it - I'd like to keep that area of functionality out of the TA management protocol beyond the ability of a TA to include a certificate. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ietf-trust-anchor Thu Sep 6 10:23: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 l86HNjMN069385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2007 10:23: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 l86HNjdQ069384; Thu, 6 Sep 2007 10:23: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 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 l86HNini069359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2007 10:23:44 -0700 (MST) (envelope-from hotz@jpl.nasa.gov) Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l86HNWCP004141; Thu, 6 Sep 2007 10:23:32 -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 l86HNQoU008389; Thu, 6 Sep 2007 10:23:30 -0700 In-Reply-To: References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> <01fd01c7e642$2832db00$0301a8c0@Wylie> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <649F46DA-D81A-44FF-ADAE-7D8E5B6486FA@jpl.nasa.gov> Cc: Paul Hoffman , Content-Transfer-Encoding: 7bit From: "Henry B. Hotz" Subject: Re: TAA definition Date: Thu, 6 Sep 2007 10:23:13 -0700 To: Stephen Kent 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 Sep 4, 2007, at 12:17 AM, Stephen Kent wrote: > This gets back to the issue I cited earlier, and reiterated several > times. Each TAA has to have an ability to associate some scope with > it. This scope may have to be imposed on TAs installed "under" each > TAA. That way one can use static analysis of TAAs to determine > whether there are overlaps that might cause problems. The same is > true for TAs, if one has a "flatter" TA management arrangement. Fully agree. ------------------------------------------------------------------------ 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 Sep 6 15: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 l86MtoMF002141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2007 15: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 l86Mto71002140; Thu, 6 Sep 2007 15:55:50 -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 mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l86Mtn4i002134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Sep 2007 15:55:50 -0700 (MST) (envelope-from Black_David@emc.com) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l86MthwR014946; Thu, 6 Sep 2007 18:55:44 -0400 (EDT) Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l86Mt4XH023474; Thu, 6 Sep 2007 18:55:41 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 18:55:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: TAA definition Date: Thu, 6 Sep 2007 18:55:36 -0400 Message-ID: In-Reply-To: <649F46DA-D81A-44FF-ADAE-7D8E5B6486FA@jpl.nasa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TAA definition Thread-Index: Acfwq1EHThJ3/EKjS2qH/wZBiDZVEwALHbaQ References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> <01fd01c7e642$2832db00$0301a8c0@Wylie> <649F46DA-D81A-44FF-ADAE-7D8E5B6486FA@jpl.nasa.gov> To: Cc: X-OriginalArrivalTime: 06 Sep 2007 22:55:37.0478 (UTC) FILETIME=[0A4DAA60:01C7F0D9] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l86Mto4h002135 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Henry, > > This gets back to the issue I cited earlier, and reiterated several > > times. Each TAA has to have an ability to associate some scope with > > it. This scope may have to be imposed on TAs installed "under" each > > TAA. That way one can use static analysis of TAAs to determine > > whether there are overlaps that might cause problems. The same is > > true for TAs, if one has a "flatter" TA management arrangement. > > Fully agree. Could you provide a motivating example for which assigning each TAA scope to a separate trust store is not a good solution? Steve's example didn't do it for me, as I think it only requires 4 trust stores, one of which does some extra certificate checks. To explain where I'm coming from - my default hypothesis (I'm definitely prepared to be proved wrong) is that most of the scope, policy, etc. features can be handled via certificates, possibly cert extensions of some form. I'd prefer to deal with this area in that fashion, even to the point of having the TSA that is used to authorize the TAA include a certificate with whatever extensions are needed to get the job done. If existing certificate technology can be reused, we don't have to reinvent it, simplifying things for all concerned. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ietf-trust-anchor Fri Sep 7 12:24: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 l87JOxGN009415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2007 12:24:59 -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 l87JOxGD009414; Fri, 7 Sep 2007 12:24:59 -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 l87JOta4009405 for ; Fri, 7 Sep 2007 12:24:56 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 14713 invoked from network); 7 Sep 2007 19:21:22 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;07 Sep 2007 19:21:22 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 7 Sep 2007 19:21:22 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Sep 2007 15:24:53 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31DE69@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: RE: TAA definition Date: Fri, 7 Sep 2007 15:24:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F184.C0EEE772" 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_01C7F184.C0EEE772 Content-Type: text/plain > Could you provide a motivating example for which assigning > each TAA scope to a separate trust store is not a good solution? Many trust stores are used by a variety of applications that serve a variety of purposes. Using multiple trust stores as the mechanism for supporting different purposes is certainly possible, and could be implemented even if there were a mechanism that enabled multiple TAAs with different privilege sets to manage a single trust store. I'm not sure we need to settle on a mechanism right now. There's no disagreement that multiple TAAs serving different purposes are necessary for some devices. > Steve's example didn't do it for me, as I think it only requires > 4 trust stores, one of which does some extra certificate checks. > > To explain where I'm coming from - my default hypothesis (I'm > definitely prepared to be proved wrong) is that most of the > scope, policy, etc. features can be handled via certificates, > possibly cert extensions of some form. I'd prefer to deal > with this area in that fashion, even to the point of having > the TSA that is used to authorize the TAA include a > certificate with whatever extensions are needed to get the > job done. If existing certificate technology can be reused, > we don't have to reinvent it, simplifying things for all concerned. I agree, though processing extensions from certificates that function as TAs would require augmentation of the 3280 path processing algorithm. > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > ------_=_NextPart_001_01C7F184.C0EEE772 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: TAA definition

> Could you provide a motivating example for which = assigning
> each TAA scope to a separate trust store is not = a good solution?

Many trust stores are used by a variety of = applications that serve a variety of purposes.  Using multiple = trust stores as the mechanism for supporting different purposes is = certainly possible, and could be implemented even if there were a = mechanism that enabled multiple TAAs with different privilege sets to = manage a single trust store. 

I'm not sure we need to settle on a mechanism right = now.  There's no disagreement that multiple TAAs serving different = purposes are necessary for some devices.

> Steve's example didn't do it for me, as I think = it only requires
> 4 trust stores, one of which does some extra = certificate checks.
>
> To explain where I'm coming from - my default = hypothesis (I'm
> definitely prepared to be proved wrong) is that = most of the
> scope, policy, etc. features can be handled via = certificates,
> possibly cert extensions of some form.  = I'd prefer to deal
> with this area in that fashion, even to the = point of having
> the TSA that is used to authorize the TAA = include a
> certificate with whatever extensions are needed = to get the
> job done.  If existing certificate = technology can be reused,
> we don't have to reinvent it, simplifying = things for all concerned.

I agree, though processing extensions from = certificates that function as TAs would require augmentation of the = 3280 path processing algorithm. 

 
> Thanks,
> --David
> = ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, = MA  01748
> +1 (508) = 293-7953          &nbs= p;  FAX: +1 (508) 293-7786
> = black_david@emc.com        Mobile: = +1 (978) 394-7754
> = ----------------------------------------------------
>

------_=_NextPart_001_01C7F184.C0EEE772-- From owner-ietf-trust-anchor Mon Sep 10 12:13: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 l8AJD9UY085084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 12:13: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 l8AJD9ub085083; Mon, 10 Sep 2007 12:13: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8AJD7ir085070 for ; Mon, 10 Sep 2007 12:13:08 -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 1IUoh0-0000kd-5O; Mon, 10 Sep 2007 15:13:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> <01fd01c7e642$2832db00$0301a8c0@Wylie> Date: Mon, 10 Sep 2007 15:13:14 -0400 To: Black_David@emc.com From: Stephen Kent Subject: RE: Multiple TAAs 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: >... >Ok, here's that example: > >> For example, imagine a security device that implements IPsec but also >> incorporates application layer proxies as well. The device vendor is >> the only authorized source for the IPsec software. One or more other >> vendors are authorized sources for the application layer proxies. The >> set of application proxy vendors is managed by the device vendor, >> because he has "qualified" them as OK providers re the device. The >> enterprise security administrator is the only authorized source for >> IPsec PAD/SPD management, which is represented as a signed file. > >And let's assume that the enterprise security administrator is also >the only authorized source for IKE authentication TA management, since >that comes up in the next paragraph. There are three classes of >entities: > - device vendor > - application proxy vendors > - enterprise security administrator >and there's no overlap among the classes, although I could >envision the device vendor supplying some initial application >proxies with the device. I would expect that the device vendor might also be a proxy supplier, both initially and perhaps throughout the life of the product. > > To enforce these different authorizations I want to be able to >> associate different TAs with different sources. For example the only >> authorized source of IPsec software (and basic device software) is >> the device vendor. For the application proxies, I might need a TA per >> vendor, and maybe a TAA that allows me to manage the installation of >> those TAs. I would need one TA for the PAD/SPD, and a TAA for >> managing TAs for IKE. > >But why do all of those TAs need to go into a single trust store? > >IMHO, mixing the TAs used for routine IKE authentication with the TA >that allows the IPsec software to be replaced is asking for trouble. They are not "mixed" if we can tag them to represent their different authorizations. But, I see your point, i.e., if we create different stores as a means of distinguishing the different classes of authorizations, that is another way to tag TAs without a need to refer to the content of the certs. That transforms at least part of the representation problem for authorization into a uniform mechanism, i.e., the ability to manage the TAs in a given store. However, I don't think that will provide all the requisite controls I suggested might be needed, e.g., the ability to distinguish among proxy vendors. > > For the software sources (IPsec and application proxies) I could make >> use of the firmware wrapper format (RFC 4108) for signed software. I >> might use the same format for the SPD files (even though they are not >> software per se). In that format, the preferred firmware package name >> is an OID, and a version number. >> >> The fact that 4108 labels packages (files) by OID presents an >> opportunity for using these OIDs for authorization. One might easily >> structure the OIDs used here to distinguish the IPsec software from >> the proxy software packages (and from the PAD/SPD file). The >> different proxy software packages also should be labeled by vendor, >> to prevent one vendor from supplying a package for another. > >If that label OID is used to dispatch to one of three trust stores, >life suddenly gets much simpler, and in particular, it makes it >easier to put special restrictions around IPsec software replacement >and application proxies by contrast to routine PAD/SPD updates >because the software replacement is functionally separated. I agree that a three-store model is a reasonable way to address top-level distinctions, but not more fine grained ones. For example, I didn't go into details about IKE TAs. In general one would want to constrain the name space each TA is authorized to represent. In X.509 we can do this via the NameConstrants extension. But, that is a very X.509-specific feature, and thus requires reference to the semantics of X.509 certs. > > To enforce this simple policy there is a need to make sure that when > > one validates a signature on a package using a TA, that the TA is the > > right one. It is not enough that the TA is referenced by the >> package; the TA must be authorized to verify signatures on packages >> of a specific type. This can be enforced by associating with each TA >> an OID that is the prefix of the labels associated with the packages >> signed by the relevant vendor, or by the local admin. The OID confers > > authorization to verify firmware package signatures that have that >> OID as a prefix for the package name. This way if a vendor (or a sys >> admin) mislabels a package, the TA used to verify the package will >> reject it. > >Or put these TAs into three separate trust stores (plus one for IKE) >and dispatch the firmware wrapper packages to trust stores based on >OID - special OID for IPsec replacement, special OID for PAD/SPD >files, everything else gets treated as a possible proxy. I might >be about to concede part of Steve's point by arguing that for the >proxy trust store, the TA has to include a certificate signed by >the device vendor and the prefix OID of the packages that TA can >verify has to be in the certificate. I'm not sure exactly what you are saying above, although I do like the part where you mention the word "concede" :-). With regard to the proxy vendors, there is a need to distinguish among them, e.g., to prevent on vendor from supplying a package that replaces (because it ha a higher version number) a package from another vendor. I think that it is asking too much to say that each proxy vendor has to have a distinct store, and that we have to bind that store to the software from that vendor. I think that would be the logical extension of the TA store model you have articulated, right? > > One would like to be able to employ the same sort of authorization up >> one level, i.e., for TAAs. For example, if we install a TAA for >> managing TAs for KE, we don't want that TAA installing TAs that can >> be used to verify package signatures. > >This works fine with four trust stores and each TAA being specific >to a trust store. The only headache is that there are now four >TSAs to install (as IPsec software, application proxy software, >PAD/SPD and IKE authentication each have their own trust store), >but there's not much overlap: >- IPsec software install and proxy software install might be able > to share a TSA, but I'd argue for IPsec software install > having its own TSA that can be offline until the device > vendor's software signing key has to be replaced, and that > the device vendor should use a different signing key for > its base software vs. the proxies. >- PAD/SPD and IKE authentication trust store updates can share > the enterprise security administrator's TSA, as both are > about control of policy distribution. >So across the four trust stores, we need 2 or 3 TSAs, or which >one or two get installed twice because there's a TSA per trust >store. That seems to be within reason. 2-3 seems like an OK number if we can everything we need, but ... > >Now looking at trust store TA contents, I would argue that >there's limited overlap: >- First of all the software install TAs should not overlap > with the policy distribution TAs because the enterprise > security administrator is not a software developer. agreed. >- The software install TAs need to be restricted to handling > the sensitive software, but the IPsec software > TA might also be usable for proxies. yes. >- A TA used for PAD/SPD download might also be used to > authenticate the connection on which that download is > delivered, although that's does not strike me as a > good idea courtesy of the signature involved in IKE > authentication, as it risks the TA signing something > during an IKE run that turns out to be PAD/SPD data. I think I agree wit this too. >So across the four trust stores, the IPsec software distribution >TA might be duplicated, and the few TAs used for PAD/SPD download >TAs might be duplicated if the security policy is sloppy. A >security administrator doing a good job duplicates at most one >TA across the four trust stores. > >> This example is just offered to motivate the following observations: > > >> - one needs to be able to bind data to each TA to constrain >> the set of signed objects that the TA is authorized to verify. >> >> - one also needs to be able to express the same sort of >> authorization data to TAAs, so that each TAA can "flow down" these >> constraints >> >> - for TAAs, there also will need to be a way to express >> additional authorization data (if we support a hierarchy of TAAs) > > where this data relates to management of TAAs by other TAAs >> >> If we want to develop a standard that is applicable in a wide range >> of contexts, then I think we need to define the required capabilities >> for expressing and binding authorization data to TAs and TAAs. I >> think the observations above suggest that one needs to know a fair >> amount about what types of authorization data can be expressed via >> the TAA/TA data structure, in order to be able to determine if a >> candidate TAA/TA mechanism is sufficiently expressive for a candidate >> type of environment. > >Based on this example, I don't see that complexity as justified, >when using four separate trust stores each with their own TSA(s) >solves the problem with what looks like acceptable overhead, makes >the mechanism simpler, and therefore (I'd argue) increases assurance >that the TAs and TSAs are correctly separated by purpose/use. but note the need for additional granularity, in two of the stores, as I suggested above. >In the specific area of application proxy software verification, >I'm pushing the complexity of determining whether a TA can >verify a software package into the PKIX certificate infrastructure >that can already handle it - I'd like to keep that area of >functionality out of the TA management protocol beyond the >ability of a TA to include a certificate. > If you're saying that the per-vendor granularity is best managed by a cert extension of the sort I suggested, I guess I agree. But, that is an example of using a cert-specific capability to achieve the needed granularity of authorization management. Is your point that this is now a TA feature, but not TAA feature? Steve From owner-ietf-trust-anchor Mon Sep 10 13:31: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 l8AKVHJ4090195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 13:31: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 l8AKVHLH090194; Mon, 10 Sep 2007 13:31: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 mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8AKVFmh090187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Sep 2007 13:31:16 -0700 (MST) (envelope-from Black_David@emc.com) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l8AKV1Gs025958; Mon, 10 Sep 2007 16:31:01 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l8AKUm3x011376; Mon, 10 Sep 2007 16:30:59 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 16:30:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Multiple TAAs Date: Mon, 10 Sep 2007 16:30:23 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple TAAs thread-index: Acfz3qZbQ5amf2aJR+25wT5BpaB1WQACjG3g References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> <01fd01c7e642$2832db00$0301a8c0@Wylie> To: Cc: X-OriginalArrivalTime: 10 Sep 2007 20:30:24.0188 (UTC) FILETIME=[6A6E1FC0:01C7F3E9] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l8AKVHmg090189 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steve, > >In the specific area of application proxy software verification, > >I'm pushing the complexity of determining whether a TA can > >verify a software package into the PKIX certificate infrastructure > >that can already handle it - I'd like to keep that area of > >functionality out of the TA management protocol beyond the > >ability of a TA to include a certificate. > > If you're saying that the per-vendor granularity is best managed by a > cert extension of the sort I suggested, I guess I agree. But, that is > an example of using a cert-specific capability to achieve the needed > granularity of authorization management. Is your point that this is > now a TA feature, but not TAA feature? Yes, specifically: > > I might > > be about to concede part of Steve's point by arguing that for the > > proxy trust store, the TA has to include a certificate signed by > > the device vendor and the prefix OID of the packages that TA can > > verify has to be in the certificate. and the code that handles proxy software download knows to check that OID against the code package. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ietf-trust-anchor Mon Sep 10 14:08: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 l8AL8SBl094016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 14:08: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 l8AL8SHx094015; Mon, 10 Sep 2007 14:08: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 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 l8AL8PTt094006 for ; Mon, 10 Sep 2007 14:08: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: Multiple TAAs Date: Mon, 10 Sep 2007 14:09:37 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple TAAs Thread-Index: Acfz4dYarmxuN/EdQ9STxPx8CYsPrgAC+dZA From: "Thomas Hardjono" To: "Stephen Kent" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l8AL8RTt094009 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: Monday, September 10, 2007 12:13 PM > To: Black_David@emc.com > Cc: ietf-trust-anchor@vpnc.org > Subject: RE: Multiple TAAs > ..... > > > >And let's assume that the enterprise security administrator > is also the > >only authorized source for IKE authentication TA management, > since that > >comes up in the next paragraph. There are three classes of > >entities: > > - device vendor > > - application proxy vendors > > - enterprise security administrator > >and there's no overlap among the classes, although I could > envision the > >device vendor supplying some initial application proxies with the > >device. > > I would expect that the device vendor might also be a proxy > supplier, both initially and perhaps throughout the life of > the product. Hmmm, there are plenty of Enterprises who only allow their IT guys to perform any and all updates (software and firmware). Employees are prohibited from installing anything. These IT guys turn-off Windows auto update on all clients. In such Enterprises, the IT guy is the sole TAA. He/she downloads all software and firmware updates, tests them and then (if ok) pushes them out to the client machines through the internal network. However, this is perhaps orthogonal to a technically sound TAM solution (which should allow the Enterprise to designate multiple TAAs). /thomas/ From owner-ietf-trust-anchor Tue Sep 11 07:09: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 l8BE9C3j094087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2007 07:09: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 l8BE9Cj3094084; Tue, 11 Sep 2007 07:09: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8BE9BIs094074 for ; Tue, 11 Sep 2007 07:09:11 -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 1IV6QR-0003PA-45; Tue, 11 Sep 2007 10:09:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 11 Sep 2007 10:08:57 -0400 To: "Thomas Hardjono" From: Stephen Kent Subject: RE: Multiple TAAs 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:09 PM -0700 9/10/07, Thomas Hardjono wrote: > >... > >Hmmm, there are plenty of Enterprises who only allow their IT guys to >perform any and all updates (software and firmware). Employees are >prohibited from installing anything. These IT guys turn-off Windows auto >update on all clients. In such Enterprises, the IT guy is the sole TAA. >He/she downloads all software and firmware updates, tests them and then >(if ok) pushes them out to the client machines through the internal >network. good point; that is a more appropriate model in such contexts. But, even if the IT guy is the TAA, he will want to install TAs that are constrained in what they are used to verify, which is consistent with the need to interpret TA data to enforce such constraints. >However, this is perhaps orthogonal to a technically sound TAM solution >(which should allow the Enterprise to designate multiple TAAs). > >/thomas/ no argument there. Steve From owner-ietf-trust-anchor Tue Sep 11 07:09: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 l8BE9CFe094090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2007 07:09: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 l8BE9CAm094089; Tue, 11 Sep 2007 07:09: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 mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8BE9BdP094073 for ; Tue, 11 Sep 2007 07:09:11 -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 1IV6QQ-0003PA-4l; Tue, 11 Sep 2007 10:09:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <004901c7e426$ad24f8c0$0301a8c0@Wylie> <01fd01c7e642$2832db00$0301a8c0@Wylie> Date: Tue, 11 Sep 2007 10:06:55 -0400 To: Black_David@emc.com From: Stephen Kent Subject: RE: Multiple TAAs 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 4:30 PM -0400 9/10/07, Black_David@emc.com wrote: >Steve, > >> >In the specific area of application proxy software verification, >> >I'm pushing the complexity of determining whether a TA can >> >verify a software package into the PKIX certificate infrastructure >> >that can already handle it - I'd like to keep that area of >> >functionality out of the TA management protocol beyond the >> >ability of a TA to include a certificate. >> >> If you're saying that the per-vendor granularity is best managed by a >> cert extension of the sort I suggested, I guess I agree. But, that is >> an example of using a cert-specific capability to achieve the needed >> granularity of authorization management. Is your point that this is > > now a TA feature, but not TAA feature? > >Yes, specifically: > >> > I might >> > be about to concede part of Steve's point by arguing that for the >> > proxy trust store, the TA has to include a certificate signed by >> > the device vendor and the prefix OID of the packages that TA can >> > verify has to be in the certificate. > >and the code that handles proxy software download knows to check that >OID against the code package. > David, OK. I am clearer on what you're thinking is here. I am concerned that, in order to adopt the simple TA store model, we have to make other software be more knowledgeable about the authorization semantics associated with signatures. I guess we have a law of conservation of complexity at work here :-), i.e., we're moving complexity from one area (TA management) into another (signed package processing). I agree that one can do this, but the result is a less full-featured TA management capability than what I had envisioned was required. I'll see if I can come up with examples where the management of TAs per se requires interpretation of TA data, and is not satisfied by the TA store model. Stev e From owner-ietf-trust-anchor Wed Sep 12 07:05: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 l8CE5U7Q053633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Sep 2007 07:05: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 l8CE5Up5053632; Wed, 12 Sep 2007 07:05: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 woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l8CE5SWr053616 for ; Wed, 12 Sep 2007 07:05:29 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200709121405.l8CE5SWr053616@balder-227.proper.com> Received: (qmail 29290 invoked from network); 12 Sep 2007 14:05:21 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 12 Sep 2007 14:05:21 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Sep 2007 08:58:11 -0400 To: ietf-trust-anchor@vpnc.org From: Russ Housley Subject: Re: Issue with the requirements document: PKIX-centric terminology Cc: weiler@tislabs.com In-Reply-To: <46C2FE40.4040003@nist.gov> References: <886F5D4C78AFB14D87261206BFB9612E1D31D34D@scygmxs1.cygnacom.com> <46BCC0CC.2040805@cs.tcd.ie> <46C2FE40.4040003@nist.gov> 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: I think that the protocol needs to be able to support X.509, OpenPGP, DNSSEC, and other protocol environments that make use of public keys for validating digital signatures. That said, I strongly believe that the most urgent need is X.509, so that should be the priority. From my reading of this mail list, no one is suggesting otherwise. Jon Callas has described a situation where a trust anchor management protocol would be useful in Open PGP. He is one of the experts in that protocol environment, so I do not need to build on his comments. Steve Kent has reported that Mike St. Johns does not see a need for a trust anchor management protocol in the DNSSEC protocol environment. I hope Mike is right, but I fear that he is not. The politics are the impediment to deployment of the DNSSEC strict hierarchy. As a result, alternatives to the strict hierarchy are emerging. For example, the IESG just approved the publication of draft-weiler-dnssec-dlv as an Informational RFC. There are may possible ways that this protocol could be used. Personally, I hope the existence of an alternative will help sort out the politics around the strict hierarchy, but if that does not happen there may be a need for a trust anchor management protocol in the DNSSEC environment. Stephen Farrell has stated that there is very low overhead in adding support for trust anchors beyond the X.509 environment. He is certainly correct, at least from the syntax perspective. CMS is primarily used with X.509 certificates, but it also supports other certificate formats. At one point, Some folks in the Open PGP community were considering a document that would describe how to use PGP keys with CMS. I do not know the status of that effort, but it has not yet reached IETF Last Call. My point in raising this example is that the syntax is very straightforward, but there may be important things to say about the semantics in each protocol environment. I think the best way forward it to design a protocol syntax that supports all of these protocol environments. Flesh out the X.509 environment semantics in the initial document, and then write other documents to address the semantics of the other protocol environments as the need (and interest) emerges. Russ From owner-ietf-trust-anchor Mon Sep 17 13:46: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 l8HKkrpx090702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2007 13:46: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 l8HKkrxo090701; Mon, 17 Sep 2007 13:46: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l8HKkqd4090694 for ; Mon, 17 Sep 2007 13:46:53 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 15858 invoked from network); 17 Sep 2007 20:43:05 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;17 Sep 2007 20:43:05 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 17 Sep 2007 20:43:05 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Sep 2007 16:46:51 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D3F98EC@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-trust-anchor@vpnc.org Subject: -02 problem statement draft Date: Mon, 17 Sep 2007 16:46:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F96B.DFE14522" 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_01C7F96B.DFE14522 Content-Type: text/plain The -02 problem statement draft was submitted last week. Not sure why there was no annoucement. It can be found here: http://tools.ietf.org/html/draft-wallace-ta-mgmt-problem-statement-02. ------_=_NextPart_001_01C7F96B.DFE14522 Content-Type: text/html Content-Transfer-Encoding: quoted-printable -02 problem statement draft

The -02 problem statement draft was submitted last = week.  Not sure why there was no annoucement.  It can be = found here: http://tools.ietf.org/html/draft-wallace-ta-mgmt-probl= em-statement-02.

------_=_NextPart_001_01C7F96B.DFE14522-- From owner-ietf-trust-anchor Wed Sep 19 09:19: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 l8JGJsqn023153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2007 09:19: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 l8JGJs7T023152; Wed, 19 Sep 2007 09:19: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 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 l8JGJo0F023140 for ; Wed, 19 Sep 2007 09:19:53 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 74537 invoked from network); 19 Sep 2007 16:19:50 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.38.93 with login) by smtp108.biz.mail.re2.yahoo.com with SMTP; 19 Sep 2007 16:19:50 -0000 X-YMail-OSG: lakQ6aUVM1mNFKiIm7J8f9aCXQIKYCcANaxTkUgDobvdRDkRcflcgs_8DSNOsn0FKPlHGlRVew-- From: "Turner, Sean P." To: Subject: Updating charter d03 Date: Wed, 19 Sep 2007 12:18:35 -0400 Organization: IECA, Inc. Message-ID: <00f201c7fad8$bc9156f0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Acf62Lp40tRxmqxZTWq+XIT5mVoxiw== Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Before I post d04 of the charter I want to make sure I've properly captured the suggested and implied changes: a) To address the number of TAAs it seems like we could collapse the 1st and 2nd scope bullets: - Supporting a single trust anchor administrator, such as in a typical enterprise, who may be administering multiple trust anchors in her domain - Supporting multiple trust anchor administrators, such as is typical for home users in to one bullet: - Supporting systems the require a single trust anchor administrator and systems that require multiple trust anchor administrators b) In last in scope bullet change "may or many not" to "may or may not" so that it now reads "Supporting devices that may or may not be connected to the Internet at the time of management (e.g., relying on physical delivery of trust anchor management messages)" c) As Russ pointed out there may be more than one specification, change the last bullet from "A standards track trust anchor management protocol specification" to "Standards track trust anchor management protocol specifications" Steve Kent indicated that the TAA was undefined. I'm hoping to avoid including the TAA definition in the charter and that we can do that in the deliverables. Have I missed any others? spt From owner-ietf-trust-anchor Tue Oct 2 08:31: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 l92FVA0u066108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2007 08:31: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 l92FVAhs066107; Tue, 2 Oct 2007 08:31: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 [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 l92FV7TD066098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2007 08:31:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <00f201c7fad8$bc9156f0$0301a8c0@Wylie> References: <00f201c7fad8$bc9156f0$0301a8c0@Wylie> Date: Tue, 2 Oct 2007 08:31:01 -0700 To: "Turner, Sean P." , From: Paul Hoffman Subject: Re: Updating charter d03 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: Given no discussion in about two weeks, please post the whole proposed new charter so we can move forwards on it. --Paul Hoffman At 12:18 PM -0400 9/19/07, Turner, Sean P. wrote: >Before I post d04 of the charter I want to make sure I've properly captured >the suggested and implied changes: > >a) To address the number of TAAs it seems like we could collapse the 1st and >2nd scope bullets: > >- Supporting a single trust anchor administrator, such as in a typical >enterprise, who may be administering multiple trust anchors in her domain >- Supporting multiple trust anchor administrators, such as is typical for >home users > >in to one bullet: > >- Supporting systems the require a single trust anchor administrator and >systems that require multiple trust anchor administrators > >b) In last in scope bullet change "may or many not" to "may or may not" so >that it now reads "Supporting devices that may or may not be connected to >the Internet at the time of management (e.g., relying on physical delivery >of trust anchor management messages)" > >c) As Russ pointed out there may be more than one specification, change the >last bullet from "A standards track trust anchor management protocol >specification" to "Standards track trust anchor management protocol >specifications" > >Steve Kent indicated that the TAA was undefined. I'm hoping to avoid >including the TAA definition in the charter and that we can do that in the >deliverables. > >Have I missed any others? > >spt From owner-ietf-trust-anchor Tue Oct 2 09:37: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 l92GbcdG075081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2007 09:37: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 l92GbcOR075080; Tue, 2 Oct 2007 09:37: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 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 l92GbbIL075070 for ; Tue, 2 Oct 2007 09:37:37 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 57228 invoked from network); 2 Oct 2007 16:37:36 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.36.145 with login) by smtp101.biz.mail.re2.yahoo.com with SMTP; 2 Oct 2007 16:37:36 -0000 X-YMail-OSG: Gir.JU4VM1lXLnL8.Q3JbQSpENbC.6Y7jEems8roXUHS4YuTzJqQ62xl2Z9B6wxfOKMMMYGT4moLLhf14vrfjftu.x1wMb2gqOa5jCPEpMUTmeOXPheXgLsCEYXf_wGvsQn1Lvqm5zIDww-- From: "Turner, Sean P." To: Subject: Strawman Charter d04 Date: Tue, 2 Oct 2007 12:35:45 -0400 Organization: IECA, Inc. Message-ID: <01c501c80512$4813da70$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: AcgFEkehnxFndiHnTeW6rRVATYKEwQ== 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: Strawman charter for trust anchor management (tam) Version: 04, October 2nd 2007 Chair(s) TBD Security Area Director(s): - Tim Polk - Sam Hartman Security Area Advisor: TBD Mailing Lists: General Discussion: ietf-trust-anchor@vpnc.org To Subscribe: http://www.vpnc.org/ietf-trust-anchor/ Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/ Description of Working Group: The need for a standard protocol for trust anchor management has been recognized for some time. Many groups within the IETF, including PKIX, Kerberos, TLS and SIDR have a dependency on trust anchors, yet provide no generic mechanism for the their management. A trust anchor represents an authoritative entity represented via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. Relying parties use trust anchors to determine if digitally signed information objects are valid by verifying digital signatures using the trust anchor's public key and by enforcing the constraints expressed in the associated data. Despite the wide-spread use of trust anchors, there is no standard means for managing these security-critical data. This Working Group will develop a specification to fill this gap. The initial problem statement for this work is to be based on: - draft-wallace-ta-mgmt-problem-statement The scope of the work is to include: - Supporting a single trust anchor administrator, such as in a typical enterprise, who may be administering multiple trust anchor stores in her domain - Supporting multiple trust anchor administrators, such as is typical for home users - Supporting systems with limited or no user interface - Supporting devices that may or may not be connected to the Internet at the time of management (e.g., relying on physical delivery of trust anchor management messages) The following are out of scope of this work: - Management of non-anchor signature validation objects such as intermediate certificates in a validation path. - Mandating whether the recipient of trust anchors from a trust anchor manager will use those anchors. The deliverables will be: - An informational problem statement/requirements specification for a trust anchor management protocol - Standards track trust anchor management protocol specifications Goals and Milestones: +6 months WG last call on problem statement/requirements +9 months Adoption of WG draft protocol spec. +15 months WG last call for protocol spec. From owner-ietf-trust-anchor Tue Oct 2 10:18: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 l92HI03r079607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2007 10:18: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 l92HI0Q4079606; Tue, 2 Oct 2007 10:18: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 l92HHumk079590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2007 10:17:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <01c501c80512$4813da70$0301a8c0@Wylie> References: <01c501c80512$4813da70$0301a8c0@Wylie> Date: Tue, 2 Oct 2007 10:17:55 -0700 To: "Turner, Sean P." , From: Paul Hoffman Subject: Re: Strawman Charter d04 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:35 PM -0400 10/2/07, Turner, Sean P. wrote: >The scope of the work is to include: > >- Supporting a single trust anchor administrator, such as in a typical >enterprise, who may be administering multiple trust anchor stores in her >domain >- Supporting multiple trust anchor administrators, such as is typical for >home users I stil support your earlier proposal to combine these into a single bullet: - Supporting systems the require a single trust anchor administrator and systems that require multiple trust anchor administrators Does anyone object to this change? --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Oct 4 08:57: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 l94FvCuM022238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2007 08:57: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 l94FvCZL022237; Thu, 4 Oct 2007 08:57: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 smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l94FvATk022230 for ; Thu, 4 Oct 2007 08:57:11 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 46928 invoked from network); 4 Oct 2007 15:57:10 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.36.145 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 4 Oct 2007 15:57:09 -0000 X-YMail-OSG: IvR3ZWMVM1mgaFgrkbFlgXalM3YJUtiN8iibIuh_dV5hqIYEOvHRGYoC3jdVDThM6zjFPO2GP0xkqXwkw4Gp5KBE57ivKYxHefFhzd5YnPyiG5xNrJtYQRX3VlCx5LUgAyTi.QOOg2Kc7jQ- From: "Turner, Sean P." To: Subject: Strawman Charter d05 Date: Thu, 4 Oct 2007 11:55:05 -0400 Organization: IECA, Inc. Message-ID: <00e601c8069e$ee705dc0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgGnu4C/0pXGTY8Qa2B6BT7MX/3IQ== Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Strawman charter for trust anchor management (tam) Version: 05, October 4th 2007 Chair(s) TBD Security Area Director(s): - Tim Polk - Sam Hartman Security Area Advisor: TBD Mailing Lists: General Discussion: ietf-trust-anchor@vpnc.org To Subscribe: http://www.vpnc.org/ietf-trust-anchor/ Archive: http://www.vpnc.org/ietf-trust-anchor/mail-archive/ Description of Working Group: The need for a standard protocol for trust anchor management has been recognized for some time. Many groups within the IETF, including PKIX, Kerberos, TLS and SIDR have a dependency on trust anchors, yet provide no generic mechanism for the their management. A trust anchor represents an authoritative entity represented via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. Relying parties use trust anchors to determine if digitally signed information objects are valid by verifying digital signatures using the trust anchor's public key and by enforcing the constraints expressed in the associated data. Despite the wide-spread use of trust anchors, there is no standard means for managing these security-critical data. This Working Group will develop a specification to fill this gap. The initial problem statement for this work is to be based on: - draft-wallace-ta-mgmt-problem-statement The scope of the work is to include: - Supporting systems the require a single trust anchor administrator and systems that require multiple trust anchor administrators - Supporting systems with limited or no user interface - Supporting devices that may or may not be connected to the Internet at the time of management (e.g., relying on physical delivery of trust anchor management messages) The following are out of scope of this work: - Management of non-anchor signature validation objects such as intermediate certificates in a validation path. - Mandating whether the recipient of trust anchors from a trust anchor manager will use those anchors. The deliverables will be: - An informational problem statement/requirements specification for a trust anchor management protocol - Standards track trust anchor management protocol specifications Goals and Milestones: +6 months WG last call on problem statement/requirements +9 months Adoption of WG draft protocol spec. +15 months WG last call for protocol spec. From owner-ietf-trust-anchor Thu Oct 4 09:35: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 l94GZCkh026027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2007 09:35: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 l94GZCJJ026026; Thu, 4 Oct 2007 09:35: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l94GZBFG026018 for ; Thu, 4 Oct 2007 09:35:11 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200710041635.l94GZBFG026018@balder-227.proper.com> Received: (qmail 23919 invoked by uid 0); 4 Oct 2007 16:35:05 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (207.236.147.202) by woodstock.binhost.com with SMTP; 4 Oct 2007 16:35:05 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 04 Oct 2007 12:35:04 -0400 To: ietf-trust-anchor@vpnc.org From: Russ Housley Subject: For your consideration: TAMP and CCC Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The Trust Anchor Management Protocol (TAMP) specification has been submitted for your consideration.  The draft was developed primarily to support trust anchor management for cryptographic modules with an assumption that the module would manage a single trust anchor store.  As such, there are some aspects of the specification that are out of alignment with the direction that this group seems to be taking.  Specific items that are likely to change include the following:

- Throughout the draft, the term "cryptographic module" can often be read as "trust anchor store".  If I understand the direction of the group, then a focus on the trust anchor store is more appropriate.

- Messages are targeted using hardware-centric names.  I think this approach is one that ought to be supported, but there are probably others.  At a minimum we should consider multiple trust anchor stores on the same device.

- The mail list has discussed trust anchor types, but this draft defines a structure for trust anchors that are used in the validation of  X.509 certification paths and signatures on CMS objects that are directly signed by the trust anchor.    At a minimum, I think that it is important to add a hook for other trust anchor types.

Additionally, some changes are planned for the section that describes the processing of TAMPUpdate messages.  Additional language describing path processing in support of TAMP update processing will be added and the CertPathControls feature will be subject to subordination rules.

The TAMP draft is accompanied by another draft: Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate Extension (CCC).  The CCC draft defines a certificate extension to handle delegation of privileges expressed in TAMP via the TrustAnchorUsage type.  This certificate extension is used to determine whether the public key in an X.509 public key certificate is appropriate to use in the processing of a CMS-protected content.

The drafts are available at these locations:
http ://www.ietf.org/internet-drafts/draft-housley-tamp-00.txt
http://www.ietf.org/internet-drafts/draft-housley-cms-content-constraints-extn-00.txt
From owner-ietf-trust-anchor Thu Oct 4 10:19: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 l94HJtRY030723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2007 10:19: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 l94HJtvt030722; Thu, 4 Oct 2007 10:19: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 mail.newbay.com (089-101-140017.ntlworld.ie [89.101.140.17] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l94HJqPU030709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Oct 2007 10:19:54 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 083F410040771; Thu, 4 Oct 2007 18:19:52 +0100 (IST) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JApeXBBHbhzQ; Thu, 4 Oct 2007 18:19:41 +0100 (IST) Received: from [127.0.0.1] (Stephen-Laptop.newbay.com [192.168.2.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id 270EA1004076E; Thu, 4 Oct 2007 18:19:40 +0100 (IST) Message-ID: <470520AB.5090506@cs.tcd.ie> Date: Thu, 04 Oct 2007 18:19:39 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Russ Housley CC: ietf-trust-anchor@vpnc.org Subject: Re: For your consideration: TAMP and CCC References: <200710041635.l94GZBFG026018@balder-227.proper.com> In-Reply-To: <200710041635.l94GZBFG026018@balder-227.proper.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks Russ, I think that those should provide excellent material to move discussions on the list along. (Mind you, at 91 pages, it might take a while to digest;-) Cheers, Stephen. Russ Housley wrote: > The Trust Anchor Management Protocol (TAMP) specification has been > submitted for your consideration. The draft was developed primarily to > support trust anchor management for cryptographic modules with an > assumption that the module would manage a single trust anchor store. As > such, there are some aspects of the specification that are out of > alignment with the direction that this group seems to be taking. > Specific items that are likely to change include the following: > > - Throughout the draft, the term "cryptographic module" can often be > read as "trust anchor store". If I understand the direction of the > group, then a focus on the trust anchor store is more appropriate. > > - Messages are targeted using hardware-centric names. I think this > approach is one that ought to be supported, but there are probably > others. At a minimum we should consider multiple trust anchor stores on > the same device. > > - The mail list has discussed trust anchor types, but this draft defines > a structure for trust anchors that are used in the validation of X.509 > certification paths and signatures on CMS objects that are directly > signed by the trust anchor. At a minimum, I think that it is > important to add a hook for other trust anchor types. > > Additionally, some changes are planned for the section that describes > the processing of TAMPUpdate messages. Additional language describing > path processing in support of TAMP update processing will be added and > the CertPathControls feature will be subject to subordination rules. > > The TAMP draft is accompanied by another draft: Cryptographic Message > Syntax (CMS) Content Constraints X.509 Certificate Extension (CCC). The > CCC draft defines a certificate extension to handle delegation of > privileges expressed in TAMP via the TrustAnchorUsage type. This > certificate extension is used to determine whether the public key in an > X.509 public key certificate is appropriate to use in the processing of > a CMS-protected content. > > The drafts are available at these locations: > http > ://www.ietf.org/internet-drafts/draft-housley-tamp-00.txt > > http://www.ietf.org/internet-drafts/draft-housley-cms-content-constraints-extn-00.txt > From owner-ietf-trust-anchor Sun Oct 14 08:20:29 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 l9EFKTLN055937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Oct 2007 08:20:29 -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 l9EFKTQ3055936; Sun, 14 Oct 2007 08:20: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 michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9EFKRqR055930 for ; Sun, 14 Oct 2007 08:20:28 -0700 (MST) (envelope-from ynir@checkpoint.com) Received: from [91.90.139.173] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l9EFKQTh010685 for ; Sun, 14 Oct 2007 17:20:26 +0200 (IST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <200710041635.l94GZBFG026018@balder-227.proper.com> References: <200710041635.l94GZBFG026018@balder-227.proper.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18--680350263; protocol="application/pkcs7-signature" Message-Id: <6B16241E-3912-4644-A740-2194BE18174D@checkpoint.com> From: Yoav Nir Subject: Re: For your consideration: TAMP and CCC Date: Sun, 14 Oct 2007 17:20:14 +0200 To: ietf-trust-anchor@vpnc.org X-Mailer: Apple Mail (2.752.3) Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-18--680350263 Content-Type: multipart/alternative; boundary=Apple-Mail-17--680350451 --Apple-Mail-17--680350451 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed OK. I've finally managed to read this, although not as thoroughly as I would have liked to. The TAMP protocol described in the draft describes a "cryptographic module" or trust anchor store that has three tiers of trust anchors - Apex TA - exactly one of those. Has two key pairs. One is only used in the replacement of the Apex TA. - Mgmt TA - one or more of those - Identity TA - several of those - they're the regular trust anchors, such as the CA certs in a browser. - The protocol specifies messages used in managing the trust anchor stores. - The Apex TA represents the ultimate authority (owner of the cryptographic module?) and is used to manage Mgmt TAs, Mgmt TAs are used to manage identity TAs. - All the messages in the protocol are requests or responses. All requests have responses. Requests must be signed, responses should be. Problems I see: 1. It's always request-response. the store-and-forward, or email scenario is missing, but it could probably be added. 2. There is no association between identity TA and the Mgmt TA that added it. You can't have an operation like "erase the Mgmt TA and everything it added", which I think is important. 3. You can query whether a particular TA is present, but you can't ask for a list of all present TAs. 4. You can delete a particular TA, but you can't delete a group or all TAs. You may want this if you want to erase all current TAs and add a new list. 5. The mandatory Apex TA. I can see cases where the user or owner manually controls the list of Mgmt TAs, and using the protocol just for the Identity TAs. That's about what I've seen. Thoughts? On Oct 4, 2007, at 6:35 PM, Russ Housley wrote: > The Trust Anchor Management Protocol (TAMP) specification has been > submitted for your consideration. The draft was developed > primarily to support trust anchor management for cryptographic > modules with an assumption that the module would manage a single > trust anchor store. As such, there are some aspects of the > specification that are out of alignment with the direction that > this group seems to be taking. Specific items that are likely to > change include the following: > > - Throughout the draft, the term "cryptographic module" can often > be read as "trust anchor store". If I understand the direction of > the group, then a focus on the trust anchor store is more appropriate. > > - Messages are targeted using hardware-centric names. I think this > approach is one that ought to be supported, but there are probably > others. At a minimum we should consider multiple trust anchor > stores on the same device. > > - The mail list has discussed trust anchor types, but this draft > defines a structure for trust anchors that are used in the > validation of X.509 certification paths and signatures on CMS > objects that are directly signed by the trust anchor. At a > minimum, I think that it is important to add a hook for other trust > anchor types. > > Additionally, some changes are planned for the section that > describes the processing of TAMPUpdate messages. Additional > language describing path processing in support of TAMP update > processing will be added and the CertPathControls feature will be > subject to subordination rules. > > The TAMP draft is accompanied by another draft: Cryptographic > Message Syntax (CMS) Content Constraints X.509 Certificate > Extension (CCC). The CCC draft defines a certificate extension to > handle delegation of privileges expressed in TAMP via the > TrustAnchorUsage type. This certificate extension is used to > determine whether the public key in an X.509 public key certificate > is appropriate to use in the processing of a CMS-protected content. > > The drafts are available at these locations: > http ://www.ietf.org/internet-drafts/draft-housley-tamp-00.txt > http://www.ietf.org/internet-drafts/draft-housley-cms-content- > constraints-extn-00.txt --Apple-Mail-17--680350451 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
OK. I've finally managed to = read this, although not as thoroughly as I would have liked = to.

The TAMP = protocol described in the draft describes a "cryptographic module" or = trust anchor store that has three tiers of trust anchors
- = Apex TA - exactly one of those. Has two key pairs. One is only used in = the replacement of the Apex TA.
- Mgmt TA - one or more of = those
- Identity TA - several of those - they're the regular = trust anchors, such as the CA certs in a browser.

- The protocol specifies = messages used in managing the trust anchor stores.
- The Apex = TA represents the ultimate authority (owner of the cryptographic = module?) and is used to manage Mgmt TAs, Mgmt TAs are used to manage = identity TAs.
- All the messages in the protocol are requests = or responses. All requests have responses. Requests must be signed, = responses should be.

Problems I = see:
1. It's always request-response. the store-and-forward, = or email scenario is missing, but it could probably be = added.
2. There is no association between identity TA and the = Mgmt TA that added it.=A0 You can't have an operation like "erase the = Mgmt TA and everything it added", which I think is = important.
3. You can query whether a particular TA is = present, but you can't ask for a list of all present TAs.
4. = You can delete a particular TA, but you can't delete a group or all TAs. = You may want this if you want to erase all current TAs and add a new = list.
5. The mandatory Apex TA. I can see cases where the user = or owner manually controls the list of Mgmt TAs, and using the protocol = just for the Identity TAs.

That's about what I've = seen. Thoughts?

On Oct 4, 2007, at 6:35 PM, Russ = Housley wrote:

The Trust Anchor Management Protocol = (TAMP) specification has been submitted for your consideration.=A0 The = draft was developed primarily to support trust anchor management for = cryptographic modules with an assumption that the module would manage a = single trust anchor store.=A0 As such, there are some aspects of the = specification that are out of alignment with the direction that this = group seems to be taking.=A0 Specific items that are likely to change = include the following:

- Throughout the draft, the term = "cryptographic module" can often be read as "trust anchor store".=A0 If = I understand the direction of the group, then a focus on the trust = anchor store is more appropriate.

- Messages are targeted using = hardware-centric names.=A0 I think this approach is one that ought to be = supported, but there are probably others.=A0 At a minimum we should = consider multiple trust anchor stores on the same device.

- The = mail list has discussed trust anchor types, but this draft defines a = structure for trust anchors that are used in the validation of=A0 X.509 = certification paths and signatures on CMS objects that are directly = signed by the trust anchor.=A0=A0=A0 At a minimum, I think that it is = important to add a hook for other trust anchor types.

= Additionally, some changes are planned for the section that describes = the processing of TAMPUpdate messages.=A0 Additional language describing = path processing in support of TAMP update processing will be added and = the CertPathControls feature will be subject to subordination = rules.

The TAMP draft is accompanied by another draft: = Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate = Extension (CCC).=A0 The CCC draft defines a certificate extension to = handle delegation of privileges expressed in TAMP via the = TrustAnchorUsage type.=A0 This certificate extension is used to = determine whether the public key in an X.509 public key certificate is = appropriate to use in the processing of a CMS-protected content.

= The drafts are available at these locations:
= = http = ://www.ietf.org/internet-drafts/draft-housley-tamp-00.txt =
= http://www.ietf.org/internet-drafts/draft-housley-cms-content-constraints-= extn-00.txt

= --Apple-Mail-17--680350451-- --Apple-Mail-18--680350263 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTAxNDE1 MjAxNFowIwYJKoZIhvcNAQkEMRYEFN8Yxd2Q9PvoogIB7vqITc9TNsccMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQBiS9NZfceX M+G146Ont/3qZyDucNWsf0AUQ/Py+YwTloRDDoWXDBE3QUUjctQE0q945LMAqKFxic6fY6exwHlm UJzw5GhjqMc73/JRmlaBqhLIfmMbih63gVhDgYU0wAYPAXAkDuDd3sTaKYh3qqm0+n0c74Rrrmud feXSb1UzO+Bm3mUEAHUAgK8t6hApSiZkUP62+ziLUuA1THpTrvxCHdn+5KGi9m7QRhjzWGN0cGB2 mfWsptbBByn9iYOQV/8UOEMN9gjyN2GSkPfv4fFlxKLJGGI4JJIBnvFD2BZjnWnhNNmYdCKKFdQm RCuCEEG3M0TIJRqI3/Z/ckZNwWg/AAAAAAAA --Apple-Mail-18--680350263-- From owner-ietf-trust-anchor Mon Oct 15 05:13: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 l9FCDgt6040817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Oct 2007 05:13: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 l9FCDgFf040816; Mon, 15 Oct 2007 05:13: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l9FCDfgW040809 for ; Mon, 15 Oct 2007 05:13:42 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 6033 invoked from network); 15 Oct 2007 12:09:05 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;15 Oct 2007 12:09:05 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 15 Oct 2007 12:09:05 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Oct 2007 08:13:32 -0400 Message-ID: From: Carl Wallace To: Yoav Nir , ietf-trust-anchor@vpnc.org Subject: RE: For your consideration: TAMP and CCC Date: Mon, 15 Oct 2007 08:13:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80F24.CB884106" 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_01C80F24.CB884106 Content-Type: text/plain Responses inline... From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Yoav Nir Sent: Sunday, October 14, 2007 11:20 AM To: ietf-trust-anchor@vpnc.org Subject: Re: For your consideration: TAMP and CCC OK. I've finally managed to read this, although not as thoroughly as I would have liked to. The TAMP protocol described in the draft describes a "cryptographic module" or trust anchor store that has three tiers of trust anchors - Apex TA - exactly one of those. Has two key pairs. One is only used in the replacement of the Apex TA. - Mgmt TA - one or more of those - Identity TA - several of those - they're the regular trust anchors, such as the CA certs in a browser. [CRW] The number of Mgmt and Identity TAs could vary depending on the purpose of a trust store. Though not really intended by the spec, a trust store could feature just an Apex and be managed using only the Apex-related messages. An instance that requires only Identity TAs could have zero Mgmt TAs (but would still require an Apex). A trust store that supports only a limited number of management operations may have zero Identity TAs. - The protocol specifies messages used in managing the trust anchor stores. - The Apex TA represents the ultimate authority (owner of the cryptographic module?) and is used to manage Mgmt TAs, Mgmt TAs are used to manage identity TAs. [CRW] Additionally, an Apex can be used to manage identity TAs and Mgmt TAs can be used to manage other Mgmt TAs. - All the messages in the protocol are requests or responses. All requests have responses. Requests must be signed, responses should be. Problems I see: 1. It's always request-response. the store-and-forward, or email scenario is missing, but it could probably be added. 2. There is no association between identity TA and the Mgmt TA that added it. You can't have an operation like "erase the Mgmt TA and everything it added", which I think is important. [CRW] It wouldn't be difficult to add an association, but the removal operation could get tricky, particularly if multiple trust anchor managers collaborate on the definition of a particular trust anchor. Maybe an option like you suggest in 4) would cover this well enough, i.e., erase all and use a new list. 3. You can query whether a particular TA is present, but you can't ask for a list of all present TAs. [CRW] The TAMP Status Query response provides a list of all TAs present in a trust store. The terse response option provides just a list of key identifiers. The verbose option provides full details of the TAs that are installed. 4. You can delete a particular TA, but you can't delete a group or all TAs. You may want this if you want to erase all current TAs and add a new list. [CRW] You can delete all TAs, but only when replacing the Apex. You can delete groups of TAs with a single response by including multiple elements in the updates field. Aside from the clearTrustAnchors flag in the TAMPApexUpdate message, there is currently no short hand instruction for removing groups of trust anchors. 5. The mandatory Apex TA. I can see cases where the user or owner manually controls the list of Mgmt TAs, and using the protocol just for the Identity TAs. [CRW] I think you could use one of the manually controlled Mgmt TAs as the Apex then use the protocol for Identity TA management. That's about what I've seen. Thoughts? ------_=_NextPart_001_01C80F24.CB884106 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: For your consideration: TAMP and CCC

Responses inline...

From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-= trust-anchor@mail.vpnc.org] On Behalf Of Yoav Nir
Sent: Sunday, October 14, 2007 11:20 AM
To: ietf-trust-anchor@vpnc.org
Subject: Re: For your consideration: TAMP and = CCC
       =20
       =20
OK. I've finally managed to read this, although not = as thoroughly as I would have liked to.

The TAMP protocol described in the draft describes a = "cryptographic module" or trust anchor store that has three = tiers of trust anchors

- Apex TA - exactly one of those. Has two key pairs. = One is only used in the replacement of the Apex TA.
- Mgmt TA - one or more of those
- Identity TA - several of those - they're the = regular trust anchors, such as the CA certs in a browser.

[CRW] The number of Mgmt and Identity TAs could vary = depending on the purpose of a trust store.  Though not really = intended by the spec, a trust store could feature just an Apex and be = managed using only the Apex-related messages.  An instance that = requires only Identity TAs could have zero Mgmt TAs (but would still = require an Apex).  A trust store that supports only a limited = number of management operations may have zero Identity TAs.

- The protocol specifies messages used in managing = the trust anchor stores.
- The Apex TA represents the ultimate authority = (owner of the cryptographic module?) and is used to manage Mgmt TAs, = Mgmt TAs are used to manage identity TAs.

[CRW] Additionally, an Apex can be used to manage = identity TAs and Mgmt TAs can be used to manage other Mgmt TAs.

- All the messages in the protocol are requests or = responses. All requests have responses. Requests must be signed, = responses should be.

Problems I see:
1. It's always request-response. the = store-and-forward, or email scenario is missing, but it could probably = be added.

2. There is no association between identity TA and = the Mgmt TA that added it. You can't have an operation like "erase = the Mgmt TA and everything it added", which I think is = important.

[CRW] It wouldn't be difficult to add an association, = but the removal operation could get tricky, particularly if multiple = trust anchor managers collaborate on the definition of a particular = trust anchor.  Maybe an option like you suggest in 4) would cover = this well enough, i.e., erase all and use a new list.

3. You can query whether a particular TA is present, = but you can't ask for a list of all present TAs.

[CRW] The TAMP Status Query response provides a list = of all TAs present in a trust store.  The terse response option = provides just a list of key identifiers.  The verbose option = provides full details of the TAs that are installed.

4. You can delete a particular TA, but you can't = delete a group or all TAs. You may want this if you want to erase all = current TAs and add a new list.

[CRW] You can delete all TAs, but only when replacing = the Apex.  You can delete groups of TAs with a single response by = including multiple elements in the updates field.  Aside from the = clearTrustAnchors flag in the TAMPApexUpdate message, there is = currently no short hand instruction for removing groups of trust = anchors. 

5. The mandatory Apex TA. I can see cases where the = user or owner manually controls the list of Mgmt TAs, and using the = protocol just for the Identity TAs.

[CRW] I think you could use one of the manually = controlled Mgmt TAs as the Apex then use the protocol for Identity TA = management. 

That's about what I've seen. Thoughts?

------_=_NextPart_001_01C80F24.CB884106-- From owner-ietf-trust-anchor Thu Oct 18 12:33: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 l9IJXeie094254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 12:33: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 l9IJXeJX094253; Thu, 18 Oct 2007 12:33: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 smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9IJXZRf094243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Oct 2007 12:33:38 -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 l9IJXExU026540; Thu, 18 Oct 2007 15:33:15 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92EC1961-E5DE-407C-AC29-5376323BFBE5@nist.gov> Cc: Stephen Farrell , Sean Turner , Sam Hartman Content-Transfer-Encoding: 7bit From: Tim Polk Subject: selecting a path forward for TAM Date: Thu, 18 Oct 2007 15:33:12 -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: Dear TAM participants, I had a conference call with the BOF co-chairs a few weeks ago concerning the status of the Trust Anchor Management BOF. The group has made a lot of progress, but I am not ready to advocate a new working group at this time. The co-chairs asked me to send an email to the list that summarizes my issues. I should begin by stating that it is clear to me that some form of trust anchor management protocol can and should be pursued in the IETF. It is not clear to me whether a new working group would be the most effective mechanism, or if IETF community would be best served by pursuing this work in an existing working group. Here are the open issues, as I see them: (1) A largely government user community has been clearly established, but broader support is required for real success. In particular, I would like to see more from the vendor community indicate they are likely to adopt the output from TAM. (Please note that "vendor community" is not a euphemism for browser vendors, although they would certainly qualify. There was some indication that network appliances and other infrastructure devices might be the initial adopters. Those vendors would satisfy my requirement as well! I am simply not interested in sponsoring a group unless some vendors are interested in building the spec.) (2) In the Chicago meeting, participants seemed uncertain about the scope of this effort. Numerous participants indicated they would probably implement "it", depending on what "it" turned out to be. I do not believe this issue has been sufficiently resolved. (3) I remain nervous about the level of commitment to participate in the working group. I believe there is sufficient interest to justify a milestone in an existing wg, but have not seen a deep enough pool of players to provide chairs, editors, and revierwers. In my opinion, this is a direct result of (2). Several expressed tentative commitment to participate or implement, contingent on clarifying that scope. As a result, I requested the submission of the draft-housley-tamp-00 draft. I am hoping that a concrete proposal will help the group converge on a definition of "it", and help me to verify that a broad consensus exists to develop and deploy a trust anchor management protocol. To be honest, I was hoping to see a greater volume of traffic, although at 91 pages folks may still be working through a first pass. *Please* take the time to review this draft, and provide your input to the list. This is a critical metric in my opinion towards determining whether TAM is mature enough to charter as a working group or should be integrated into an existing working group. Thanks, Tim Polk From owner-ietf-trust-anchor Wed Nov 21 08:27: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 lALFRUw5016570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 08:27: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 lALFRU4l016569; Wed, 21 Nov 2007 08:27: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 moses.radium.ncsc.mil (moses.radium.ncsc.mil [144.51.73.129]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALFRSRS016548 for ; Wed, 21 Nov 2007 08:27:29 -0700 (MST) (envelope-from r.reddy@radium.ncsc.mil) Received: from exodus.radium.ncsc.mil (exodus.radium.ncsc.mil [144.51.74.11]) by moses.radium.ncsc.mil with ESMTP id lALFUMSG005110; Wed, 21 Nov 2007 15:30:22 GMT Received: from gust.radium.ncsc.mil by exodus.radium.ncsc.mil (8.11.7p3+Sun/SMI-SVR4) id lALFR2Y02772; Wed, 21 Nov 2007 15:27:03 GMT Received: by gust.radium.ncsc.mil with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Nov 2007 10:27:08 -0500 Message-ID: <6660125B6BE0FF42B65E5C7EEA65C38E027AAE89@gust.radium.ncsc.mil> From: "Reddy, Raksha P." To: "'Tim Polk'" , ietf-trust-anchor@vpnc.org Cc: Stephen Farrell , Sean Turner , Sam Hartman , "'kent@bbn.com'" , "'Stefan Santesson'" Subject: RE: selecting a path forward for TAM Date: Wed, 21 Nov 2007 10:27:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At the recommendation of Tim Polk, the TAM effort will be introduced to the PKIX Working Group at the December IETF Meeting. It is felt that the PKIX Working Group will be able to provide a wide audience in order to gain more support in the vendor community for the development and implementation of trust anchor management solutions. A time slot for TAM has already been posted to the PKIX agenda: http://www3.ietf.org/proceedings/07dec/agenda/pkix.txt Please use the PKIX mailing list to continue discussions pertaining to TAM: http://www.imc.org/ietf-pkix/ Thank you, Raksha Reddy -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Tim Polk Sent: Thursday, October 18, 2007 3:33 PM To: ietf-trust-anchor@vpnc.org Cc: Stephen Farrell; Sean Turner; Sam Hartman Subject: selecting a path forward for TAM Dear TAM participants, I had a conference call with the BOF co-chairs a few weeks ago concerning the status of the Trust Anchor Management BOF. The group has made a lot of progress, but I am not ready to advocate a new working group at this time. The co-chairs asked me to send an email to the list that summarizes my issues. I should begin by stating that it is clear to me that some form of trust anchor management protocol can and should be pursued in the IETF. It is not clear to me whether a new working group would be the most effective mechanism, or if IETF community would be best served by pursuing this work in an existing working group. Here are the open issues, as I see them: (1) A largely government user community has been clearly established, but broader support is required for real success. In particular, I would like to see more from the vendor community indicate they are likely to adopt the output from TAM. (Please note that "vendor community" is not a euphemism for browser vendors, although they would certainly qualify. There was some indication that network appliances and other infrastructure devices might be the initial adopters. Those vendors would satisfy my requirement as well! I am simply not interested in sponsoring a group unless some vendors are interested in building the spec.) (2) In the Chicago meeting, participants seemed uncertain about the scope of this effort. Numerous participants indicated they would probably implement "it", depending on what "it" turned out to be. I do not believe this issue has been sufficiently resolved. (3) I remain nervous about the level of commitment to participate in the working group. I believe there is sufficient interest to justify a milestone in an existing wg, but have not seen a deep enough pool of players to provide chairs, editors, and revierwers. In my opinion, this is a direct result of (2). Several expressed tentative commitment to participate or implement, contingent on clarifying that scope. As a result, I requested the submission of the draft-housley-tamp-00 draft. I am hoping that a concrete proposal will help the group converge on a definition of "it", and help me to verify that a broad consensus exists to develop and deploy a trust anchor management protocol. To be honest, I was hoping to see a greater volume of traffic, although at 91 pages folks may still be working through a first pass. *Please* take the time to review this draft, and provide your input to the list. This is a critical metric in my opinion towards determining whether TAM is mature enough to charter as a working group or should be integrated into an existing working group. Thanks, Tim Polk