From keyprov-bounces@ietf.org Wed Aug 01 04:52:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG9vz-00069R-VE; Wed, 01 Aug 2007 04:51:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG9vx-00067s-RA for keyprov@ietf.org; Wed, 01 Aug 2007 04:51:57 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IG9vx-0007Ir-AK for keyprov@ietf.org; Wed, 01 Aug 2007 04:51:57 -0400 Received: (qmail invoked by alias); 01 Aug 2007 08:51:55 -0000 Received: from ip-90-186-91-117.web.vodafone.de (EHLO [90.186.91.117]) [90.186.91.117] by mail.gmx.net (mp033) with SMTP; 01 Aug 2007 10:51:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19AxDpMxtFAkPdDdbjOvbhDjYESBFKG85EOX6ms21 6hVxVlpGmjVVbe Message-ID: <46B049A8.5070803@gmx.net> Date: Wed, 01 Aug 2007 10:51:52 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: keyprov@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: "Glen Zorn \(gwz\)" Subject: [KEYPROV] DSKPP Reviewers X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org I would like to thank * Glen Zorn * Lakshminath Dondeti * Sean Turner for their willingness to review the DSKPP draft within the next 2 weeks. Ciao Hannes _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Aug 02 17:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGiTn-0006FQ-CN; Thu, 02 Aug 2007 17:45:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGiTm-0006FF-AW for keyprov@ietf.org; Thu, 02 Aug 2007 17:45:10 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IGiTk-00038b-NH for keyprov@ietf.org; Thu, 02 Aug 2007 17:45:10 -0400 Received: (qmail 13853 invoked by uid 0); 2 Aug 2007 21:45:07 -0000 Received: from 90.186.116.146 by www095.gmx.net with HTTP; Thu, 02 Aug 2007 23:45:07 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Aug 2007 23:45:07 +0200 From: "Hannes Tschofenig" In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E71880EF@sonusmail04.sonusnet.com> Message-ID: <20070802214507.245620@gmx.net> MIME-Version: 1.0 References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A09@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A0A@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E71880EF@sonusmail04.sonusnet.com> To: dime@ietf.org, keyprov@ietf.org, ecrit@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX192AsBf3rF2Vr5WT3/c0rTUYGa5P1YTBozyrxJSZF qHrTO39i46zdmejPySNWUlzSPSRcAnlNUccg== Content-Transfer-Encoding: 7bit X-GMX-UID: UWaHd4c3bUk7LMVQ8Gkn5npsZ2hlN4rX X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [KEYPROV] Vacation X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Folks, I am on vacation and (almost) out of email reach until August 13th. If you need something really urgent then put "URGENT" into the subject header of your mail to Hannes.Tschofenig@gmx.net. Ciao Hannes _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Aug 03 09:48:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGxVq-00055H-6Z; Fri, 03 Aug 2007 09:48:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGxVo-00051v-Nm for keyprov@ietf.org; Fri, 03 Aug 2007 09:48:16 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGxVn-00038Z-5T for keyprov@ietf.org; Fri, 03 Aug 2007 09:48:16 -0400 Received: (qmail invoked by alias); 03 Aug 2007 13:41:33 -0000 Received: from ip-90-186-15-92.web.vodafone.de (EHLO [90.186.15.92]) [90.186.15.92] by mail.gmx.net (mp045) with SMTP; 03 Aug 2007 15:41:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX182JEdSkAc2cNi9Otrme2oLpwDlIOXiGIb9Erxs8W 6faQGzpP1ds6k8 Message-ID: <46B33090.40907@gmx.net> Date: Fri, 03 Aug 2007 15:41:36 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: keyprov@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Subject: [KEYPROV] DSKPP Review X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org I went through the -01 version of the DSKPP draft and I have some high-level document structure comments. Sorry that I haven't sent them earlier. There are typically three classes of readers for these types of documents: a) Folks that want to get an idea what the stuff is about. They don't want to implement it and they don't care about the details b) Implementers; they typically look at the examples first and need also to understand the schema and all the encoding details. They do often not really worry about the underlying security properties -- they assume everything is fine. c) Crypto-guys; they don't care about implementation details but focus on the abstract message interaction, the security consideration section and the key derivation procedures For (a) the document already does a pretty good job. Readers might find interesting content in Section 1, 3 and the first parts of Section 4. For (b) we could do better. There is a lot of text in there that is pretty hard to follow although it is (theoretically) pretty simple. The document will (in my view) be much simpler to read if we restructure Section 4 (DSKPP), Section 4.9 (Schema Basics), and Section 4.10 (DSKPP Messages) according to the different variants of DSKPP and explain each one-by-one instead of distributing the content over multiple sections. I also believe that we should not provide snippets of the XML schema anywhere (e.g., Section 4.9) since it does not add a lot of value for the reader. If someone cares about the schema then they will look at it. What is more interesting are examples since they explain the concepts pretty nicely. An example structure of a recently written protocol can be found with LoST: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-05.txt For the LoST document we got a number of reviews, pretty good comments and readers found it easy to follow. Btw, do we expect that all clients and all servers will implement all variants of DSKPP (One-Pass, Two-Pass and Four-Pass protocol exchange)? For (c) I also believe that we need to provide the reader more information. I am missing the abstract description of the protocol. Section 4.2 provides some information in textual form but we might want to utilize the terminology we introduced in Section 2 to either represent the protocol in a form that is similar to Section 3 of http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-06.txt or to use a Alice-and-Bob notation as it is often used as a basis for a subsequent formal verficiation. In any case, the representation allows to focus on the elements that are important for the security analysis and ignores all XML details. The key derivation description should also be the same on the client and on the server. Figure 4 should essentially be replaced by something that is closer to Figure 2 of http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-06.txt. Since the three protocol variants are from a security point of view totally different protocols I suggest to treat them separately in the security consideration section as well. Acknowledgements: The section is really short given that a number of people provided review comments. As an example, LoST http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-05.txt is somewhat verbose on listing what individuals contributed. I do, however, think it is a good idea to be a bit more explicit. Some people spend a considerable amount of time on reviews and on providing input and we should have enough time to thank them in the document. The typical rule is: If someone participates in discussions and does reviews then he will be listed in the acknowledgment section. If a person provides text he will be listed in the contributors section. Section 9: Intelluctual Property Considerations. Do you think that this section is needed? Isn't almost every company name a trademark? So, a high-level ToC might look as follows: 1. Introduction 2. Terminology 3. Use Cases [Use short abbreviations for the subsection heading rather than an entire sentence. For example, instead of saying "A cryptographic module renews its symmetric key with the same key ID" use a subject heading like "Key Renewal" or "Rekeying"] 4. DSKPP Overview [The high-level description on the message flows and information about the information that is exchanged in the different variants goes in here. A later subsection also contains the key derivations and mac calculations. I would omit the key container format here and the server authentication section did not say a lot. The client authentication section is fine when put in context of the different variants. Essentially, this is a clean-up of the existing Section 4.1,4.2,4.3,4.4.,4.5,4.6,4.7,4.8. ] 5. Four-Pass Protocol [The entire description of the 4 pass protocol goes in here with a focus on the XML stuff. This section includes XML examples. You might want to highlight the messages rather than specific types, such as AbstractRequestType, since they are not that important. Start with a very simple example and explain what is in there and then extend it so that people understand the additional functionality. These sections also need to provide enough information to visualize the state machine without necessarily drawing state machines. Someone you need to describe the different errors and warnings. You can either attach them to the individual variants or put them into a separate section if they are applicable to all three protocol variants.] 6. Two-Pass Protocol [Same as above but for the 2 pass protocol.] 7. One-Pass Protocol [Same as above but for the 1 pass protocol.] [Section 5,6,&7 should be done in reverse order depending what is easier to explain. Additionally, it might be possible and useful to separate a few things that are common for all three variants and to put them on the top.] 8. Trigger Message 9. Extensiblity [Talk about how to extend the protocol. This is not necessarily Section 4.11 since I couldn't understand Section 4.11] 10. HTTP Protocol Binding 11. Schema 12. IANA Considerations 13. Security Considerations 13.1 One-Pass Protocol 13.2 Two-Pass Protocol 13.3 Four-Pass Protocol 14. Acknowledgements 15. References More comments on the details later when someone thinks that this document restructuring is a good idea. Ciao Hannes _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Aug 03 10:24:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGy4a-000745-Lt; Fri, 03 Aug 2007 10:24:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGy4Y-00073w-Rm for keyprov@ietf.org; Fri, 03 Aug 2007 10:24:10 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGy4X-0004AA-SD for keyprov@ietf.org; Fri, 03 Aug 2007 10:24:10 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l73EO6uG012372; Fri, 3 Aug 2007 10:24:06 -0400 (EDT) Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l73ENuq1007710; Fri, 3 Aug 2007 10:23:59 -0400 (EDT) Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id l73ELRuS027033; Fri, 3 Aug 2007 10:21:27 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [KEYPROV] DSKPP Review Date: Fri, 3 Aug 2007 10:19:04 -0400 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970BABBCAD@rsana-ex-hq1.NA.RSA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] DSKPP Review thread-index: AcfV1PqRGR7OyInMSYanvDihOCOFfgABERhb References: <46B33090.40907@gmx.net> From: "Doherty, Andrea" To: "Hannes Tschofenig" , X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Hannes, I think this is great feedback and agree with the document restructuring = proposal. Andrea ________________________________ From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Fri 8/3/2007 9:41 AM To: keyprov@ietf.org Subject: [KEYPROV] DSKPP Review I went through the -01 version of the DSKPP draft and I have some high-level document structure comments. Sorry that I haven't sent them earlier. There are typically three classes of readers for these types of = documents: a) Folks that want to get an idea what the stuff is about. They don't want to implement it and they don't care about the details b) Implementers; they typically look at the examples first and need also to understand the schema and all the encoding details. They do often not really worry about the underlying security properties -- they assume everything is fine. c) Crypto-guys; they don't care about implementation details but focus on the abstract message interaction, the security consideration section and the key derivation procedures For (a) the document already does a pretty good job. Readers might find interesting content in Section 1, 3 and the first parts of Section 4. For (b) we could do better. There is a lot of text in there that is pretty hard to follow although it is (theoretically) pretty simple. The document will (in my view) be much simpler to read if we restructure Section 4 (DSKPP), Section 4.9 (Schema Basics), and Section 4.10 (DSKPP Messages) according to the different variants of DSKPP and explain each one-by-one instead of distributing the content over multiple sections. I also believe that we should not provide snippets of the XML schema anywhere (e.g., Section 4.9) since it does not add a lot of value for the reader. If someone cares about the schema then they will look at it. What is more interesting are examples since they explain the concepts pretty nicely. An example structure of a recently written protocol can be found with = LoST: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-05.txt For the LoST document we got a number of reviews, pretty good comments and readers found it easy to follow. Btw, do we expect that all clients and all servers will implement all variants of DSKPP (One-Pass, Two-Pass and Four-Pass protocol exchange)? For (c) I also believe that we need to provide the reader more information. I am missing the abstract description of the protocol. Section 4.2 provides some information in textual form but we might want to utilize the terminology we introduced in Section 2 to either represent the protocol in a form that is similar to Section 3 of http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-06.txt or to use a Alice-and-Bob notation as it is often used as a basis for a subsequent formal verficiation. In any case, the representation allows to focus on the elements that are important for the security analysis and ignores all XML details. The key derivation description should also be the same on the client and on the server. Figure 4 should essentially be replaced by something that is closer to Figure 2 of http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-06.txt. Since the three protocol variants are from a security point of view totally different protocols I suggest to treat them separately in the security consideration section as well. Acknowledgements: The section is really short given that a number of people provided review comments. As an example, LoST http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-05.txt is somewhat verbose on listing what individuals contributed. I do, however, think it is a good idea to be a bit more explicit. Some people spend a considerable amount of time on reviews and on providing input and we should have enough time to thank them in the document. The typical rule is: If someone participates in discussions and does reviews then he will be listed in the acknowledgment section. If a person provides text he will be listed in the contributors section. Section 9: Intelluctual Property Considerations. Do you think that this section is needed? Isn't almost every company name a trademark? So, a high-level ToC might look as follows: 1. Introduction 2. Terminology 3. Use Cases [Use short abbreviations for the subsection heading rather than an entire sentence. For example, instead of saying "A cryptographic module renews its symmetric key with the same key ID" use a subject heading like "Key Renewal" or "Rekeying"] 4. DSKPP Overview [The high-level description on the message flows and information about the information that is exchanged in the different variants goes in = here. A later subsection also contains the key derivations and mac = calculations. I would omit the key container format here and the server authentication section did not say a lot. The client authentication section is fine when put in context of the different variants. Essentially, this is a clean-up of the existing Section 4.1,4.2,4.3,4.4.,4.5,4.6,4.7,4.8. ] 5. Four-Pass Protocol [The entire description of the 4 pass protocol goes in here with a focus on the XML stuff. This section includes XML examples. You might want to highlight the messages rather than specific types, such as AbstractRequestType, since they are not that important. Start with a very simple example and explain what is in there and then extend it so that people understand the additional functionality. These sections also need to provide enough information to visualize the state machine without necessarily drawing state machines. Someone you need to describe the different errors and warnings. You can either attach them to the individual variants or put them into a separate section if they are applicable to all three protocol variants.] 6. Two-Pass Protocol [Same as above but for the 2 pass protocol.] 7. One-Pass Protocol [Same as above but for the 1 pass protocol.] [Section 5,6,&7 should be done in reverse order depending what is easier to explain. Additionally, it might be possible and useful to separate a few things that are common for all three variants and to put them on the top.] 8. Trigger Message 9. Extensiblity [Talk about how to extend the protocol. This is not necessarily Section 4.11 since I couldn't understand Section 4.11] 10. HTTP Protocol Binding 11. Schema 12. IANA Considerations 13. Security Considerations 13.1 One-Pass Protocol 13.2 Two-Pass Protocol 13.3 Four-Pass Protocol 14. Acknowledgements 15. References More comments on the details later when someone thinks that this document restructuring is a good idea. Ciao Hannes _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Aug 03 12:37:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH09Q-0004cE-8K; Fri, 03 Aug 2007 12:37:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH09P-0004c8-Fk for keyprov@ietf.org; Fri, 03 Aug 2007 12:37:19 -0400 Received: from robin.verisign.com ([65.205.251.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH09O-0008Dw-DK for keyprov@ietf.org; Fri, 03 Aug 2007 12:37:19 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id l73GavgP002252; Fri, 3 Aug 2007 09:36:57 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 09:36:57 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [KEYPROV] DSKPP Review Date: Fri, 3 Aug 2007 09:36:56 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C939FAFA@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <017630AA6DF2DF4EBC1DD4454F8EE2970BABBCAD@rsana-ex-hq1.NA.RSA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] DSKPP Review Thread-Index: AcfV1PqRGR7OyInMSYanvDihOCOFfgABERhbAATPNHA= From: "Pei, Mingliang" To: "Doherty, Andrea" , "Hannes Tschofenig" , X-OriginalArrivalTime: 03 Aug 2007 16:36:57.0578 (UTC) FILETIME=[82248CA0:01C7D5EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org I like the suggestions too. Thanks, - Ming=20 -----Original Message----- From: Doherty, Andrea [mailto:adoherty@rsa.com]=20 Sent: Friday, August 03, 2007 7:19 AM To: Hannes Tschofenig; keyprov@ietf.org Subject: RE: [KEYPROV] DSKPP Review Hannes, I think this is great feedback and agree with the document restructuring proposal. Andrea ________________________________ From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Fri 8/3/2007 9:41 AM To: keyprov@ietf.org Subject: [KEYPROV] DSKPP Review I went through the -01 version of the DSKPP draft and I have some high-level document structure comments. Sorry that I haven't sent them earlier. There are typically three classes of readers for these types of documents: a) Folks that want to get an idea what the stuff is about. They don't want to implement it and they don't care about the details b) Implementers; they typically look at the examples first and need also to understand the schema and all the encoding details. They do often not really worry about the underlying security properties -- they assume everything is fine. c) Crypto-guys; they don't care about implementation details but focus on the abstract message interaction, the security consideration section and the key derivation procedures For (a) the document already does a pretty good job. Readers might find interesting content in Section 1, 3 and the first parts of Section 4. For (b) we could do better. There is a lot of text in there that is pretty hard to follow although it is (theoretically) pretty simple. The document will (in my view) be much simpler to read if we restructure Section 4 (DSKPP), Section 4.9 (Schema Basics), and Section 4.10 (DSKPP Messages) according to the different variants of DSKPP and explain each one-by-one instead of distributing the content over multiple sections. I also believe that we should not provide snippets of the XML schema anywhere (e.g., Section 4.9) since it does not add a lot of value for the reader. If someone cares about the schema then they will look at it. What is more interesting are examples since they explain the concepts pretty nicely. An example structure of a recently written protocol can be found with LoST: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-05.txt For the LoST document we got a number of reviews, pretty good comments and readers found it easy to follow. Btw, do we expect that all clients and all servers will implement all variants of DSKPP (One-Pass, Two-Pass and Four-Pass protocol exchange)? For (c) I also believe that we need to provide the reader more information. I am missing the abstract description of the protocol. Section 4.2 provides some information in textual form but we might want to utilize the terminology we introduced in Section 2 to either represent the protocol in a form that is similar to Section 3 of http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-06.txt or to use a Alice-and-Bob notation as it is often used as a basis for a subsequent formal verficiation. In any case, the representation allows to focus on the elements that are important for the security analysis and ignores all XML details. The key derivation description should also be the same on the client and on the server. Figure 4 should essentially be replaced by something that is closer to Figure 2 of http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-06.txt. Since the three protocol variants are from a security point of view totally different protocols I suggest to treat them separately in the security consideration section as well. Acknowledgements: The section is really short given that a number of people provided review comments. As an example, LoST http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-05.txt is somewhat verbose on listing what individuals contributed. I do, however, think it is a good idea to be a bit more explicit. Some people spend a considerable amount of time on reviews and on providing input and we should have enough time to thank them in the document. The typical rule is: If someone participates in discussions and does reviews then he will be listed in the acknowledgment section. If a person provides text he will be listed in the contributors section. Section 9: Intelluctual Property Considerations. Do you think that this section is needed? Isn't almost every company name a trademark? So, a high-level ToC might look as follows: 1. Introduction 2. Terminology 3. Use Cases [Use short abbreviations for the subsection heading rather than an entire sentence. For example, instead of saying "A cryptographic module renews its symmetric key with the same key ID" use a subject heading like "Key Renewal" or "Rekeying"] 4. DSKPP Overview [The high-level description on the message flows and information about the information that is exchanged in the different variants goes in here. A later subsection also contains the key derivations and mac calculations. I would omit the key container format here and the server authentication section did not say a lot. The client authentication section is fine when put in context of the different variants. Essentially, this is a clean-up of the existing Section 4.1,4.2,4.3,4.4.,4.5,4.6,4.7,4.8. ] 5. Four-Pass Protocol [The entire description of the 4 pass protocol goes in here with a focus on the XML stuff. This section includes XML examples. You might want to highlight the messages rather than specific types, such as AbstractRequestType, since they are not that important. Start with a very simple example and explain what is in there and then extend it so that people understand the additional functionality. These sections also need to provide enough information to visualize the state machine without necessarily drawing state machines. Someone you need to describe the different errors and warnings. You can either attach them to the individual variants or put them into a separate section if they are applicable to all three protocol variants.] 6. Two-Pass Protocol [Same as above but for the 2 pass protocol.] 7. One-Pass Protocol [Same as above but for the 1 pass protocol.] [Section 5,6,&7 should be done in reverse order depending what is easier to explain. Additionally, it might be possible and useful to separate a few things that are common for all three variants and to put them on the top.] 8. Trigger Message 9. Extensiblity [Talk about how to extend the protocol. This is not necessarily Section 4.11 since I couldn't understand Section 4.11] 10. HTTP Protocol Binding 11. Schema 12. IANA Considerations 13. Security Considerations 13.1 One-Pass Protocol 13.2 Two-Pass Protocol 13.3 Four-Pass Protocol 14. Acknowledgements 15. References More comments on the details later when someone thinks that this document restructuring is a good idea. Ciao Hannes _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 11:33:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIR3U-0002au-PD; Tue, 07 Aug 2007 11:33:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQoO-0006uG-QU; Tue, 07 Aug 2007 11:17:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIQoO-0003hy-Bo; Tue, 07 Aug 2007 11:17:32 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 4AAF12AC66; Tue, 7 Aug 2007 15:17:02 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IIQnu-0007tF-1u; Tue, 07 Aug 2007 11:17:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 07 Aug 2007 11:17:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-Mailman-Approved-At: Tue, 07 Aug 2007 11:33:06 -0400 Cc: keyprov@ietf.org Subject: [KEYPROV] I-D ACTION:draft-ietf-keyprov-dskpp-00.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning of Symmetric Keys Working Group of the IETF. Title : Dynamic Symmetric Key Provisioning Protocol (DSKPP) Author(s) : A. Doherty Filename : draft-ietf-keyprov-dskpp-00.txt Pages : 100 Date : 2007-8-1 DSKPP is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private-key capabilities in the cryptographic modules, and with or without an established public-key infrastructure. Three variations of the protocol support multiple usage scenarios. The four-pass (i.e., two round-trip) variant enables key generation in near real-time. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. Two- and one-pass variants enable secure and efficient download and installation of symmetric keys to a cryptographic module in environments where near real-time communication may not be possible. This document builds on information contained in [RFC4758], adding specific enhancements in response to implementation experience and liaison requests. It is intended, therefore, that this document or a successor version thereto will become the basis for subsequent progression of a symmetric key provisioning protocol specification on the standards track. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-keyprov-dskpp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-keyprov-dskpp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-1142245.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-keyprov-dskpp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-keyprov-dskpp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-1142245.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --NextPart-- From keyprov-bounces@ietf.org Tue Aug 07 12:37:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIS49-0000F6-Ek; Tue, 07 Aug 2007 12:37:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIS48-0000Ex-PA for keyprov@ietf.org; Tue, 07 Aug 2007 12:37:52 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIS48-00072L-AC for keyprov@ietf.org; Tue, 07 Aug 2007 12:37:52 -0400 Received: (qmail 18372 invoked from network); 7 Aug 2007 18:37:49 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 18:37:49 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 16:18:42 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186503522.77.0.73674903332.issue1@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [KEYPROV] [issue1] Change element names to reflect keyprov and request / response style X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: At the Chicago meeting, the consensus was that the intent of the DSKPP is n= ot=20 strictly for implementation in Web Services, and that a strict SOAP-style=20 naming scheme is undesirable. However, for implementation and debugging=20 purposes, the group consensus was that the PDU names should be prefixed wit= h a=20 common name (e.g., =E2=80=9CKEYPROV=E2=80=9D or =E2=80=9CDSKPP=E2=80=9D) to= identify their context. ---------- status: chatting -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 12:45:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISBZ-0006QE-JX; Tue, 07 Aug 2007 12:45:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISBY-0006JR-OR for keyprov@ietf.org; Tue, 07 Aug 2007 12:45:32 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IISBX-0007uS-R6 for keyprov@ietf.org; Tue, 07 Aug 2007 12:45:32 -0400 Received: (qmail 32005 invoked from network); 7 Aug 2007 18:45:30 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 18:45:29 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 16:26:23 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186503983.04.0.912865097797.issue4@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.8 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [KEYPROV] [issue4] Should TokenID and KeyID be string instead of binary? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: Based on discussion in the KEYPROV WG meeting in Chicago, it is not within = the=20 KEYPROV charter to have a position on the explicit specification of a key=20 identifier and namespace. Rather, the goal is that anything the IEEE P1619= .3=20 group (or any other application) wants to specify should be supportable by=20 attributes defined in a KEYPROV key container. More specifically, with reg= ard=20 to the KEYPROV key id work: =E2=80=A2 DSKPP, in combination with whatever key container format it defin= es,=20 should make available all of the key metadata (e.g., KeyID, attributes and=20 namespace) required of an application and leave it up to the application to=20 format the data in accordance with its key identifier specification. As suc= h,=20 there was a general preference for the namespace not being encoded with the= ID. =E2=80=A2 The following proposal was generally agreeable (although not=20 required): A two-level URI + ID scheme, e.g., 0123456789 done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 12:46:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISCi-00075j-9F; Tue, 07 Aug 2007 12:46:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISCg-00075W-UF for keyprov@ietf.org; Tue, 07 Aug 2007 12:46:42 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IISCg-00086U-G8 for keyprov@ietf.org; Tue, 07 Aug 2007 12:46:42 -0400 Received: (qmail 32720 invoked from network); 7 Aug 2007 18:46:39 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 18:46:38 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 16:27:31 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186504051.62.0.103999377555.issue4@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [KEYPROV] [issue4] Should TokenID and KeyID be string instead of binary? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: There is a preference for string rather than binary. Unless there is an=20 objection, this is the direction that will be taken. ---------- status: done-cbb -> chatting _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 12:51:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISHH-0002Gv-QR; Tue, 07 Aug 2007 12:51:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISHG-0002Gh-4O for keyprov@ietf.org; Tue, 07 Aug 2007 12:51:26 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IISHE-0003ol-Cb for keyprov@ietf.org; Tue, 07 Aug 2007 12:51:26 -0400 Received: (qmail 7618 invoked from network); 7 Aug 2007 18:51:21 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 18:51:21 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 16:32:15 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186504335.06.0.602447275796.issue4@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [KEYPROV] [issue4] Should TokenID and KeyID be string instead of binary? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: Changing state back to "done-cbb" ---------- status: chatting -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 12:53:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISJi-0003XF-Fm; Tue, 07 Aug 2007 12:53:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISJh-0003X4-4m for keyprov@ietf.org; Tue, 07 Aug 2007 12:53:57 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IISJf-0003vg-Pj for keyprov@ietf.org; Tue, 07 Aug 2007 12:53:57 -0400 Received: (qmail 10102 invoked from network); 7 Aug 2007 18:53:54 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 18:53:54 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 16:34:47 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186504487.79.0.328857667325.issue6@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.8 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [KEYPROV] [issue6] Refer to EncryptionAlgorithm from ClientHello for the SupportedEncryptionAlgorithms? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: This issue was raised at the meeting in Chicago. Rather than create a sepa= rate=20 document that provides a mapping between the key container algorithm names = and=20 those in DSKPP, there was a preference for consistently aligning the names=20 across the documents. The work to do this will be handled via the mailing = list. ---------- nosy: +keyprov _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 12:59:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISP7-0006fR-93; Tue, 07 Aug 2007 12:59:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISP5-0006T3-EC for keyprov@ietf.org; Tue, 07 Aug 2007 12:59:31 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IISP4-00044z-2r for keyprov@ietf.org; Tue, 07 Aug 2007 12:59:31 -0400 Received: (qmail 17802 invoked from network); 7 Aug 2007 18:59:28 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 18:59:28 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 16:40:21 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186504821.56.0.476877775033.issue8@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [KEYPROV] [issue8] How to refer to HOTP and SecurID OTP algorithms? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: This issue was raised at the meeting in Chicago. There was general agreeme= nt=20 that the PSKC I-D should not rely on enum for algorithm identifiers, but sh= ould=20 instead rely on URNs. HOTP and SecurID URNs will be used and aligned across DSKPP and key contain= er=20 documents. ---------- nosy: +keyprov status: need-eg -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 13:04:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISUI-00021b-8i; Tue, 07 Aug 2007 13:04:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISUG-00021S-Jp for keyprov@ietf.org; Tue, 07 Aug 2007 13:04:52 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IISUF-0004EP-0N for keyprov@ietf.org; Tue, 07 Aug 2007 13:04:52 -0400 Received: (qmail 21956 invoked from network); 7 Aug 2007 19:04:48 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 19:04:48 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 16:45:41 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186505141.69.0.177503269266.issue5@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [KEYPROV] [issue5] Different approaches used to refer to algorithms in keyprov and PSKC X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: Per discussion at meeting in Chicago, there was general agreement=20 that the PSKC I-D should not rely on enum for algorithm identifiers, but sh= ould=20 instead rely on URNs. URI's will be used and aligned across DSKPP and key container=20 documents. ---------- status: chatting -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 13:06:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISVd-0003VC-P0; Tue, 07 Aug 2007 13:06:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISVd-0003Uw-3O for keyprov@ietf.org; Tue, 07 Aug 2007 13:06:17 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IISVb-0004Gt-6g for keyprov@ietf.org; Tue, 07 Aug 2007 13:06:17 -0400 Received: (qmail 22210 invoked from network); 7 Aug 2007 19:06:12 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 19:06:12 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 16:47:05 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186505225.98.0.894969482462.issue6@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.8 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [KEYPROV] [issue6] Refer to EncryptionAlgorithm from ClientHello for the SupportedEncryptionAlgorithms? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: Marking done-cbb since the alignment of algorithm types will be handled via=20 mailing list. ---------- status: chatting -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 13:09:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISYP-0004xx-PF; Tue, 07 Aug 2007 13:09:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISYN-0004xr-Uz for keyprov@ietf.org; Tue, 07 Aug 2007 13:09:07 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IISYN-0004LC-6r for keyprov@ietf.org; Tue, 07 Aug 2007 13:09:07 -0400 Received: (qmail 23766 invoked from network); 7 Aug 2007 19:09:03 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 19:09:03 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 16:49:57 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186505397.06.0.344868568818.issue7@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [KEYPROV] [issue7] Shall we support an option for other response channel such as SMS? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: At the meeting in Chicago, consensus was that those who are interested in t= he=20 SMS delivery use case should produce a separate document; the core DSKPP=20 document should not explicitly address a solution for this use case. ---------- nosy: +keyprov status: chatting -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 13:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISek-0000Eq-82; Tue, 07 Aug 2007 13:15:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISei-00009c-KZ for keyprov@ietf.org; Tue, 07 Aug 2007 13:15:40 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IISeh-00017d-UC for keyprov@ietf.org; Tue, 07 Aug 2007 13:15:40 -0400 Received: (qmail 27963 invoked from network); 7 Aug 2007 19:15:33 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 19:15:33 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 16:56:27 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186505787.13.0.621789641593.issue9@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.8 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [KEYPROV] [issue9] Document the relationship between SupportedKeyInitializationMethod and EncryptionMethod in a response message X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: Based on discussion at meeting in Chicago, alignment is needed between prot= ocol=20 document and key container format specifications. =20 Since DSKPP can support multiple key container formats, albeit PSKC is the=20 documented default, describing key initialization profiles seems relevant t= o=20 the DSKPP protocol spec, and PSKC (and other key container format=20 specifications) would align to the profiles. Discussion is needed. ---------- nosy: +keyprov _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 13:20:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISjD-0003x4-1z; Tue, 07 Aug 2007 13:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISjC-0003wz-E5 for keyprov@ietf.org; Tue, 07 Aug 2007 13:20:18 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IISjB-0004br-QK for keyprov@ietf.org; Tue, 07 Aug 2007 13:20:18 -0400 Received: (qmail 29782 invoked from network); 7 Aug 2007 19:20:15 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 19:20:15 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 17:01:09 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186506069.29.0.392185246318.issue11@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [KEYPROV] [issue11] Is special keyprov HTTP header definition required? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: Note that a special header definition is not required. Rather the=20 specification identifies a MIME content type for all DSKPP messages (application/vnd.ietf.keyprov.dskpp+xml) and restrictions on HTTP headers. ---------- nosy: +keyprov status: need-eg -> chatting _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 13:21:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISkS-0004bm-F3; Tue, 07 Aug 2007 13:21:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISkQ-0004bK-NE for keyprov@ietf.org; Tue, 07 Aug 2007 13:21:34 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IISkQ-0004dB-3T for keyprov@ietf.org; Tue, 07 Aug 2007 13:21:34 -0400 Received: (qmail 30063 invoked from network); 7 Aug 2007 19:21:31 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 19:21:31 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 17:02:25 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186506145.03.0.649323783191.issue11@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.8 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [KEYPROV] [issue11] Is special keyprov HTTP header definition required? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: During the meeting in Chicago, the KEYPROV WG co-chairs said they would spe= ak=20 with the IETF Applications Area Director about usage of HTTP binding in the=20 document. _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 13:23:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISm3-0005UZ-Cj; Tue, 07 Aug 2007 13:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISm2-0005UU-Ag for keyprov@ietf.org; Tue, 07 Aug 2007 13:23:14 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IISm1-0004er-Nc for keyprov@ietf.org; Tue, 07 Aug 2007 13:23:14 -0400 Received: (qmail 30309 invoked from network); 7 Aug 2007 19:23:11 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 19:23:11 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 17:04:04 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186506244.82.0.665219472212.issue12@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [KEYPROV] [issue12] Should we use strongly typed message or any type for flexibility? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: After some discussion in Chicago, the group converged on a preference for=20 the =E2=80=9Cany=E2=80=9D type as it is used in the DSKPP draft today. Str= ong typing is not=20 recommended. Phillip Hallam-Baker cited experience in OASIS wherein =E2=80= =9Cany=E2=80=9D was=20 not allowed, but then the equivalent later relied upon. He also reminded t= he=20 group that =E2=80=9Cany=E2=80=9D is used in XMLenc and XMLdsig, which are b= oth relied upon by=20 DSKPP. ---------- nosy: +keyprov status: in-progress -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 13:25:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISo3-0006aN-HC; Tue, 07 Aug 2007 13:25:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISo1-0006aI-Jg for keyprov@ietf.org; Tue, 07 Aug 2007 13:25:17 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IISo1-0004gf-5Y for keyprov@ietf.org; Tue, 07 Aug 2007 13:25:17 -0400 Received: (qmail 30649 invoked from network); 7 Aug 2007 19:25:15 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 19:25:15 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 17:06:06 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186506366.76.0.709002796587.issue13@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [KEYPROV] [issue13] Shall we explicitly document how to construct AuthenticationCode over HTTP case? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: Securely sending an authentication code over HTTP was discussed in Section = 4=2E3 (Client Authentication) of draft-ietf-keyprov-dskpp-00.txt. ---------- nosy: +keyprov status: need-eg -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 13:29:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISs7-0001Dv-O2; Tue, 07 Aug 2007 13:29:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISs6-00018P-Ej for keyprov@ietf.org; Tue, 07 Aug 2007 13:29:30 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IISs5-0001Pu-HZ for keyprov@ietf.org; Tue, 07 Aug 2007 13:29:29 -0400 Received: (qmail 32449 invoked from network); 7 Aug 2007 19:29:28 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 19:29:27 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 17:10:21 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186506621.34.0.854931903897.issue23@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [KEYPROV] [issue23] Shall we use word "Key" in XML type names to replace word "Secret"? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: This change was made in draft-hoyer-keyprov-protable-symmetric-key-containe= r- 02.txt and in draft-ietf-keyprov-dskpp-00.txt. Marking "done-cbb". ---------- status: testing -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 13:33:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISwH-00041m-OG; Tue, 07 Aug 2007 13:33:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISwG-0003zy-4w for keyprov@ietf.org; Tue, 07 Aug 2007 13:33:48 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IISwF-0001WZ-Me for keyprov@ietf.org; Tue, 07 Aug 2007 13:33:48 -0400 Received: (qmail 3952 invoked from network); 7 Aug 2007 19:33:46 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 19:33:46 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 17:14:39 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186506879.42.0.736666613175.issue10@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [KEYPROV] [issue10] Do we need to provide SOAP binding and where if so? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: Based on discussions in Chicago and Prague, a SOAP binding is desirable.=20 Whether a separate document will be resubmitted for the SOAP binding or whe= ther=20 the DSKPP should expressed using WSDL 2.0 (which allows for SOAP and HTTP=20 bindings) is TBD after the co-chairs consult with the Applications Area=20 Director. ---------- nosy: +keyprov _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 13:37:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISzt-0006rI-1W; Tue, 07 Aug 2007 13:37:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISzr-0006r6-2x for keyprov@ietf.org; Tue, 07 Aug 2007 13:37:31 -0400 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IISzq-0001gS-Ch for keyprov@ietf.org; Tue, 07 Aug 2007 13:37:30 -0400 Received: (qmail 5820 invoked from network); 7 Aug 2007 19:37:28 +0200 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 7 Aug 2007 19:37:28 +0200 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 07 Aug 2007 17:18:22 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1186507102.23.0.877220013997.issue20@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.8 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [KEYPROV] [issue20] Define commonly used data type for keyprov in a common schema file for DSKPP and PSKC to share X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: During the meeting in Chicago, a separate document for the purpose of align= ing=20 types across DSKPP and PSKC was discouraged. Presumably this applies to a=20 separate schema as well. _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 07 14:24:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IITjH-0003Nd-8l; Tue, 07 Aug 2007 14:24:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IITjG-0003NU-ER for keyprov@ietf.org; Tue, 07 Aug 2007 14:24:26 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IITjF-0006Hf-56 for keyprov@ietf.org; Tue, 07 Aug 2007 14:24:26 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l77INrmv014957; Tue, 7 Aug 2007 11:23:53 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 11:24:21 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [KEYPROV] [issue8] How to refer to HOTP and SecurID OTP algorithms? Date: Tue, 7 Aug 2007 11:22:14 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD370134200C@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <1186504821.56.0.476877775033.issue8@http://www.tschofenig.priv.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [issue8] How to refer to HOTP and SecurID OTP algorithms? Thread-Index: AcfZFFYBAGxpAIsZRAibDmoS1QuyxgACpcBA From: "Hallam-Baker, Phillip" To: "KEYPROV Roundup Issue Tracker" , , "Pei, Mingliang" X-OriginalArrivalTime: 07 Aug 2007 18:24:21.0789 (UTC) FILETIME=[2CD81CD0:01C7D920] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1942382604==" Errors-To: keyprov-bounces@ietf.org --===============1942382604== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgY291bGQgZG8gd2l0aCBhIGxpc3Qgb2YgYWxnb3JpdGhtcyB0aGF0IHBlb3BsZSB3b3VsZCBs aWtlIGlkZW50aWZpZXJzIGZvciBhbmQgdGhlIGlkZW50aWZpZXJzIHRoZXkgcHJvcG9zZSBtYXkg YmUgdXNlZCBhcyBmb2xsb3dzOg0KDQpBbGdvcml0aG0gTmFtZQ0KQWxnb3JpdGhtIElkZW50aWZp ZXIgVVJJDQpBbnkgb3RoZXIgYWxnb3JpdGhtIGlkZW50aWZpZXJzIHRoYXQgbWlnaHQgYmUgcmVs ZXZhbnQgKE9JRCwgZXRjLikNClNvdXJjZSBzcGVjaWZpY2F0aW9uDQpTdGF0dXMgb2Ygc291cmNl IHNwZWNpZmljYXRpb24gKFN0YW5kYXJkLCBJbmZvcm1hdGlvbmFsLCBQcm9wcmlldGFyeSwgZXRj KQ0KDQpJIGFtIGN1cnJlbnRseSB3b3JraW5nIG9uIGEgY2F0YWxvZ3VlIG9mIFVSSSBiYXNlZCBp ZGVudGlmaWVycyBmb3IgY3J5cHRvLiBPbmNlIGNvbXBsZXRlIEkgd2lsbCBwcm9wb3NlIGFuIElB TkEgcmVnaXN0cnkgYW5kIGFkZCB0aGVzZSB0byB0aGUgSUQgc2V0dGluZyB0aGUgaW5pdGlhbCBz ZXQgb2YgY29kZSBwb2ludHMuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogQW5kcmVhIERvaGVydHkgW21haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0XSANCj4g U2VudDogVHVlc2RheSwgQXVndXN0IDA3LCAyMDA3IDEyOjQwIFBNDQo+IFRvOiBrZXlwcm92QGll dGYub3JnOyBQZWksIE1pbmdsaWFuZw0KPiBTdWJqZWN0OiBbS0VZUFJPVl0gW2lzc3VlOF0gSG93 IHRvIHJlZmVyIHRvIEhPVFAgYW5kIFNlY3VySUQgDQo+IE9UUCBhbGdvcml0aG1zPw0KPiANCj4g DQo+IEFuZHJlYSBEb2hlcnR5IDxhZG9oZXJ0eUByc2EuY29tPiBhZGRlZCB0aGUgY29tbWVudDoN Cj4gDQo+IFRoaXMgaXNzdWUgd2FzIHJhaXNlZCBhdCB0aGUgbWVldGluZyBpbiBDaGljYWdvLiAg VGhlcmUgd2FzIA0KPiBnZW5lcmFsIGFncmVlbWVudCB0aGF0IHRoZSBQU0tDIEktRCBzaG91bGQg bm90IHJlbHkgb24gZW51bSANCj4gZm9yIGFsZ29yaXRobSBpZGVudGlmaWVycywgYnV0IHNob3Vs ZCBpbnN0ZWFkIHJlbHkgb24gVVJOcy4NCj4gDQo+IEhPVFAgYW5kIFNlY3VySUQgVVJOcyB3aWxs IGJlIHVzZWQgYW5kIGFsaWduZWQgYWNyb3NzIERTS1BQIA0KPiBhbmQga2V5IGNvbnRhaW5lciBk b2N1bWVudHMuDQo+IA0KPiAtLS0tLS0tLS0tDQo+IG5vc3k6ICtrZXlwcm92DQo+IHN0YXR1czog bmVlZC1lZyAtPiBkb25lLWNiYg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEtFWVBST1YgUm91bmR1cCBJc3N1ZSBUcmFj a2VyIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiANCj4gPGh0dHA6Ly93d3cudHNjaG9mZW5p Zy5jb206ODA4MC9rZXlwcm92L2lzc3VlOD4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBLRVlQUk9WIG1haWxpbmcgbGlzdA0KPiBL RVlQUk9WQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2tleXByb3YNCj4gDQo= --===============1942382604== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============1942382604==-- From keyprov-bounces@ietf.org Tue Aug 07 15:01:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIUJU-0003dk-H5; Tue, 07 Aug 2007 15:01:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIUJT-0003YV-09 for keyprov@ietf.org; Tue, 07 Aug 2007 15:01:51 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIUJS-0004AT-9L for keyprov@ietf.org; Tue, 07 Aug 2007 15:01:50 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l77J1HuG021672; Tue, 7 Aug 2007 12:01:17 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 12:01:46 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [KEYPROV] [issue10] Do we need to provide SOAP binding and where ifso? Date: Tue, 7 Aug 2007 11:59:39 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD3701342014@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <1186506879.42.0.736666613175.issue10@http://www.tschofenig.priv.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [issue10] Do we need to provide SOAP binding and where ifso? Thread-Index: AcfZGR+8ssS+HM1gQpWzZ/YGvyePvgAC1msg From: "Hallam-Baker, Phillip" To: "KEYPROV Roundup Issue Tracker" , , "Pei, Mingliang" X-OriginalArrivalTime: 07 Aug 2007 19:01:46.0326 (UTC) FILETIME=[66B14760:01C7D925] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0768064180==" Errors-To: keyprov-bounces@ietf.org --===============0768064180== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIHJlYXNvbiBmb3IgZG9pbmcgdGhpcyBpcyB3aGF0IG9jY3VycmVkIGluIHRoZSBQS0lYIHdv cmtpbmcgZ3JvdXAgd2l0aCBTQ1ZQLg0KDQpTQ1ZQIHdhcyBvcmlnaW5hbGx5IGRlZmluZWQgYXMg YmVpbmcgbGF5ZXJlZCBvbiBIVFRQLiBCdXQgdGhlIHNwZWMgd2FzIGluY29tcGxldGUgd2l0aCBy ZXNwZWN0IHRvIHRoZSBiaW5kaW5nLiBUaGUgYXBwbGljYXRpb25zIGFyZWEgZGlyZWN0b3Igbm90 aWNlZCB0aGlzIGF0IGxhc3QgY2FsbC4gU2luY2UgdGhlIGdyb3VwIHdhcyBvdGhlcndpc2UgbWVh bnQgdG8gY2xvc2UgdGhleSBoYXZlIG5vdyBnb25lIHRvIGEgcHJvdG9jb2wgb3ZlciByYXcgVENQ IGp1c3QgZm9yIHRoZSBzYWtlIG9mIGdldHRpbmcgaXQgb3V0IHRoZSBkb29yLg0KDQpMYXllcmlu ZyB2aWEgV1NETCBtZWFucyB0aGF0IHdlIGhhdmUgdGhlIGJlbmVmaXQgb2YgdGhlIFczQyBiaW5k aW5nIHdvcmssIGFuZCBvbmUgaG9wZXMgdGhhdCB0aGV5IHVuZGVyc3RhbmQgSFRUUC4NCg0KQSBk ZXZlbG9wZXIgY2FuIGlnbm9yZSB0aGUgV1NETCBpZiB0aGV5IGNob29zZSwgdGhleSBhcmUgbm90 IG9ibGlnYXRlZCB0byBtYWtlIHVzZSBvZiBpdC4gQnV0IGlmIHRoZXkgYXJlIHVzaW5nIGEgV1NE TCBiYXNlZCB0b29sa2l0IHRvIGNvbnN0cnVjdCB0aGUgU09BUCBiaW5kaW5nIHRoZXkgY2FuIHRo cm93IG91dCB0aGUgSFRUUCBiaW5kaW5nIHdpdGhvdXQgYW55IG1vcmUgZWZmb3J0LiANCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmRyZWEgRG9oZXJ0eSBbbWFpbHRv Omhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXRdIA0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMDcs IDIwMDcgMToxNSBQTQ0KPiBUbzoga2V5cHJvdkBpZXRmLm9yZzsgUGVpLCBNaW5nbGlhbmcNCj4g U3ViamVjdDogW0tFWVBST1ZdIFtpc3N1ZTEwXSBEbyB3ZSBuZWVkIHRvIHByb3ZpZGUgU09BUCAN Cj4gYmluZGluZyBhbmQgd2hlcmUgaWZzbz8NCj4gDQo+IA0KPiBBbmRyZWEgRG9oZXJ0eSA8YWRv aGVydHlAcnNhLmNvbT4gYWRkZWQgdGhlIGNvbW1lbnQ6DQo+IA0KPiBCYXNlZCBvbiBkaXNjdXNz aW9ucyBpbiBDaGljYWdvIGFuZCBQcmFndWUsIGEgU09BUCBiaW5kaW5nIGlzIA0KPiBkZXNpcmFi bGUuIA0KPiBXaGV0aGVyIGEgc2VwYXJhdGUgZG9jdW1lbnQgd2lsbCBiZSByZXN1Ym1pdHRlZCBm b3IgdGhlIFNPQVAgDQo+IGJpbmRpbmcgb3Igd2hldGhlciB0aGUgRFNLUFAgc2hvdWxkIGV4cHJl c3NlZCB1c2luZyBXU0RMIDIuMCANCj4gKHdoaWNoIGFsbG93cyBmb3IgU09BUCBhbmQgSFRUUA0K PiBiaW5kaW5ncykgaXMgVEJEIGFmdGVyIHRoZSBjby1jaGFpcnMgY29uc3VsdCB3aXRoIHRoZSAN Cj4gQXBwbGljYXRpb25zIEFyZWEgRGlyZWN0b3IuDQo+IA0KPiAtLS0tLS0tLS0tDQo+IG5vc3k6 ICtrZXlwcm92DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gS0VZUFJPViBSb3VuZHVwIElzc3VlIFRyYWNrZXIgPGhhbm5l cy50c2Nob2ZlbmlnQGdteC5uZXQ+IA0KPiA8aHR0cDovL3d3dy50c2Nob2ZlbmlnLmNvbTo4MDgw L2tleXByb3YvaXNzdWUxMD4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBLRVlQUk9WIG1haWxpbmcgbGlzdA0KPiBLRVlQUk9WQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2tleXByb3YN Cj4gDQo= --===============0768064180== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============0768064180==-- From keyprov-bounces@ietf.org Tue Aug 14 04:07:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKrQf-0003mo-7n; Tue, 14 Aug 2007 04:07:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKrQd-0003me-QF for keyprov@ietf.org; Tue, 14 Aug 2007 04:07:03 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKrQd-0001pe-1t for keyprov@ietf.org; Tue, 14 Aug 2007 04:07:03 -0400 Received: (qmail invoked by alias); 14 Aug 2007 08:07:01 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp052) with SMTP; 14 Aug 2007 10:07:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/BuDNQiBLBXEAKKN34c372yMuctLi/zjjGcR4Gro cOkEmi0/7N2i20 Message-ID: <46C162A3.10103@gmx.net> Date: Tue, 14 Aug 2007 10:06:59 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Hoyer Subject: Re: [KEYPROV] Confirmation of KEYPROV IETF 69 Working Group Hums on draft-hoyer-keyprov-portable-symmetric-key-container-02.txt References: <46A8F5CD.7020908@gmx.net> In-Reply-To: <46A8F5CD.7020908@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: keyprov@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org There was no objection raised. Phillip, please resubmit the draft as a KEYPROV working group item (i.e., draft-ietf-keyprov-portable-symmetric-key-container-00.txt). Ciao Hannes Hannes Tschofenig wrote: > Hi all, > > we asked the group during the KEYPROV session whether > draft-hoyer-keyprov-portable-symmetric-key-container-02.txt should > become a WG item as a baseline for the work on the > mandatory-to-implement XML-based key container format. > > The group was in favor. No objections have been raised. > > If you have objections please post a mail. > Deadline: 11th August 2007 > > Ciao > Hannes & Phillip > > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 14 04:24:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKrhV-0007gT-It; Tue, 14 Aug 2007 04:24:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKrhU-0007gN-ME for keyprov@ietf.org; Tue, 14 Aug 2007 04:24:28 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKrhU-0002Gj-4H for keyprov@ietf.org; Tue, 14 Aug 2007 04:24:28 -0400 Received: (qmail invoked by alias); 14 Aug 2007 08:24:24 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp053) with SMTP; 14 Aug 2007 10:24:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18IpUV/9+cI3QSOtQ79kJTdOLiLqq9pupSAJBZ6LR EewIrVrib4UNQq Message-ID: <46C166B7.3030907@gmx.net> Date: Tue, 14 Aug 2007 10:24:23 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: turners@ieca.com Subject: Re: [KEYPROV] Confirmation of KEYPROV IETF 69 Working Group Hums on draft-turner-symmetrickeyformat-00.txt References: <46A8F5E0.5060405@gmx.net> In-Reply-To: <46A8F5E0.5060405@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: keyprov@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org There was no objection raised. Sean, please resubmit the draft as a KEYPROV working group item (i.e., draft-ietf-keyprov-symmetric-key-format-00.txt). Ciao Hannes Hannes Tschofenig wrote: > Hi all, > > we asked the group during the KEYPROV session whether > draft-turner-symmetrickeyformat-00.txt should become a WG item as a > baseline for the work on an optional-to-implement ASN.1-based key > container format. > > The group was in favor. No objections have been raised. > > If you have objections please post a mail. > Deadline: 11th August 2007 > > Ciao > Hannes & Phillip > > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Wed Aug 15 18:56:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRmY-0004qU-B7; Wed, 15 Aug 2007 18:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRmX-0004qP-Ni for keyprov@ietf.org; Wed, 15 Aug 2007 18:56:05 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ILRmW-0005AW-FO for keyprov@ietf.org; Wed, 15 Aug 2007 18:56:05 -0400 Received: (qmail invoked by alias); 15 Aug 2007 22:56:03 -0000 Received: from p5498784B.dip.t-dialin.net (EHLO [192.168.1.2]) [84.152.120.75] by mail.gmx.net (mp039) with SMTP; 16 Aug 2007 00:56:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+IqBI/fgyIeGSxCpwdCnBKOGtIao5g/2porY31yM QEuoA9lXLPl3VS Message-ID: <46C38484.3070702@gmx.net> Date: Thu, 16 Aug 2007 00:56:04 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: keyprov@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 2.9 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [KEYPROV] Meeting Minutes X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Please check the meeting minutes: http://www3.ietf.org/proceedings/07jul/minutes/keyprov.txt _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Aug 16 09:50:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILfkH-0003bD-Vm; Thu, 16 Aug 2007 09:50:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILfkG-0003XC-UP for keyprov@ietf.org; Thu, 16 Aug 2007 09:50:41 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILfkG-0007q4-50 for keyprov@ietf.org; Thu, 16 Aug 2007 09:50:40 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7GDoafl005230; Thu, 16 Aug 2007 09:50:36 -0400 (EDT) Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7GDoWhE008351; Thu, 16 Aug 2007 09:50:33 -0400 (EDT) Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id l7GDoUuS029595; Thu, 16 Aug 2007 09:50:30 -0400 (EDT) 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, 16 Aug 2007 09:50:29 -0400 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970C2C849E@rsana-ex-hq1.NA.RSA.NET> In-Reply-To: <3E5A2F1AD44F5E49A74F79AB47C0C0C939F330@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review comments - PSKC thread-index: AcfCF8H5roqi9T3eT+Sz0sEoRNv5sAAJE+nAB3G4/3A= References: <3E5A2F1AD44F5E49A74F79AB47C0C0C939F330@mou1wnexmb10.vcorp.ad.vrsn.com> From: "Doherty, Andrea" To: "Pei, Mingliang" , , "Philip Hoyer" X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__CP_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: Subject: [KEYPROV] Review comments - PSKC X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org I reviewed draft-hoyer-keyprov-portable-symmetric-key-container-02.txt and have the following comments: General: =3D=3D=3D=3D=3D=3D=3D=3D 1. Align terminology with DSKPP, esp. use of "token", "credentials", "seed records", "shared secret", "secret key", "attributes" throughout the document. 2. Add section for IANA Considerations 3. Several typos found; recommend running document through spell checker. Abstract: =3D=3D=3D=3D=3D=3D=3D=3D=3D Is last paragraph appropriate for IETF document? Section 1 (Introduction): =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= 1. It would be best if this document would be more generic to application context. Currently, it is still more "OTP" focused than useful for all constituents interested in this specification. 2. First sentence should read "...systems based ^^upon^^ one time..." 3. Last sentence has spelling error "wherears" Section 3.1.1 (Credential migration by end-user): =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=3D=3D=3D Last paragraph - this is example where alignment with DSKPP Key Initialization Profiles will be required (refer to Issue #9 in issue tracker). Section 3.2.1 (Online provisioning...): =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 Perhaps clarify last sentence of first paragraph ("user can download more than one..."). Doesn't this capability depend on whether an application has concept of a session, and how the session is defined? Note that this capability is more of a provisioning server feature, and is not applicable to DSKPP. Section 3.2.2 (Server to server...): =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 First sentente, "...information from ^^a^^ manufacturer". Section 5.1.4 (KeyID): =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= Perhaps add explanation here that namespace is not encoded into the KeyID, but maintained as a separate attribute, e.g., "Issuer". Section 5.1.7 (AccessRules): =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 Recommend that you allow for a more complex PIN policy, esp., (a) how the PIN is to be used in the OTP calculation (e.g., concatenated vs. XOR's with the token code) and (b) PIN length. Section 5.1.8 (EncryptionMethod): =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 1. Align this section with DSKPP Key Initialization Methods (see Issue Tracker #9). 2. Last paragraph - "KeyContainer" is referred to here, but not previously defined. Section 6 (diagram): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Typo in diagram -- arrow between Key n and Key p should be shown to the right. 2. Align model represented by the diagram with Object Model in DSKPP. 3. Provide note that while PSKC supports bulk provisioning of keys, DSKPP does not. Section 6.1.1 (KeyType): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. SECRET has typo "key key".=20 2. Last paragraph on 'Value Digest' - Perhaps refer to Section 5.1.8 for clarity. Section 6.1.2 (UsageType): =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 - replace reference to [OCRA] with URI. Section 6.1.4 (DeviceIdType): =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 1. Would be better if description were more generic; add storage device as an example. 2. I recommend base64Binary as data type for SerialNo. Section 6.1.5 (UserType): =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= To be consistent with the DSKPP Object Model, "UserIdType" would be more consistent that "UserType". Alternatively, "ClientIDType" would be more consistent than "UserType" since a user may be a software application. Section 6.1.9 (AlgorithmIdentifierType): =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 1. Replace [OCRA] throughout this section with appropriate URI. 2. "The AlgorithmIdentifierType is define^^d^^ as follows" Section 6.5 (KeyAlgorithmType): =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 This type overlaps with "KeyType" in DSKPP; align. Section 8.1 (Payload Confidentiality): =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 I recommend that you identify and define each of the profiles that are described at a high-level here. Section 8.2 (Payload Integrity): =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 "provides a mean^^s^^ to" Section 11 (Normative References): =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 1. Many of the references in the list are not normative but "informative" (e.g., all of the I-D's). I think the section should either be divided in two, or simply called "References". 2. Is [OATHRefArch] used in the document? 3. Update [DSKPP] reference to draft-ietf-keyprov-dskpp-00.txt. -- Andrea _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Aug 16 18:36:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILnws-0006cz-6T; Thu, 16 Aug 2007 18:36:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILnwq-0006aC-1H for keyprov@ietf.org; Thu, 16 Aug 2007 18:36:12 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILnwo-0006AM-QP for keyprov@ietf.org; Thu, 16 Aug 2007 18:36:11 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7GMaAHp017415 for ; Thu, 16 Aug 2007 18:36:10 -0400 (EDT) Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7GMa8b5004513 for ; Thu, 16 Aug 2007 18:36:08 -0400 (EDT) Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id l7GMa7uS007804 for ; Thu, 16 Aug 2007 18:36:07 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Aug 2007 18:35:29 -0400 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970BABBD11@rsana-ex-hq1.NA.RSA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IEEE_P1619] [1619.3] 2007-08-15 Meeting Minutes and Roster thread-index: AcffdR4InII8OEHSRbyLH5XxDidxSAA4KF/6 References: A<46C3581B.3010402@cisco.com> From: "Doherty, Andrea" To: X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [KEYPROV] FW: [IEEE_P1619] [1619.3] 2007-08-15 Meeting Minutes and Roster X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Please find minutes from yesterday's P1619.3 meeting. Note that I = provided an update on our work at this meeting. Andrea ________________________________ From: Fabio Maino [mailto:fmaino@CISCO.COM] Sent: Wed 8/15/2007 3:46 PM To: STDS-P1619@listserv.ieee.org Subject: [IEEE_P1619] [1619.3] 2007-08-15 Meeting Minutes and Roster Minutes are online at: https://siswg.net/index.php?option=3Dcom_content&task=3Dcategory§ioni= d=3D10&id=3D34&Itemid=3D64 Roster at: https://siswg.net/index.php?option=3Dcom_docman&task=3Ddoc_download&gid=3D= 35&Itemid=3D41 Fabio _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Mon Aug 27 19:14:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPnmf-0002Zw-Lx; Mon, 27 Aug 2007 19:14:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPnme-0002Zr-Ij for keyprov@ietf.org; Mon, 27 Aug 2007 19:14:12 -0400 Received: from smtp104.biz.mail.re2.yahoo.com ([206.190.52.173]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPnmd-0004vN-WE for keyprov@ietf.org; Mon, 27 Aug 2007 19:14:12 -0400 Received: (qmail 65155 invoked from network); 27 Aug 2007 23:14:11 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.2.130 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 27 Aug 2007 23:14:11 -0000 X-YMail-OSG: N_X3D6UVM1lasjAmKSlTVY2_LgwknClMlGh_1Goiklvc08NxaMBIFymz6uZIoHlHPsGxTzHGWQ-- From: "Turner, Sean P." To: Date: Mon, 27 Aug 2007 19:14:14 -0400 Organization: IECA, Inc. Message-ID: <011001c7e8ff$fdc1f5c0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfo//ufMOE+vBjIQpK91fKDZxGr7w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [KEYPROV] Comments on draft-ietf-keyprov-dskpp-00.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Here are some comments/questions on draft-ietf-keyprov-dskpp-00 (note that I only skimmed the schema section): * Which variant(s) is(are) the MUSTs for the client? for the server? Does someone claiming conformance to this document need to support 4, 2, and 1-pass or can they claim conformance for just 4, 2, or 1-pass? * The term symmetric cryptographic module is used in many places, suggest changing it to symmetric key cryptography module? A symmetric modules makes it sound like both sides are the same ;) * The concept of an issuer is first introduced in 3.3. It should be described in section 2. (and maybe 4.1?) * (sec 4.2.1) Step c indicates the CM should verify the server's certificate before using it to encrypt R_C, add reference to [RFC3280] for step's necessary to verify the server's certificate. * (sec 4.2.2 and sec 4.2.3) In the 2-pass and 1-pass descriptions, they mention that the scenarios can be used when adminstrator approval is required. For me that would entail a , a that indicates waiting-on-approval (pending or whatever state), then either another client generated to ask about the previous or a server generated response . Does this match what you were thinking? If so is it worth, having a section that describes the 'wait I'm getting approval' scenarios? * (sec 4.3.1) Which of the 3 client authentication mechanism is the MUST and which are the SHOULDs for the client? for the server? * (sec 4.4) Can we add a reference to the ASN.1 based symmetric key content type ID? * (sec 4.5.1) What is the MUST DSKPP-PRF for the client? for the server? The last sentence points to Annex E for realizations of the DSKPP-PRF but it is unclear whether the appendix is normative and which realization is required. * (sec 4.5.2) The last sentence indicates the secret key k 'MUST be 16 octets long' shouldn't it be 'MUST be at least 16 octets long'? * (sec 4.7) What is the MUST algorithm for encryption of the pseudorandom Nonces sent from the client? * (sec 4.6 and 4.7) I'm not a cryptographer but why not pick osmething more useful than 'Encryption' and 'Key Generation' as the thing to concatenate with - maybe Time? * (sec 4.9.2) Should the Version be set to 1.0 like para 4.9.1. That is, should we add: Version MUST be set to "1.0". * (sec 4.9.5) Is there a way to make at least of the values in StatusCode be present - or is this taken care of in the use="required" in AbstractResponseType? * (sec 4.9.10, 4.9.11, 4.9.12, and 4.10.2) OPTIONALLY is not a key word. Suggest something along the lines of "The ProtocolVariantsType type is OPTIONAL for clients. It is used by DSKPP clients to indicate the number of passes of the DSKPP protocol that is supports (see Section 4.2)." * (sec 4.9.11) Add space between two types in title. Add ")" to end of paragraph. * (sec 4.10.2) Delete "optional" from title and add "This section is optional for both clients and servers." Assuming it's true. * (sec 7) Should considerations be added for when the issuer acts a proxy between the provisioning server? * Are Annexes A-E information or normative? Please indicate as much. * With the definition of the authenticated-encrypted algorithms is there any thought to using these algorithms here? * Do we need to support internationalization of the string concatenated in the DSKPP-PRF, K_Token, and MACs ;) spt _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 28 19:37:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQAct-0008Ki-Nq; Tue, 28 Aug 2007 19:37:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQAcs-0008Jz-DY for keyprov@ietf.org; Tue, 28 Aug 2007 19:37:38 -0400 Received: from supertimor.gemalto.com ([194.88.222.178] helo=supertimor.gemplus.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQAcq-0004zu-Py for keyprov@ietf.org; Tue, 28 Aug 2007 19:37:38 -0400 Received: from GMSEXC02.CORP.DS.GEMPLUS.COM (unknown [10.2.158.62]) by supertimor.gemplus.com (Postfix) with ESMTP id 120B91FB021; Tue, 28 Aug 2007 23:37:36 +0000 (GMT) Received: from GMSEXC07.CORP.DS.GEMPLUS.COM ([10.2.158.55]) by GMSEXC02.CORP.DS.GEMPLUS.COM with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 01:37:36 +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 Subject: RE: [KEYPROV] Review comments - PSKC Date: Wed, 29 Aug 2007 01:33:06 +0200 Message-ID: <093F8C873752A84D98A28841099DF380178D7B@GMSEXC07.CORP.DS.GEMPLUS.COM> In-Reply-To: <017630AA6DF2DF4EBC1DD4454F8EE2970C2C849E@rsana-ex-hq1.NA.RSA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Review comments - PSKC thread-index: AcfCF8H5roqi9T3eT+Sz0sEoRNv5sAAJE+nAB3G4/3ACbsNlcA== From: "CHANG Shuh" To: "Doherty, Andrea" , "Pei, Mingliang" , , "Philip Hoyer" , , "CHANG Shuh" X-OriginalArrivalTime: 28 Aug 2007 23:37:36.0186 (UTC) FILETIME=[69DA41A0:01C7E9CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Cc: X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Hi Andrea, Thanks for the great comments on the PSKC draft. The PSKC WG had an extensive discussion today and is providing the responses shown below under each issue. Regards, Shuh =20 > -----Original Message----- > From: Doherty, Andrea [mailto:adoherty@rsa.com]=20 > Sent: Thursday, August 16, 2007 8:50 AM > To: Pei, Mingliang; keyprov@ietf.org; Philip Hoyer > Subject: [KEYPROV] Review comments - PSKC >=20 > I reviewed draft-hoyer-keyprov-portable-symmetric-key-container-02.txt > and have the following comments: >=20 > General: > =3D=3D=3D=3D=3D=3D=3D=3D > 1. Align terminology with DSKPP, esp. use of "token",=20 > "credentials", "seed records", "shared secret", "secret key",=20 > "attributes" throughout the document. We acknowledge this issue, and will address it in the next revision. >=20 > 2. Add section for IANA Considerations We will add this IANA section in this revision. (Ming's work item) >=20 > 3. Several typos found; recommend running document through=20 > spell checker. Yes, we'll do that. (Ming's work item) >=20 > Abstract: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > Is last paragraph appropriate for IETF document? We'll remove this paragraph and add it in the Acknowledgement section. (Ming's work item) This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a format that can be freely distributed to the technical community. >=20 > Section 1 (Introduction): > = =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= > 1. It would be best if this document would be more generic to=20 > application context. Currently, it is still more "OTP"=20 > focused than useful for all constituents interested in this=20 > specification. Need further discussion, and we'll address this issue in the next revision. >=20 > 2. First sentence should read "...systems based ^^upon^^ one time..." Yes, we'll correct that. (Ming will correct it today.) >=20 > 3. Last sentence has spelling error "wherears" Yes, we'll correct that. (Ming will correct it today.) >=20 > Section 3.1.1 (Credential migration by end-user): > = =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=3D=3D=3D > Last paragraph - this is example where alignment with DSKPP=20 > Key Initialization Profiles will be required (refer to Issue=20 > #9 in issue tracker). Need further discussion, and we'll address this issue in the next revision. >=20 > Section 3.2.1 (Online provisioning...): > = =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 > Perhaps clarify last sentence of first paragraph ("user can=20 > download more than one..."). Doesn't this capability depend=20 > on whether an application has concept of a session, and how=20 > the session is defined? > Note that this capability is more of a provisioning server=20 > feature, and is not applicable to DSKPP. We'll clarify and rephrase the sentence to "a payload can contain multiple credentials". We'll address this issue in this revision. >=20 > Section 3.2.2 (Server to server...): > = =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 > First sentente, "...information from ^^a^^ manufacturer". Yes, we'll correct that. (Ming will correct it today.) >=20 > Section 5.1.4 (KeyID): > = =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= > Perhaps add explanation here that namespace is not encoded=20 > into the KeyID, but maintained as a separate attribute, e.g.,=20 > "Issuer". Agree and will do it in the next revision.. (Ming's action item) >=20 > Section 5.1.7 (AccessRules): > = =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 > Recommend that you allow for a more complex PIN policy, esp.,=20 > (a) how the PIN is to be used in the OTP calculation (e.g.,=20 > concatenated vs. > XOR's with the token code) and (b) PIN length. Yes, agree. Ming will open an issue in issuer tracker. Add (c) how to transfer initial PIN value. Shuh to chat with people for some best practice. The issue "When PIN is used, how do you actually transfer the initial PIN using PSKC?" needs to be further discussed. Different vendors might have different approaches. We'd also like to solicit from the KeyProv list members for inputs on this issue. >=20 > Section 5.1.8 (EncryptionMethod): > = =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 > 1. Align this section with DSKPP Key Initialization Methods=20 > (see Issue Tracker #9). We'll defer this to next revision. >=20 > 2. Last paragraph - "KeyContainer" is referred to here, but=20 > not previously defined. We'll rephrase this sentence by changing word "KeyContainer" to "payload". >=20 > Section 6 (diagram): > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 1. Typo in diagram -- arrow between Key n and Key p should be=20 > shown to the right. Yes and will correct. (Shuh's action item) >=20 > 2. Align model represented by the diagram with Object Model in DSKPP. This issue has been discussed in a previous PSKC conf call. The diagram is a more clear representation of the container. On the other hand, a more detailed object model will be genereated after the final XML schema is finalized. (Shuh's work item) >=20 > 3. Provide note that while PSKC supports bulk provisioning of=20 > keys, DSKPP does not. This is a provisioning protocol, not a format. Therefore, it's better to specify it in DSKPP. >=20 > Section 6.1.1 (KeyType): > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 1. SECRET has typo "key key".=20 Agree and will correct. (Ming will correct it today.) >=20 > 2. Last paragraph on 'Value Digest' - Perhaps refer to=20 > Section 5.1.8 for clarity. Agree and will rephrase in this revision. >=20 > Section 6.1.2 (UsageType): > = =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 > - replace reference to [OCRA] with URI. We'll do that in the next revision. Deferred when URI is used. >=20 > Section 6.1.4 (DeviceIdType): > = =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 > 1. Would be better if description were more generic; add=20 > storage device as an example. We'll rephrase it in the next revision. >=20 > 2. I recommend base64Binary as data type for SerialNo. Will track as an issue to discuss. (Ming) >=20 > Section 6.1.5 (UserType): > = =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= > To be consistent with the DSKPP Object Model, "UserIdType"=20 > would be more consistent that "UserType". Alternatively,=20 > "ClientIDType" would be more consistent than "UserType" since=20 > a user may be a software application. We'll refer this to further study. >=20 > Section 6.1.9 (AlgorithmIdentifierType): > = =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 > 1. Replace [OCRA] throughout this section with appropriate URI. We'll do that in the next revision. >=20 > 2. "The AlgorithmIdentifierType is define^^d^^ as follows" Agree and will correct. (Ming) >=20 > Section 6.5 (KeyAlgorithmType): > = =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 > This type overlaps with "KeyType" in DSKPP; align. PSKC already has a KeyType. KeyAlgorithm is another attribute layer on top of KeyType. The KeyAlgorithmType in PSKC is different from KeyType in DSKPP. KeyAlgorithmType is the algorithm where the key will be applied. Therefore, we'll need to do more study on this issue to better clarify. >=20 > Section 8.1 (Payload Confidentiality): > = =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 > I recommend that you identify and define each of the profiles=20 > that are described at a high-level here. We'll defer it to the next revision. >=20 > Section 8.2 (Payload Integrity): > = =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 > "provides a mean^^s^^ to" Agree and will correct. (Ming to change today) >=20 > Section 11 (Normative References): > = =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 > 1. Many of the references in the list are not normative but=20 > "informative" (e.g., all of the I-D's). I think the section=20 > should either be divided in two, or simply called "References". We need to further discuss this issue. >=20 > 2. Is [OATHRefArch] used in the document? Will remove it. >=20 > 3. Update [DSKPP] reference to draft-ietf-keyprov-dskpp-00.txt. Agree. (Ming to change in this revision) >=20 >=20 > -- Andrea >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Aug 28 22:10:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQD0k-0007Hp-4E; Tue, 28 Aug 2007 22:10:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQD0j-0007FT-7u for keyprov@ietf.org; Tue, 28 Aug 2007 22:10:25 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQD0i-0008GX-Oi for keyprov@ietf.org; Tue, 28 Aug 2007 22:10:25 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l7T290GZ009827 for ; Tue, 28 Aug 2007 19:09:00 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 19:10:24 -0700 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: Tue, 28 Aug 2007 19:10:23 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C9433573@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Auto Response] I-D submission: Portal Symmetric Key Container v1.0 as a KeyProv WG item Thread-Index: Acfp4Pv/sXKwhLEJSyKuEx0T8iUU2QAACDVQ From: "Pei, Mingliang" To: X-OriginalArrivalTime: 29 Aug 2007 02:10:24.0156 (UTC) FILETIME=[C26375C0:01C7E9E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [KEYPROV] FW: [Auto Response] I-D submission: Portal Symmetric Key Container v1.0 as a KeyProv WG item X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org We have just re-submitted PSKC draft as a keyprov work group WG item. The changes are the following from the last version by the authors. - File name change - Editor changes to reflect the last active authors - Fixes for some typos and reference updates as indicated by Andrea. Additional changes will be done in the next revision. - Ming -----Original Message----- From: Internet Draft Submission Manager [mailto:internet-drafts-reply@ietf.org]=20 Sent: Tuesday, August 28, 2007 7:05 PM To: Pei, Mingliang Subject: [Auto Response] I-D submission: Portal Symmetric Key Container v1.0 as a KeyProv WG item Greetings: This message is being sent to acknowledge receipt of your Internet-Draft submission or message to internet-drafts@ietf.org. If you submitted an Internet-Draft, then it will be posted on the Internet-Drafts page of the IETF Web site, and an I-D Action message will be sent to the I-D-Announce List. If you need to track the status of your Internet-Draft submission at a later date, then please send a note to ietf-action@ietf.org (using the suggested subject line Status of I-D Submission: ) and reference this auto-response acknowledgement in the body. Please note that all Internet-Drafts offered for publication as RFCs must conform to the requirements specified in I-D Checklist () or they will be returned to the author(s) for revision. Therefore, the IETF Secretariat strongly recommends that you address all of the issues raised in this document before submitting a request to publish your Internet-Draft to the IESG. The IETF Secretariat _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Aug 30 14:57:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQpCd-0005Fd-5y; Thu, 30 Aug 2007 14:57:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQpCb-0005FS-8t for keyprov@ietf.org; Thu, 30 Aug 2007 14:57:13 -0400 Received: from smtp110.biz.mail.re2.yahoo.com ([206.190.53.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IQpCa-0004OC-0V for keyprov@ietf.org; Thu, 30 Aug 2007 14:57:13 -0400 Received: (qmail 14242 invoked from network); 30 Aug 2007 18:57:11 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.108.27.185 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 30 Aug 2007 18:57:11 -0000 X-YMail-OSG: GyBuuagVM1ljj4A2g.NWbHYUkP7ACWyQyWgRsTfYyPCyYxtUrzf3gAOm8G9WLjuGOqPV2UpFtESxxZDTkjKrjMhfAaevUMJD_3GdtmUoy6ijwvWjZ6ozSQ2rdxYv7S8Jl8Qk4CFLCxRS4w-- From: "Turner, Sean P." To: Subject: FW: [Auto Response] RE: [KEYPROV] Confirmation of KEYPROV IETF 69 Working Group Hums on draft-turner-symmetrickeyformat-00.txt Date: Thu, 30 Aug 2007 14:57:12 -0400 Organization: IECA, Inc. Message-ID: <012a01c7eb37$94e60660$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfrKjACSZ4YnqouTh6gL4hrEZIlPAAChLKQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org We have just re-submitted the Symmetric Key Format Content Type as a keyprov working group ID. The changes from the last version are as follows: - changed the file name - deleted '88 ASN.1 module and reference to the '88 ASN.1 documents as we believe it won't be needed by the time this ID gets to RFC status - included OIDs for the ASN.1 module and content type - required DER as the encoding for the content type spt >-----Original Message----- >From: Internet Draft Submission Manager >[mailto:internet-drafts-reply@ietf.org] >Sent: Thursday, August 30, 2007 1:21 PM >To: turners@ieca.com >Subject: [Auto Response] RE: [KEYPROV] Confirmation of KEYPROV >IETF 69 Working Group Hums on draft-turner-symmetrickeyformat-00.txt > > >Greetings: > >This message is being sent to acknowledge receipt of your >Internet-Draft submission or message to internet-drafts@ietf.org. >If you submitted an Internet-Draft, then it will be posted on >the Internet-Drafts page of the IETF Web site, and an I-D >Action message will be sent to the I-D-Announce List. If you >need to track the status of your Internet-Draft submission at >a later date, then please send a note to ietf-action@ietf.org >(using the suggested subject line Status of I-D Submission: >) and reference this auto-response acknowledgement >in the body. > >Please note that all Internet-Drafts offered for publication >as RFCs must conform to the requirements specified in I-D Checklist >() or they will be >returned to the author(s) for revision. Therefore, the IETF >Secretariat strongly recommends that you address all of the >issues raised in this document before submitting a request to >publish your Internet-Draft to the IESG. > >The IETF Secretariat > _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov