From Hannes.Tschofenig@gmx.net Mon Aug 3 03:06:36 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAED63A6A02 for ; Mon, 3 Aug 2009 03:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0q8abxgwk5Yn for ; Mon, 3 Aug 2009 03:06:36 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 833CD3A69F5 for ; Mon, 3 Aug 2009 03:06:34 -0700 (PDT) Received: (qmail invoked by alias); 03 Aug 2009 10:06:36 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp028) with SMTP; 03 Aug 2009 12:06:36 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18VIcVTe58VrR1fbihuaQ716IKBCWh7911a5qfrWR 1XgFA3BZsjEwXr From: "Hannes Tschofenig" To: "'KEYPROV'" Date: Mon, 3 Aug 2009 13:09:06 +0300 Message-ID: <047701ca1422$703cd940$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoUIm9Q2bY17E5BRNqmrCS0EZXWqQ== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Subject: [KEYPROV] Extending the PSKC Algorithm Profiles X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 10:06:36 -0000 Hi all, In a review of the PSKC document a question regarding the registration of new PSKC algorithm profiles came up. The example here is the OCRA algorithm. Note that there is a document (although a bit out-dated already) that defines a new of PSKC algorithm profiles, see http://tools.ietf.org/id/draft-hoyer-keyprov-pskc-algorithm-profiles-00.txt There are essentially two approaches for defining algorithm profiles. In the first version below new XML elements are defined that do not exist in PSKC to carry parameters of the OCRA algorithm, namely information about a hash function and information about the truncation size. Manufacturer 987654321 DC=example-bank,DC=net CM_ID_001 Issuer UID=jsmith,DC=example-bank,DC=net http://www.w3.org/2001/04/xmlenc#sha256 8 MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= 0 In the second example, the registered algorithm URN contains the parameter encoding. This requires more URNs to be registered but does not require new XML elements to be defined. Regarding the URN registration I believe that the full set of URNs need to be registered and it would not be sufficient to just register urn:ietf:params:xml:ns:keyprov:pskc#ocra and to just attach the other parameters. Maybe someone knows more about this aspect. Manufacturer 987654321 DC=example-bank,DC=net CM_ID_001 Issuer UID=jsmith,DC=example-bank,DC=net MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= 0 Both options are possible; it might be a matter of taste which one to apply and the extension style should be chosen in the http://tools.ietf.org/id/draft-hoyer-keyprov-pskc-algorithm-profiles-00.txt document. Ciao Hannes PS: Note that some new algorithm profiles might not require any XML elements to be defined nor multiple URNs to be registered. It very much depends on the specific algorithm profile but I have chosen OCRA since the issue came up there. From phoyer@actividentity.com Mon Aug 3 03:09:27 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58D533A6D36 for ; Mon, 3 Aug 2009 03:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivog66+SJe9K for ; Mon, 3 Aug 2009 03:09:26 -0700 (PDT) Received: from frhub1.activcard.fr (frhub1.activcard.fr [91.151.120.133]) by core3.amsl.com (Postfix) with ESMTP id 442A53A69F5 for ; Mon, 3 Aug 2009 03:09:26 -0700 (PDT) Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id 1F858183953; Mon, 3 Aug 2009 12:09:25 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 3 Aug 2009 12:09:37 +0200 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB792B@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <047701ca1422$703cd940$0301a8c0@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Extending the PSKC Algorithm Profiles Thread-Index: AcoUIm9Q2bY17E5BRNqmrCS0EZXWqQAAAylw References: <047701ca1422$703cd940$0301a8c0@nsnintra.net> From: "Philip Hoyer" To: "Hannes Tschofenig" , "KEYPROV" Subject: Re: [KEYPROV] Extending the PSKC Algorithm Profiles X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 10:09:27 -0000 Hannes, I believe we discussed this on some call while back and that we preferred Option 2 where the OCRA suite would be appended to the URN. Philip -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, August 03, 2009 11:09 AM To: 'KEYPROV' Subject: [KEYPROV] Extending the PSKC Algorithm Profiles Hi all,=20 In a review of the PSKC document a question regarding the registration of new PSKC algorithm profiles came up. The example here is the OCRA algorithm. Note that there is a document (although a bit out-dated already) that defines a new of PSKC algorithm profiles, see http://tools.ietf.org/id/draft-hoyer-keyprov-pskc-algorithm-profiles-00. txt There are essentially two approaches for defining algorithm profiles. In the first version below new XML elements are defined that do not exist in PSKC to carry parameters of the OCRA algorithm, namely information about a hash function and information about the truncation size.=20 Manufacturer 987654321 DC=3Dexample-bank,DC=3Dnet CM_ID_001 Issuer UID=3Djsmith,DC=3Dexample-bank,DC=3Dnet =20 http://www.w3.org/2001/04/xmlenc#sha256 8 MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=3D 0 In the second example, the registered algorithm URN contains the parameter encoding. This requires more URNs to be registered but does not require new XML elements to be defined.=20 Regarding the URN registration I believe that the full set of URNs need to be registered and it would not be sufficient to just register urn:ietf:params:xml:ns:keyprov:pskc#ocra and to just attach the other parameters. Maybe someone knows more about this aspect.=20 Manufacturer 987654321 DC=3Dexample-bank,DC=3Dnet CM_ID_001 Issuer UID=3Djsmith,DC=3Dexample-bank,DC=3Dnet MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=3D 0 Both options are possible; it might be a matter of taste which one to apply and the extension style should be chosen in the http://tools.ietf.org/id/draft-hoyer-keyprov-pskc-algorithm-profiles-00. txt document.=20 Ciao Hannes PS: Note that some new algorithm profiles might not require any XML elements to be defined nor multiple URNs to be registered. It very much depends on the specific algorithm profile but I have chosen OCRA since the issue came up there.=20 _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov From turners@ieca.com Thu Aug 6 09:26:58 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C793A6DE4 for ; Thu, 6 Aug 2009 09:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so5tfYV2eVsx for ; Thu, 6 Aug 2009 09:26:57 -0700 (PDT) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by core3.amsl.com (Postfix) with SMTP id A2E463A6A82 for ; Thu, 6 Aug 2009 09:26:57 -0700 (PDT) Received: (qmail 75071 invoked from network); 6 Aug 2009 16:26:58 -0000 Received: from unknown (HELO thunderfish.local) (turners@96.241.8.236 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 6 Aug 2009 16:26:58 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: Pcz8GqQVM1mIRstK.LvMpKxxltlZhKeoZEYdVx51P_0yOxsKPr.tAGrZ7nXFv_pv4blnQkNbyi3B6N4KxMggXCpd0ib7zQ_SIlwQmpXLoPNBGsIvO_EG.aBKyc033Qa5e61A8c8uzId1pzjpQTGADG1xkY3DKGN79iqUYKKkCEkihoKzypqBipQ3gvkpaY3yuh16016FwySGQGUB5SsXJV7yI.uX8n4_wNEBVlivVTWOVgoprpI5NNePtCFLPbgpSXTH5psvXb8ZZFdQR3SCWaW5kgAfTb0D42xHXEzwm1TnCdEm00BnAre078vP_Q9FGegT X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7B0452.8030108@ieca.com> Date: Thu, 06 Aug 2009 12:26:58 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: keyprov@ietf.org References: <4A715934.5000909@ieca.com> In-Reply-To: <4A715934.5000909@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [KEYPROV] XML to ASN.1 for attributes X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 16:26:58 -0000 Sean Turner wrote: > As PSKC is basically done, I'm going to convert the XML > elements/attributes to ASN.1. I've got one question: should the > elements with child elements be one attribute or separate attributes? > For example, DeviceInfo is as follows: > > > Manufacturer > 987654321 > DC=example-bank,DC=net > > We could either have one attribute: > > DeviceInfo ::= SEQUENCE { > manufactuer Manufactuer, > serialNo SerialNo, > userId UserId } > > or three separate attributes: > > Manufactuer, SerialNo, and UserId. > > Which way do people want it? I'm leaning towards separate attributes.... spt From hannes.tschofenig@nsn.com Thu Aug 6 10:58:08 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC7B3A6CEE for ; Thu, 6 Aug 2009 10:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYB583fhu9dt for ; Thu, 6 Aug 2009 10:58:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 36D5C3A6BBB for ; Thu, 6 Aug 2009 10:58:06 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n76Hw6bR029643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2009 19:58:06 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n76Hw6qv014380; Thu, 6 Aug 2009 19:58:06 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 19:58:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 21:00:35 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45019411FE@FIESEXC015.nsn-intra.net> In-Reply-To: <4A7B0452.8030108@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] XML to ASN.1 for attributes Thread-Index: AcoWsrx+fx6+dIktRTajoDlLf0eNZgADOBqQ References: <4A715934.5000909@ieca.com> <4A7B0452.8030108@ieca.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Sean Turner" , X-OriginalArrivalTime: 06 Aug 2009 17:58:05.0647 (UTC) FILETIME=[72F16DF0:01CA16BF] Subject: Re: [KEYPROV] XML to ASN.1 for attributes X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 17:58:08 -0000 In XML it is more useful to have child elements rather than attributes. The main reason is extensibility. When you want to define complex structures then those cannot be added as attributes.=20 I wonder whether a similar restriction replies to ASN.1 Ciao Hannes >-----Original Message----- >From: keyprov-bounces@ietf.org=20 >[mailto:keyprov-bounces@ietf.org] On Behalf Of ext Sean Turner >Sent: 06 August, 2009 19:27 >To: keyprov@ietf.org >Subject: Re: [KEYPROV] XML to ASN.1 for attributes > >Sean Turner wrote: >> As PSKC is basically done, I'm going to convert the XML=20 >> elements/attributes to ASN.1. I've got one question: should the=20 >> elements with child elements be one attribute or separate attributes? >> For example, DeviceInfo is as follows: >>=20 >> >> Manufacturer >> 987654321 >> DC=3Dexample-bank,DC=3Dnet >>=20 >> We could either have one attribute: >>=20 >> DeviceInfo ::=3D SEQUENCE { >> manufactuer Manufactuer, >> serialNo SerialNo, >> userId UserId } >>=20 >> or three separate attributes: >>=20 >> Manufactuer, SerialNo, and UserId. >>=20 >> Which way do people want it? > > >I'm leaning towards separate attributes.... > >spt >_______________________________________________ >KEYPROV mailing list >KEYPROV@ietf.org >https://www.ietf.org/mailman/listinfo/keyprov > From turners@ieca.com Thu Aug 6 11:34:42 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A5B28C166 for ; Thu, 6 Aug 2009 11:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt5MtOlCMK2o for ; Thu, 6 Aug 2009 11:34:42 -0700 (PDT) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by core3.amsl.com (Postfix) with SMTP id 60AE528C177 for ; Thu, 6 Aug 2009 11:34:24 -0700 (PDT) Received: (qmail 74238 invoked from network); 6 Aug 2009 18:34:25 -0000 Received: from unknown (HELO thunderfish.local) (turners@96.241.8.236 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 6 Aug 2009 18:34:25 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: 5KKAQB4VM1nJyrRsD_5gMLiW0hNe6YS628rXIgGTF6rU_iPlnT.7iI1hXD0PXA29M8QcRSBgOUyqB3IgjZ.l471VG.LAgsvtKorRSxtHNbdLaxhlM8A1cmEqJXIfVQz2pi98K4IFTHxR4F5xVrBjPG4trGz7_SEQFVlH4nCg6ZPgAz56sInTaSmXlc4MG9E0oDLiz5wmmbOG86TcI9Ujvuax4jkYmvqWMOlQABb58jFTqVAmXi.A3GVSwzaDahqnLM3S_1IneZ3tW72DuuS.NKJaHGvt0raXziT43vKT4ytyBRdKJO0WGlUoJf_b1v4LW7R_7zQ_oVY3JJk.V5RLZd6D6nBK2Wofubg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7B2230.5020006@ieca.com> Date: Thu, 06 Aug 2009 14:34:24 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <4A715934.5000909@ieca.com> <4A7B0452.8030108@ieca.com> <3D3C75174CB95F42AD6BCC56E5555B45019411FE@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45019411FE@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: keyprov@ietf.org Subject: Re: [KEYPROV] XML to ASN.1 for attributes X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 18:34:42 -0000 Hannes, The ASN.1 container has an extensible mechanism to add arbitrary data to a collection of keys or one key. It just happens to be called an attribute. So the term is being a bit overloaded. When we define the attributes we can either define the attributes to be the lowest child element or a collection of child elements. We can also use ASN.1's extensibility mechanism (the "...") to allow more things to be added to an attribute that collects more than one child element. spt Tschofenig, Hannes (NSN - FI/Espoo) wrote: > In XML it is more useful to have child elements rather than attributes. > The main reason is extensibility. When you want to define complex > structures then those cannot be added as attributes. > > I wonder whether a similar restriction replies to ASN.1 > > Ciao > Hannes > > >> -----Original Message----- >> From: keyprov-bounces@ietf.org >> [mailto:keyprov-bounces@ietf.org] On Behalf Of ext Sean Turner >> Sent: 06 August, 2009 19:27 >> To: keyprov@ietf.org >> Subject: Re: [KEYPROV] XML to ASN.1 for attributes >> >> Sean Turner wrote: >>> As PSKC is basically done, I'm going to convert the XML >>> elements/attributes to ASN.1. I've got one question: should the >>> elements with child elements be one attribute or separate attributes? >>> For example, DeviceInfo is as follows: >>> >>> >>> Manufacturer >>> 987654321 >>> DC=example-bank,DC=net >>> >>> We could either have one attribute: >>> >>> DeviceInfo ::= SEQUENCE { >>> manufactuer Manufactuer, >>> serialNo SerialNo, >>> userId UserId } >>> >>> or three separate attributes: >>> >>> Manufactuer, SerialNo, and UserId. >>> >>> Which way do people want it? >> >> I'm leaning towards separate attributes.... >> >> spt >> _______________________________________________ >> KEYPROV mailing list >> KEYPROV@ietf.org >> https://www.ietf.org/mailman/listinfo/keyprov >> > From Hannes.Tschofenig@gmx.net Thu Aug 6 11:36:37 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7424B28C16C for ; Thu, 6 Aug 2009 11:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeGsQuVY+slB for ; Thu, 6 Aug 2009 11:36:36 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2DF2F28C166 for ; Thu, 6 Aug 2009 11:36:35 -0700 (PDT) Received: (qmail invoked by alias); 06 Aug 2009 18:36:37 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp012) with SMTP; 06 Aug 2009 20:36:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/xI/9/2J3xL8q7N8KgXXlyrU6tenzJLa+RkLOFdx XiCRzD5VRlqJnw From: "Hannes Tschofenig" To: "'Sean Turner'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: <4A715934.5000909@ieca.com> <4A7B0452.8030108@ieca.com><3D3C75174CB95F42AD6BCC56E5555B45019411FE@FIESEXC015.nsn-intra.net> <4A7B2230.5020006@ieca.com> Date: Thu, 6 Aug 2009 21:39:06 +0300 Message-ID: <049c01ca16c5$2ebff1a0$625aa20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoWxJmbyJstgYAJT1SmTK+JkrQ6LQAAH9qQ In-Reply-To: <4A7B2230.5020006@ieca.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 Cc: keyprov@ietf.org Subject: Re: [KEYPROV] XML to ASN.1 for attributes X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 18:36:37 -0000 This sounds like is only a matter of taste whether you go for option (1) or (2) listed in your original mail. >-----Original Message----- >From: keyprov-bounces@ietf.org >[mailto:keyprov-bounces@ietf.org] On Behalf Of Sean Turner >Sent: 06 August, 2009 21:34 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: keyprov@ietf.org >Subject: Re: [KEYPROV] XML to ASN.1 for attributes > >Hannes, > >The ASN.1 container has an extensible mechanism to add >arbitrary data to a collection of keys or one key. It just >happens to be called an attribute. So the term is being a bit >overloaded. When we define the attributes we can either >define the attributes to be the lowest child element or a >collection of child elements. We can also use ASN.1's >extensibility mechanism (the "...") to allow more things to be >added to an attribute that collects more than one child element. > >spt > >Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> In XML it is more useful to have child elements rather than >attributes. >> The main reason is extensibility. When you want to define complex >> structures then those cannot be added as attributes. >> >> I wonder whether a similar restriction replies to ASN.1 >> >> Ciao >> Hannes >> >> >>> -----Original Message----- >>> From: keyprov-bounces@ietf.org >>> [mailto:keyprov-bounces@ietf.org] On Behalf Of ext Sean Turner >>> Sent: 06 August, 2009 19:27 >>> To: keyprov@ietf.org >>> Subject: Re: [KEYPROV] XML to ASN.1 for attributes >>> >>> Sean Turner wrote: >>>> As PSKC is basically done, I'm going to convert the XML >>>> elements/attributes to ASN.1. I've got one question: should the >>>> elements with child elements be one attribute or separate >attributes? >>>> For example, DeviceInfo is as follows: >>>> >>>> >>>> Manufacturer >>>> 987654321 >>>> DC=example-bank,DC=net >>>> >>>> We could either have one attribute: >>>> >>>> DeviceInfo ::= SEQUENCE { >>>> manufactuer Manufactuer, >>>> serialNo SerialNo, >>>> userId UserId } >>>> >>>> or three separate attributes: >>>> >>>> Manufactuer, SerialNo, and UserId. >>>> >>>> Which way do people want it? >>> >>> I'm leaning towards separate attributes.... >>> >>> spt >>> _______________________________________________ >>> KEYPROV mailing list >>> KEYPROV@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyprov >>> >> >_______________________________________________ >KEYPROV mailing list >KEYPROV@ietf.org >https://www.ietf.org/mailman/listinfo/keyprov > From turners@ieca.com Thu Aug 6 12:00:41 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A878728C19D for ; Thu, 6 Aug 2009 12:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBYmoWCu3XZE for ; Thu, 6 Aug 2009 12:00:40 -0700 (PDT) Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by core3.amsl.com (Postfix) with SMTP id B23C728C246 for ; Thu, 6 Aug 2009 12:00:14 -0700 (PDT) Received: (qmail 83433 invoked from network); 6 Aug 2009 19:00:15 -0000 Received: from unknown (HELO thunderfish.local) (turners@96.241.8.236 with plain) by smtp110.biz.mail.re2.yahoo.com with SMTP; 6 Aug 2009 19:00:15 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: 2bNw7sIVM1lkIxGkfP4NWx2HiZfMs6Cw.o13Y.8fgGZ8YYwAnhd_hr1vRiQSgMdM26rS9iYlwxdzgwGooKY_Pwqr9On9Gn_bOnTICFN6CQU_NIB1J6wtiDgJa2axmuzZ1ZV8vPXccf9kHTbGSbEdKtp5lRtXGDUp6JgkJ4URymTRfnntVPS23t1zdH4rG7UoAJ2DpYSxa33L2.uEXWL2wj17kEoBUisxohVuJaAhRo3J3eFU1RDupMY93TSlyOZlR8tLaMDwWlzLvNKxHawJ.l7XArQHsH0LG.VwxsJlrVkj4WbyLjlrcgF46Bqm1F4vFh2J4UUOr.bWzKYE5oqMdTf8NsYK1TyUHIw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7B283E.3090108@ieca.com> Date: Thu, 06 Aug 2009 15:00:14 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hannes Tschofenig References: <4A715934.5000909@ieca.com> <4A7B0452.8030108@ieca.com><3D3C75174CB95F42AD6BCC56E5555B45019411FE@FIESEXC015.nsn-intra.net> <4A7B2230.5020006@ieca.com> <049c01ca16c5$2ebff1a0$625aa20a@nsnintra.net> In-Reply-To: <049c01ca16c5$2ebff1a0$625aa20a@nsnintra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: keyprov@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [KEYPROV] XML to ASN.1 for attributes X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 19:00:41 -0000 Hannes, Pretty much. The one difference that comes to mind is that if we pick the separate attributes option you won't have something called with the same name as the parent element (e.g., nothing will be called DeviceInfo). spt Hannes Tschofenig wrote: > This sounds like is only a matter of taste whether you go for option (1) or > (2) listed in your original mail. > > > >> -----Original Message----- >> From: keyprov-bounces@ietf.org >> [mailto:keyprov-bounces@ietf.org] On Behalf Of Sean Turner >> Sent: 06 August, 2009 21:34 >> To: Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: keyprov@ietf.org >> Subject: Re: [KEYPROV] XML to ASN.1 for attributes >> >> Hannes, >> >> The ASN.1 container has an extensible mechanism to add >> arbitrary data to a collection of keys or one key. It just >> happens to be called an attribute. So the term is being a bit >> overloaded. When we define the attributes we can either >> define the attributes to be the lowest child element or a >> collection of child elements. We can also use ASN.1's >> extensibility mechanism (the "...") to allow more things to be >> added to an attribute that collects more than one child element. >> >> spt >> >> Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> In XML it is more useful to have child elements rather than >> attributes. >>> The main reason is extensibility. When you want to define complex >>> structures then those cannot be added as attributes. >>> >>> I wonder whether a similar restriction replies to ASN.1 >>> >>> Ciao >>> Hannes >>> >>> >>>> -----Original Message----- >>>> From: keyprov-bounces@ietf.org >>>> [mailto:keyprov-bounces@ietf.org] On Behalf Of ext Sean Turner >>>> Sent: 06 August, 2009 19:27 >>>> To: keyprov@ietf.org >>>> Subject: Re: [KEYPROV] XML to ASN.1 for attributes >>>> >>>> Sean Turner wrote: >>>>> As PSKC is basically done, I'm going to convert the XML >>>>> elements/attributes to ASN.1. I've got one question: should the >>>>> elements with child elements be one attribute or separate >> attributes? >>>>> For example, DeviceInfo is as follows: >>>>> >>>>> >>>>> Manufacturer >>>>> 987654321 >>>>> DC=example-bank,DC=net >>>>> >>>>> We could either have one attribute: >>>>> >>>>> DeviceInfo ::= SEQUENCE { >>>>> manufactuer Manufactuer, >>>>> serialNo SerialNo, >>>>> userId UserId } >>>>> >>>>> or three separate attributes: >>>>> >>>>> Manufactuer, SerialNo, and UserId. >>>>> >>>>> Which way do people want it? >>>> I'm leaning towards separate attributes.... >>>> >>>> spt >>>> _______________________________________________ >>>> KEYPROV mailing list >>>> KEYPROV@ietf.org >>>> https://www.ietf.org/mailman/listinfo/keyprov >>>> >> _______________________________________________ >> KEYPROV mailing list >> KEYPROV@ietf.org >> https://www.ietf.org/mailman/listinfo/keyprov >> > > From anders.rundgren@telia.com Sat Aug 8 00:49:57 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06FF73A67A5 for ; Sat, 8 Aug 2009 00:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bt2F-sGT4RD for ; Sat, 8 Aug 2009 00:49:56 -0700 (PDT) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by core3.amsl.com (Postfix) with ESMTP id 014283A6A98 for ; Sat, 8 Aug 2009 00:49:55 -0700 (PDT) Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.140.3) (authenticated as u18116613) id 4A5BC8BE001D23B7; Sat, 8 Aug 2009 09:49:58 +0200 Message-ID: From: "Anders Rundgren" To: "KEYPROV" , Date: Sat, 8 Aug 2009 09:50:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.20661 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Cc: adrianba@microsoft.com Subject: [KEYPROV] Microsoft: is old and very basic X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 07:49:57 -0000 http://lists.w3.org/Archives/Public/public-html/2009Aug/0389.html However, that doesn't make Microsoft's solution ideal either because it also fails to address provisioning in a way that is even remotely comparable to what current card management software offers. IETF's DSKPP/PSKC which currently is in WGLC can unlike the HTML5 and MSFT solutions set PIN-codes on tokens which I consider a minimum requirement. Unfortunately DSKPP/PSKC has no ties to PKI or browsers. This total confusion seems like an ideal reason for me to continue working on the universal browser-based key-provisioning system. Although it is a very slow process (it's not my day-job), it is probably still much faster than the alternatives which seems to be stuck in a form they got a decade ago. Anders http://keycenter.webpki.org From anders.rundgren@telia.com Mon Aug 10 23:08:07 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052753A68D4 for ; Mon, 10 Aug 2009 23:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_40=-0.185, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34GkBBTlxiRY for ; Mon, 10 Aug 2009 23:08:05 -0700 (PDT) Received: from mail.primekey.se (walter.primekey.se [195.149.137.135]) by core3.amsl.com (Postfix) with ESMTP id 02F623A6844 for ; Mon, 10 Aug 2009 23:08:04 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 2E756C3C6F; Tue, 11 Aug 2009 08:08:05 +0200 (CEST) Message-ID: <4A810AC4.4030206@telia.com> Date: Tue, 11 Aug 2009 08:08:04 +0200 From: Anders Rundgren User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Adrian Bateman References: <749F45FA745A3244A87A63316D4E26B187C2200FBD@NA-EXMSG-C108.redmond.corp.microsoft.com> In-Reply-To: <749F45FA745A3244A87A63316D4E26B187C2200FBD@NA-EXMSG-C108.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------010903000003010000030903" Cc: "dev-tech-crypto@lists.mozilla.org" , KEYPROV Subject: Re: [KEYPROV] Microsoft: is old and very basic X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 06:08:07 -0000 This is a multi-part message in MIME format. --------------010903000003010000030903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, Thank you for the prompt response. I believe that only represent the tip of an iceberg because the fact is that in the EU banks and governments are spending huge sums on developing proprietary and national replacements of the local PKI-client in browsers because the latter are not only all over the map; they do not support things like on-line signatures. The following is a recent example of maybe 20 different efforts of this kind: http://egovlabs.gv.at/projects/mocca I.e. even if would be standardized (and adopted by Microsoft and other leading browser vendors...), it would not make any difference for the major users of PKI since /they still would need to deploy their own stuff/. There is though one area which /desperately/ needs a standard "" and that are mobile phones. Why is that? It is because unlike for PCs where most serious users of PKI use with smart cards that are physically distributed, mobile phones lack such a possibility, because SIMs are tied to operators and are thus generally useless as key-containers. The real problem here is that this issue spans multiple "departments" and "platform owners" which so far has lead to a decade-long stand-still. My guess is that this effectively makes it unreachable from a traditional standardization perspective. I believe Microsoft's introduction of InformationCards was a very good way of introducing new technology which was a bit similar to WHATWG did with HTML5 (i.e. code + specs in a rather non-formal way). FWIW, I'm personally involved in creating a de-facto standard for on-line provisioning. Unlike HTML5 I have spent considerable time investigating and listing "requirements" for such a facility with on-line banking and e-government services for consumers/citizens as the primary (but not only) targets. It has recently morphed into an eight-pass (!) XML protocol which is an indication that a single HTML tag probably doesn't fill the bill. That doesn't allow a bank to set PIN-code or PIN-code policy is just a starter since this innocent-looking requirement actually has major implications, even including core platform cryptography: To my knowledge this is outside of CertEnroll/Xenroll as well since the underlaying standard Windows CSPs do not support PIN settings or PIN-policies, at least not in a consumer setup. The latter should be interpreted as /multiple and independent issuers all having their own ideas about policies/. Sincerely, Anders Rundgren Senior Security Consultant Adrian Bateman wrote: > On Saturday, August 08, 2009 12:50 AM, Anders Rundgren wrote: > >> http://lists.w3.org/Archives/Public/public-html/2009Aug/0389.html >> >> However, that doesn't make Microsoft's solution ideal either because it >> also fails to address provisioning in a way that is even remotely >> comparable to what current card management software offers. >> > > Hi Anders, > > Thanks for the mail and the forward to the lists in the CC line. > > I certainly wasn't trying to make a claim that Microsoft's solution is ideal - this isn't my area of expertise so I wouldn't be able to judge that. I have forwarded your mail on to a team better equipped to give feedback. My question was, based on the feedback I'd heard, whether or not it made sense to standardize the old behaviour in HTML 5 when a more modern solution might be more appropriate. > > I will follow-up here when I get more feedback from the team that looks after this area. > > Regards, > > Adrian. > > > --------------010903000003010000030903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Adrian,

