trust anchor management problem statement

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

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

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

Hello,

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

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

Besides CMS the BOF should definitely also cover = XML.

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

- document specifying define ta in CMS

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

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

- = protocol how to get ta?

Any = opinions?

Tobias

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

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

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

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

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

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

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

I agree the "authority over a device" = language needs improvement. The draft does call out that multiple = trust stores may reside on a particular machine and may be application = specific.
------_=_NextPart_001_01C7B42D.37A39818-- From owner-ietf-trust-anchor Thu Jun 21 11:10:52 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LIAp8I078301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 11:10:51 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LIAp3S078300; Thu, 21 Jun 2007 11:10:51 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LIAn66078278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jun 2007 11:10:50 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id B5780320B8; Thu, 21 Jun 2007 19:10:48 +0100 (IST) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id l5LIAljm009074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jun 2007 19:10:47 +0100 Message-ID: <467ABF90.5040500@cs.tcd.ie> Date: Thu, 21 Jun 2007 19:12:32 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Paul Hoffman CC: ietf-trust-anchor@vpnc.org Subject: Re: Distribution of trust anchor policy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 10530389 - 5761b52b3774 X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Hoffman wrote: > I would rather see this group embrace policy distribution with the trust > anchors than to force the policy into the trust anchors themselves > simply because the policy should be being made by the administrator, not > the authorities who create the trust anchors. I'm a bit confused by that, there seem to be two separable issues:- 1. Some of the more exotic PKIX policy stuff may not be implemented everywhere. 2. You want the admin for this (putative) protocol to control these settings and not a subbordinate CA. I don't see how 1=>2 which is what I thought you were saying above, S. From owner-ietf-trust-anchor Thu Jun 21 11:26:06 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LIQ6US082599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 11:26:06 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LIQ6vn082598; Thu, 21 Jun 2007 11:26:06 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l5LIQ3Hf082580 for ; Thu, 21 Jun 2007 11:26:04 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: (qmail 2847 invoked from network); 21 Jun 2007 18:25:56 -0000 Received: from sharon.boeyen@entrust.com by sottccs1.entrust.com with EntrustECS-Server-8.0;21 Jun 2007 18:25:56 -0000 Received: from unknown (HELO sottexch1.corp.ad.entrust.com) (10.4.51.28) by sottccs1.entrust.com with SMTP; 21 Jun 2007 18:25:56 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Distribution of trust anchor policy Date: Thu, 21 Jun 2007 14:25:59 -0400 Message-ID: <04398A2C9F306C4690265C144089972D01BE7580@sottexch1.corp.ad.entrust.com> In-Reply-To: <467ABF90.5040500@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Distribution of trust anchor policy Thread-Index: Ace0MGjq7cMPJbH6Q22PVY1DwEoQWAAAR0Pw References: <467ABF90.5040500@cs.tcd.ie> From: "Sharon Boeyen" To: "Stephen Farrell" , "Paul Hoffman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5LIQ5Hf082591 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I also think we need to be cautious and keep this focused on actual trust anchors (as opposed to an alternative to cross-certification). -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen Farrell Sent: Thursday, June 21, 2007 2:13 PM To: Paul Hoffman Cc: ietf-trust-anchor@vpnc.org Subject: Re: Distribution of trust anchor policy Paul Hoffman wrote: > I would rather see this group embrace policy distribution with the > trust anchors than to force the policy into the trust anchors > themselves simply because the policy should be being made by the > administrator, not the authorities who create the trust anchors. I'm a bit confused by that, there seem to be two separable issues:- 1. Some of the more exotic PKIX policy stuff may not be implemented everywhere. 2. You want the admin for this (putative) protocol to control these settings and not a subbordinate CA. I don't see how 1=>2 which is what I thought you were saying above, S. From owner-ietf-trust-anchor Thu Jun 21 11:40:12 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LIeCtU086112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 11:40:12 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LIeC1I086111; Thu, 21 Jun 2007 11:40:12 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LIeBns086098; Thu, 21 Jun 2007 11:40:12 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Distribution of trust anchor policy Date: Thu, 21 Jun 2007 11:40:02 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879082B334A@EXVS01.ex.dslextreme.net> In-Reply-To: <467ABF90.5040500@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Distribution of trust anchor policy thread-index: Ace0MOykfAvcAgfMRJ2xlboZJjDHvQAAoZtQ References: <467ABF90.5040500@cs.tcd.ie> From: "Santosh Chokhani" To: "Stephen Farrell" , "Paul Hoffman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5LIeCns086099 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Constraints such as certificate policies, name constraints, policy constraints, should be available to apply to trust anchor so that a TA is not all or nothing proposition. -----Original Message----- From: owner-ietf-trust-anchor@mail.vpnc.org [mailto:owner-ietf-trust-anchor@mail.vpnc.org] On Behalf Of Stephen Farrell Sent: Thursday, June 21, 2007 2:13 PM To: Paul Hoffman Cc: ietf-trust-anchor@vpnc.org Subject: Re: Distribution of trust anchor policy Paul Hoffman wrote: > I would rather see this group embrace policy distribution with the trust > anchors than to force the policy into the trust anchors themselves > simply because the policy should be being made by the administrator, not > the authorities who create the trust anchors. I'm a bit confused by that, there seem to be two separable issues:- 1. Some of the more exotic PKIX policy stuff may not be implemented everywhere. 2. You want the admin for this (putative) protocol to control these settings and not a subbordinate CA. I don't see how 1=>2 which is what I thought you were saying above, S. From owner-ietf-trust-anchor Thu Jun 21 12:08:57 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJ8uGC092362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 12:08:57 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LJ8udh092360; Thu, 21 Jun 2007 12:08:56 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from [10.20.30.108] (adsl-66-125-125-71.dsl.pltn13.pacbell.net [66.125.125.71]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJ8j6h092308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 12:08:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <467ABF90.5040500@cs.tcd.ie> <04398A2C9F306C4690265C144089972D01BE7580@sottexch1.corp.ad.entrust.com> <82D5657AE1F54347A734BDD33637C879082B334A@EXVS01.ex.dslextreme.net> References: <467ABF90.5040500@cs.tcd.ie> <467ABF90.5040500@cs.tcd.ie> <04398A2C9F306C4690265C144089972D01BE7580@sottexch1.corp.ad.entrust.com> <467ABF90.5040500@cs.tcd.ie> <82D5657AE1F54347A734BDD33637C879082B334A@EXVS01.ex.dslextreme.net> Date: Thu, 21 Jun 2007 12:08:32 -0700 To: Stephen Farrell , "Sharon Boeyen" , "Santosh Chokhani" From: Paul Hoffman Subject: Re: Distribution of trust anchor policy Cc: ietf-trust-anchor@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:12 PM +0100 6/21/07, Stephen Farrell wrote: >Paul Hoffman wrote: >>I would rather see this group embrace policy distribution with the >>trust anchors than to force the policy into the trust anchors >>themselves simply because the policy should be being made by the >>administrator, not the authorities who create the trust anchors. > >I'm a bit confused by that, there seem to be two separable >issues:- > >1. Some of the more exotic PKIX policy stuff may not be implemented >everywhere. > >2. You want the admin for this (putative) protocol to control >these settings and not a subbordinate CA. > >I don't see how 1=>2 which is what I thought you were saying >above, Sorry, I meant to say that both #1 and #2 are true, separately. Even if the users have all the PKIX policy stuff implemented, the trust admin should still be able to specify it himself/herself without having to issue additional certs. At 2:25 PM -0400 6/21/07, Sharon Boeyen wrote: >I also think we need to be cautious and keep this focused on actual >trust anchors (as opposed to an alternative to cross-certification). The policy I used in the example (which trust anchor is allowed to vouch for which identities) is not related to cross-certification. In current PKIX terms, a trust anchor is allowed to vouch for any identities whatsoever. At 11:40 AM -0700 6/21/07, Santosh Chokhani wrote: >Constraints such as certificate policies, name constraints, policy >constraints, should be available to apply to trust anchor so that a TA >is not all or nothing proposition. Exactly. --Paul Hoffman, Director --VPN Consortium From owner-ietf-trust-anchor Thu Jun 21 12:15:40 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJFe0Y094071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 12:15:40 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LJFeMD094070; Thu, 21 Jun 2007 12:15:40 -0700 (MST) (envelope-from owner-ietf-trust-anchor@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-trust-anchor@mail.vpnc.org using -f Received: from ca-server2.wavx.wavesys.com (ca-server2.wavx.wavesys.com [65.197.200.86] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LJFcJP094030; Thu, 21 Jun 2007 12:15:39 -0700 (MST) (envelope-from thardjono@wavesys.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Trust anchors for multiple applications Date: Thu, 21 Jun 2007 12:15:53 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trust anchors for multiple applications Thread-Index: Ace0LQANIllyCjb+QSuPEbfoISof2wACbruA From: "Thomas Hardjono" To: "Paul Hoffman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5LJFdJP094044 Sender: owner-ietf-trust-anchor@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hmmm, in reading the draft -00, I