Thank you for the prompt response.

I believe that <keygen> only represent the tip of an iceberg because the fact is that in the EU banks and governments are spending huge sums on developing proprietary and national replacements of the local PKI-client in browsers because the latter are not only all over the map; they do not support things like on-line signatures.

The following is a recent example of maybe 20 different efforts of this kind:

http://egovlabs.gv.at/projects/mocca

I.e. even if <keygen> would be standardized (and adopted by Microsoft and other leading browser vendors...), it would not make any difference for the major users of PKI since they still would need to deploy their own stuff.

There is though one area which desperately needs a standard "<keygen>" and that are mobile phones.  Why is that?  It is because unlike for PCs where most serious users of PKI use with smart cards that are physically distributed, mobile phones lack such a possibility, because SIMs are tied to operators and are thus generally useless as key-containers.

The real problem here is that this issue spans multiple "departments" and "platform owners" which so far has lead to a decade-long stand-still.  My guess is that this effectively makes it unreachable from a traditional standardization perspective.   I believe Microsoft's introduction of InformationCards was a very good way of introducing new technology which was a bit similar to WHATWG did with HTML5 (i.e. code + specs in a rather non-formal way).

FWIW, I'm personally involved in creating a de-facto standard for on-line provisioning.  Unlike HTML5 I have spent considerable time investigating and listing "requirements" for such a facility with on-line banking and e-government services for consumers/citizens as the primary (but not only) targets.  It has recently morphed into an eight-pass (!) XML protocol which is an indication that a single HTML tag probably doesn't fill the bill.

That <keygen> doesn't allow a bank to set PIN-code or PIN-code policy is just a starter since this innocent-looking requirement actually has major implications, even including core platform cryptography:  To my knowledge this is outside of CertEnroll/Xenroll as well since the underlaying standard Windows CSPs do not support PIN settings or PIN-policies, at least not in a consumer setup.  The latter should be interpreted as multiple and independent issuers all having their own ideas about policies.

Sincerely,
Anders Rundgren
Senior Security Consultant


Adrian Bateman wrote: 
On Saturday, August 08, 2009 12:50 AM, Anders Rundgren wrote:
  
http://lists.w3.org/Archives/Public/public-html/2009Aug/0389.html

However, that doesn't make Microsoft's solution ideal either because it
also fails to address provisioning in a way that is even remotely
comparable to what current card management software offers.
    

Hi Anders,

Thanks for the mail and the forward to the lists in the CC line.

I certainly wasn't trying to make a claim that Microsoft's solution is ideal - this isn't my area of expertise so I wouldn't be able to judge that. I have forwarded your mail on to a team better equipped to give feedback. My question was, based on the feedback I'd heard, whether or not it made sense to standardize the old <keygen> behaviour in HTML 5 when a more modern solution might be more appropriate.

I will follow-up here when I get more feedback from the team that looks after this area.

Regards,

Adrian.

--------------010903000003010000030903-- From adrianba@microsoft.com Mon Aug 10 20:14:17 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F2F3A676A for ; Mon, 10 Aug 2009 20:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whCnEqC0m5hj for ; Mon, 10 Aug 2009 20:14:16 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 3B43C3A6B3B for ; Mon, 10 Aug 2009 20:14:16 -0700 (PDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 10 Aug 2009 20:14:20 -0700 Received: from NA-EXMSG-C108.redmond.corp.microsoft.com ([157.54.62.159]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.18.53]) with mapi; Mon, 10 Aug 2009 20:14:19 -0700 From: Adrian Bateman To: Anders Rundgren Date: Mon, 10 Aug 2009 20:11:15 -0700 Thread-Topic: Microsoft: is old and very basic Thread-Index: AcoX/OvIMl/5B9TJQEOfLQPfnFqbLACMwpZw Message-ID: <749F45FA745A3244A87A63316D4E26B187C2200FBD@NA-EXMSG-C108.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 11 Aug 2009 02:34:07 -0700 Cc: "dev-tech-crypto@lists.mozilla.org" , KEYPROV Subject: Re: [KEYPROV] Microsoft: is old and very basic X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 03:35:16 -0000 On Saturday, August 08, 2009 12:50 AM, Anders Rundgren wrote: > http://lists.w3.org/Archives/Public/public-html/2009Aug/0389.html >=20 > However, that doesn't make Microsoft's solution ideal either because it > also fails to address provisioning in a way that is even remotely > comparable to what current card management software offers. Hi Anders, Thanks for the mail and the forward to the lists in the CC line. I certainly wasn't trying to make a claim that Microsoft's solution is idea= l - this isn't my area of expertise so I wouldn't be able to judge that. I = have forwarded your mail on to a team better equipped to give feedback. My = question was, based on the feedback I'd heard, whether or not it made sense= to standardize the old behaviour in HTML 5 when a more modern sol= ution might be more appropriate. I will follow-up here when I get more feedback from the team that looks aft= er this area. Regards, Adrian. From hannes.tschofenig@nsn.com Thu Aug 13 06:28:23 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337413A6AD7 for ; Thu, 13 Aug 2009 06:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.093 X-Spam-Level: X-Spam-Status: No, score=-3.093 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKhrASCqcsib for ; Thu, 13 Aug 2009 06:28:22 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 86DE63A6B0D for ; Thu, 13 Aug 2009 06:28:21 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7DDQhtS022418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Aug 2009 15:26:43 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7DDQhHs026254 for ; Thu, 13 Aug 2009 15:26:43 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 15:26:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1C19.B2247D96" Date: Thu, 13 Aug 2009 16:29:15 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45019756AB@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting Minutes (IETF#75) Thread-Index: AcocGg2XPcKXHjd2QMmRG15HkuX0Ug== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "KEYPROV" X-OriginalArrivalTime: 13 Aug 2009 13:26:43.0031 (UTC) FILETIME=[B2A3A670:01CA1C19] Subject: [KEYPROV] Meeting Minutes (IETF#75) X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 13:28:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1C19.B2247D96 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Provisioning of Symmetric Keys WG=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D XMPP WG Agenda - IETF 75, Stockholm Tuesday, 28 July 2009, Session 1: 0900-1130 Room: Large Auditorium Meeting Agenda Available at: = http://www.ietf.org/proceedings/75/agenda/xmpp.txt Jabber Logs Available at: = http://jabber.ietf.org/logs/keyprov/2009-07-30.txt Jim Schaad took notes. Sean Turner chaired the meeting. Sean presented WG status slides available at = http://www.ietf.org/proceedings/75/slides/keyprov-0.ppt. There are = three active Internet Drafts (IDs). All three IDs will be discussed = during the meeting. Of note, the second working group last call (WGLC) = ended for the Portable Symmetric Key Container (PSKC) ended on 6/27. Sean also presented slides (available at = http://www.ietf.org/proceedings/75/slides/keyprov-1.ppt) on the PSKC ID, = which were produced by Philip Hoyer. The current version (-03) = addressed comments received during the 1st WG LC. Changes include: - Tweaks to schema that address comments from IETF 74 white board = session - Require generated MAC key encrypted with transport key - Corrected examples with proper generated values - Aligned introduction with DSKPP spec - Added new W3c DerivedKey element to PBE Comments were received on the -03 version; however all are considered = minor. Comments include: - Adding clearer descriptions for DeviceBinding and UserId - There needs to be alignment with PBE - Instead of mandatory use must The corresponding algorithm document will be updated. The next step is to produced a -04 version. This version will then be = provided to the security area director. Comments received during the meeting: - From Hannes: there are no manditory algorithms. - From Ming: a reference implementation is avaiable. - From Hannes: another may be in the works=20 Sean also presented slides on the ASN.1 Symmetric Key Package Content = Type, which can be found at = http://www.ietf.org/proceedings/75/slides/keyprov-2.ppt. A -05 version = was published shortly before IETF 75, but it was just a keep-alive = version that included no technical changes. Version -06 will include = ASN.1 version of the XML elements and attributes. The one issue raised = was whether there should be one attribute or multiple attributes. No comments were received. Magnus Nystr=F6m presented slides on the Dynamic Symmetric Key = Provisioning Protocol (DSKPP), which can be found at = http://www.ietf.org/proceedings/75/slides/keyprov-4/keyprov-4.htm. He = first presented a primer on the DSKPP protocol itself and then he = addressed the status of the ID. Version -08 includes comments received = on version -07, which included: - Alignment with PSKC - Changed MACAlgorithm - Updated conformance requirements - Changed AuthenticatedDataType->ClientId to optional Comments received include: - What is the timeframe for the next version? The next version should = be out soon and then WGLC should be issued. - Alexandros(?) asked what is the best use for these types of = protocols? - Magnus replied that they are used to establish a shared secret for = later use typically between a mobile device assocated with a person and a server. - Alexandos(?) asked what is best use in a big company: firewalls key = or just clients joining some serer network? - Magnus replied the number of servers to be provisioned - can you use = this as well? Yes you coul but need to remember that user = authentication in protocol - need to figure out who is really there. = Serer w/ certificate then generate/transport new key material - but = could use cert in that case. Better for user devices than automaons.=20 ------_=_NextPart_001_01CA1C19.B2247D96 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Meeting Minutes (IETF#75)

Provisioning of Symmetric Keys WG =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

XMPP WG Agenda - IETF 75, = Stockholm
Tuesday, 28 July 2009, Session 1: = 0900-1130
Room: Large Auditorium

Meeting Agenda Available at: http://www.ietf.org/proceedings/75/agenda/xmpp.txt<= /U>
Jabber Logs Available at: http://jabber.ietf.org/logs/keyprov/2009-07-30.txt<= /U>

Jim Schaad took notes.

Sean Turner chaired the meeting.

Sean presented WG status slides = available at http://www.ietf.org/proceedings/75/slides/keyprov-0.ppt.  There are three active = Internet Drafts (IDs).  All three IDs will be discussed during the = meeting.  Of note, the second working group last call (WGLC) ended = for the Portable Symmetric Key Container (PSKC) ended on = 6/27.

Sean also presented slides (available = at http://www.ietf.org/proceedings/75/slides/keyprov-1.ppt) on the PSKC ID, which were = produced by Philip Hoyer.  The current version (-03) addressed = comments received during the 1st WG LC.  Changes = include:

 - Tweaks to schema that address = comments from IETF 74 white board session
 - Require generated MAC key = encrypted with transport key
 - Corrected examples with proper = generated values
 - Aligned introduction with = DSKPP spec
 - Added new W3c DerivedKey = element to PBE
Comments were received on the -03 = version; however all are considered minor.  Comments = include:
 - Adding clearer descriptions = for DeviceBinding and UserId
 - There needs to be alignment = with PBE
 - Instead of mandatory use = must
The corresponding algorithm document = will be updated.
The next step is to produced a -04 = version.  This version will then be provided to the security area = director.
Comments received during the = meeting:
- From Hannes: there are no manditory = algorithms.
- From Ming: a reference = implementation is avaiable.
- From Hannes: another may be in the = works

Sean also presented slides on the ASN.1 = Symmetric Key Package Content Type, which can be found at http://www.ietf.org/proceedings/75/slides/keyprov-2.ppt.  A -05 version was = published shortly before IETF 75, but it was just a keep-alive version = that included no technical changes.  Version -06 will include ASN.1 = version of the XML elements and attributes.  The one issue raised = was whether there should be one attribute or multiple = attributes.

No comments were received.

Magnus Nystr=F6m presented slides on = the Dynamic Symmetric Key Provisioning Protocol (DSKPP), which can be = found at http://www.ietf.org/proceedings/75/slides/keyprov-4/keypro= v-4.htm.  He first = presented a primer on the DSKPP protocol itself and then he addressed = the status of the ID.  Version -08 includes comments received on = version -07, which included:

 - Alignment with PSKC
 - Changed MACAlgorithm
 - Updated conformance = requirements
 - Changed = AuthenticatedDataType->ClientId to optional
Comments received include:
 - What is the timeframe for the = next version?  The next version should be out soon and then WGLC = should be issued.
 - Alexandros(?) asked what is = the best use for these types of protocols?
 - Magnus replied that they are = used to establish a shared secret for later use typically between a = mobile device
assocated with a person and a = server.
 - Alexandos(?) asked what is = best use in a big company: firewalls key or just clients joining some = serer network?
 - Magnus replied the number of = servers to be provisioned - can you use this as well?  Yes you coul = but need to remember that user authentication in protocol - need to = figure out who is really there.  Serer w/ certificate then = generate/transport new key material - but could use cert in that case. = Better for user devices than automaons.





------_=_NextPart_001_01CA1C19.B2247D96-- From phoyer@actividentity.com Fri Aug 28 06:58:41 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D6528C1DC for ; Fri, 28 Aug 2009 06:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjzTqxcwcxPd for ; Fri, 28 Aug 2009 06:58:40 -0700 (PDT) Received: from frhub1.activcard.fr (frhub1.activcard.fr [91.151.120.133]) by core3.amsl.com (Postfix) with ESMTP id B17E03A68D1 for ; Fri, 28 Aug 2009 06:58:39 -0700 (PDT) Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id 4CA87183975; Fri, 28 Aug 2009 15:58:45 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Aug 2009 15:59:10 +0200 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB7A5F@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <9ED76AB595E4944BB33D8998DE448D1102BACBB9@CORPUSMX10B.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-03.txt Thread-Index: AcnpNGd9HfiNkjHdSaOREoz4XLRgtwEQ25UFDplLa/A= References: <028801c9e934$681fb750$035aa20a@nsnintra.net> <9ED76AB595E4944BB33D8998DE448D1102BACBB9@CORPUSMX10B.corp.emc.com> From: "Philip Hoyer" To: , , Subject: Re: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-03.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 13:58:41 -0000 Andrea, Thanks so much for the review. Please see my comments and what I have changed for final submission: Philip -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of andrea.doherty@rsa.com Sent: Monday, June 15, 2009 6:23 AM To: Hannes.Tschofenig@gmx.net; keyprov@ietf.org Subject: Re: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-03.txt Philip, etal: =20 Great work on the document! =20 Please find my comments below. =20 Items representing things that I think are "issues" are prepended with three asterisks ('***'). Note, however, that I think these are minor in nature. =20 Andrea =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Key: S - Section P - Paragraph F - Figure Abstract: Insert a comma after "For example" [PH] changed =20 Introduction, P1: ", for example^^,^^ vendors" [PH] changed=20 S3, #6: "wether" is misspelled [PH] could not find this, must have been corrected earlier=20 S4, P2: when describing the example, would help to mention the use of PIN algorithm since PIN's might not automatically be thought of as symmetric keys. [PH] Changed the example to use HOTP algorithm =20 *** S4, 'Id': The reference to multiple containers threw me. According to our terminology discussion, and the discussion on Bulk Provisioning in Section 8, PSKC only defines one Key Container. Under what circumstances would "multiple key containers" be embedded in larger xml documents? [PH] this was deemed good practice for XML so maybe if it is not DSKPP but other larger xml documents the potentially could contain multiple PSKC containers and hence having an Id would be very helpful to refer to them =20 *** S4.1, 'Algorithm': [PSKC-ALGORITHM-PROFILES] is going to expire on June 27, 2009. [PH] I need to update the spec and update, I know.... not enough time, too much to do..... =20 S4.1, last paragraph re : This paragraph is difficult to understand. Rather than "MUST be possible to carry" you are not inferring that is mandatory, but the wording implies this. is optional. Because is defined in the schema, it must be possible to carry the value --- this doesn't need explicit mention here. Would be clearer to just have as another item in the list (after 'Encrypted:") and discuss it from there. [PH]: changed =20 *** S4.2, sample schema, : The value is missing UID. Under what situations would the Device have a different UserID than the Key that the device holds? Does Device really refer to Issuer? [PH] can't follow UID. It seems to be ok in my version. The UID for a key could be a group of people (sort of a role certificate).=20 =20 *** S4.2.1, : Rob Philpott suggested the following re-wording (I mentioned this re-wording in my comments on the previous version of the doc): "This element allows a provisioning server to ensure that the key is going to be loaded into the device for which the key provisioning request was approved. The device is bound to the request using a device identifier, e.g., an IMEI for the phone, or an identifier for a class of identifiers, e.g., those for which the keys are protected by a TPM." [PH] changed =20 S4.2.3, P3: "indicates XXthatXX the entity" [PH] changed =20 *** S4.2.3, P3: By "entity" what is being referenced? Issuer? The distinction between UserID associated with key and UserID associated with Device is unclear. [PH] I changed this to 'it indicates the user the device is associated with.' =20 S4.3, P1: "sending and receiving partiesXX,XX might" [PH] changed =20 S4.3, P2: check wording for editorial problems [PH] slightly changed wording =20 S4.3, P2: Would provide better context if you stated that this example is based on MasterCard CAP, e.g., "For example, ^^in the case of MasterCard CAP,^^ [PH] changed =20 S4.3, last paragraph: The text after F4 mentioned an external key called "MasterKeyLabel", but this doesn't match the example, which instead uses called "keyProfile1". [PH] good spot, changed the example and description =20 S5, : "key carried within the PSKC document can be used" - clarify what "used" means. I think it means the number of times the key may be used by an application (after the key was imported by the receiving party). But, "used" could also mean the number of times the key can be imported. [PH] changed =20 S5, : "(000 is the vice versa of Integrity)" [PH] changed =20 S5, : This description refers to "validation server". Would be more consistent with the rest of the document to refer to this as the "receiving party". [PH] changed but not used receiving party since in this case it is the party that validates the algorithm response =20 S5, : Same comment as above. [PH] changed =20 S5, : "lenght" --- misspelled [PH] changed =20 *** S6.2: Alignment issue with DSKPP. =20 Note that according to DSKPP (-07, section 5.2.2), for Passphrase-Based Key Wrap,=20 "the option MUST be used and the key name MUST identify the=20 passphrase that will be used by the server to generate the key wrapping key. =20 The identifier and passphrase components of MUST be set to the=20 Client ID and authentication code components of AD (same AD as contained in this=20 message)." =20 However, in S6.2 of this version of PSKC, is not mentioned. [PH] not sure what I should add here could Ming help? =20 S6.3, last sentence: confusing sentence [PH] changed =20 S6.4: The wording is difficult to understand, as there are lots of misspellings, etc. [PH] completely changed =20 S10.1, Profiling: "meta-data" --- everywhere else in the doc "meta data" is used. [PH] changed =20 S11: Is the annotation regarding line break within SchemaLocation necessary? The DSKPP schema has lots of line breaks, but no annotations included. [PH] removed S12.5 and S12.6, "depreciate": The word "deprecate" is typically used instead of "depreciate". [PH] changed =20 S13.2: "provides a mean^^s^^" [PH] already changed =20 S15: "Veath"->"Vaeth" [PH] D'oh, changed =20 S16.2: The [DSKPP] is out-of-date. The latest version was released in Feb 2009 and was version -07. =20 A.1.3: "floppy" - I don't think floppy disks are used any more. [PH] sadly yes =20 A.1.4: "Over-The-Aire" -> "Over-The-Air" (Aire is a river in N England) [PH] changed ________________________________ From: keyprov-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Tue 6/9/2009 2:59 PM To: KEYPROV Subject: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-03.txt Hi all, This is the 2nd Working Group Last Call for comments on "Portable Symmetric Key Container (PSKC)": http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-03.txt Please have comments to the list by Sunday, 27 June. As always, please remember to send a note in if you've read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem". Ciao Hannes & Phillip _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov From phoyer@actividentity.com Fri Aug 28 07:29:08 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53CE83A6F72 for ; Fri, 28 Aug 2009 07:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjEtEitgLd-e for ; Fri, 28 Aug 2009 07:29:07 -0700 (PDT) Received: from frhub1.activcard.fr (frhub1.activcard.fr [91.151.120.133]) by core3.amsl.com (Postfix) with ESMTP id 007A83A70DD for ; Fri, 28 Aug 2009 07:28:58 -0700 (PDT) Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id 9EE1F183975; Fri, 28 Aug 2009 16:29:05 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Aug 2009 16:29:31 +0200 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB7A60@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <4A3ED0B0.6040301@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-03.txt Thread-Index: Acny0VOT/T/p2K4rTHeVCnHF/DaaIw1FsygQ References: <028801c9e934$681fb750$035aa20a@nsnintra.net> <4A3ED0B0.6040301@ieca.com> From: "Philip Hoyer" To: "Sean Turner" , "KEYPROV" Subject: Re: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-03.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 14:29:08 -0000 Sean, Thanks for the reviewed please find below comments on what I have changed for final submission. -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Sean Turner Sent: Monday, June 22, 2009 1:31 AM To: KEYPROV Subject: Re: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-03.txt Here are my comments. I'd say these were all nits and that the document is ready to proceed. I hope to not duplicate Andrea's comments. Abstract: r/The standard/A standard {PH] changed Intro: r/of a IANA/of an IANA [PH] changed Sec 1.3: r/semantics../semantics. [PH] changed Sec 3: r/upmost/at most? [PH] changed Sec 4.1, 'Algorithm': r/[PSKC-ALGORITHM-PROFILES]/[PSKC-ALGORITHM-PROFILES]. [PH] changed Sec 4: r/This attribute is mandatory./This attribute MUST be included. [PH] changed Sec 4/4.1: (I waffled on whether or not to include this as a comment)=20 Should the values used in Figure 2 be referenced in 4/4.1? e.g., 'Id:'=20 The 'Id' attribute carries a unique identifier for the container. For this example, the value is "exampleID1". It ties the examples to the=20 text, and might help some readers. [PH] sorry left it as is Sec 4.1,