Subject: [KEYPROV] KEYPROV Meeting Minutes, 9th December 2008

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 14 Dec 2008 11:19:57 +0200

KEYPROV Meeting Minutes, 9th December 2008
------------------------------------------

Participants: 

  - Hannes Tschofenig 
  - Philip Hoyer 
  - Andrea Doherty

Hannes went through the changes he proposed to the PSKC document to improve
readability. 
As part of this activity the following questions were raised:

 * The <Extensions> element is repeated throughout the document many times.
It might make more sense to discuss it  once in the extensibility section
instead. Everyone agreed. 

 * During the IETF KEYPROV meeting we discussed whether PSKC extensions
should use the version attribute or the a new  URN identifier. It was agreed
to use the version attribute and to create a registry for it. Hannes will
add a  registry to the IANA consideration section. 

 * Hannes suggested to make use of "choice" instead of "sequence" for XML
elements in order not to demand a specific  element ordering. The question
was raised whether there is a specific ordering imposed by the ASN.1
encoding. Sean  has to provide an answer for this question. 

 * The Usage->Format specifies Encrypt/Integrity/Unlock usage in addition to
CR and OTP usage. There is a detailed  description for CR and OTP but not
for the other values. Philip mentiones that other values, such as decrypt
and key  wrap might be missing. Andrea mentioned that DSKPP uses a different
way of expressing the same information. Everyone  agreed that it does not
make sense to have two different ways to specify this functionality. Hence,
we should try to  align it with DSKPP. We should also call this element
<action>. 

 * Why does the PINUsageMode element need to carry a child element to
describe local, prepend, etc.? Philip mentioned  that Salah came up with
this design and that he believes we should use attributes instead since the
current encoding  is very different from everything else that is being used
throughout the document. A similar comment applies to the   PINPolicy
element. Only attributes would be easier to understand. 

 * While working on the document Hannes noticed that bulk provisioning used
an optimization technique to avoid having  to repeat containers. However,
this optimization only provides slight size optimizations that might not
make a lot of  sense given that the entire encoding uses XML already, which
is very verbose. Hence, there was the question whether  this optimization is
useful given that it makes PSKC more complicated. Philip said that the
optimization was only  introduced because of the alignment with the ASN.1
encoding. Hannes suggested to ask Sean whether this is really  necessary in
the ASN.1 based key container. Additionally, the group should be asked
whether there is agreement to  have this optimization in the document. 

The next steps for the document editing are: Hannes is going to complete the
initial edits. Philip and Hannes will then discuss the detailed edits to
identify open issues. 

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 15 Dec 2008 17:46:58 +0100

Hannes,
some clarifications on the KeyProperties.

The ability to carry common attributes about multiple keys in the
container was discussed at IETF in Philadelphia and on the list.

The ability to do so via KeyProperties has been discussed by the authors
in the calls and outside and usually well received by different parties.

Hence it is not only a case of alignment with the ASN.1 spec from Sean.

Philip 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hannes Tschofenig
Sent: Sunday, December 14, 2008 9:20 AM
To: [email-masked]
Subject: [KEYPROV] KEYPROV Meeting Minutes, 9th December 2008

Participants: 

  - Hannes Tschofenig 
  - Philip Hoyer 
  - Andrea Doherty

Hannes went through the changes he proposed to the PSKC document to
improve
readability. 
As part of this activity the following questions were raised:

 * The <Extensions> element is repeated throughout the document many
times.
It might make more sense to discuss it  once in the extensibility
section
instead. Everyone agreed. 

 * During the IETF KEYPROV meeting we discussed whether PSKC extensions
should use the version attribute or the a new  URN identifier. It was
agreed
to use the version attribute and to create a registry for it. Hannes
will
add a  registry to the IANA consideration section. 

 * Hannes suggested to make use of "choice" instead of "sequence" for
XML
elements in order not to demand a specific  element ordering. The
question
was raised whether there is a specific ordering imposed by the ASN.1
encoding. Sean  has to provide an answer for this question. 

 * The Usage->Format specifies Encrypt/Integrity/Unlock usage in
addition to
CR and OTP usage. There is a detailed  description for CR and OTP but
not
for the other values. Philip mentiones that other values, such as
decrypt
and key  wrap might be missing. Andrea mentioned that DSKPP uses a
different
way of expressing the same information. Everyone  agreed that it does
not
make sense to have two different ways to specify this functionality.
Hence,
we should try to  align it with DSKPP. We should also call this element
<action>. 

 * Why does the PINUsageMode element need to carry a child element to
describe local, prepend, etc.? Philip mentioned  that Salah came up with
this design and that he believes we should use attributes instead since
the
current encoding  is very different from everything else that is being
used
throughout the document. A similar comment applies to the   PINPolicy
element. Only attributes would be easier to understand. 

 * While working on the document Hannes noticed that bulk provisioning
used
an optimization technique to avoid having  to repeat containers.
However,
this optimization only provides slight size optimizations that might not
make a lot of  sense given that the entire encoding uses XML already,
which
is very verbose. Hence, there was the question whether  this
optimization is
useful given that it makes PSKC more complicated. Philip said that the
optimization was only  introduced because of the alignment with the
ASN.1
encoding. Hannes suggested to ask Sean whether this is really  necessary
in
the ASN.1 based key container. Additionally, the group should be asked
whether there is agreement to  have this optimization in the document. 

The next steps for the document editing are: Hannes is going to complete
the
initial edits. Philip and Hannes will then discuss the detailed edits to
identify open issues.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 17 Dec 2008 09:02:46 +0200

Hi Philip, 

Thanks for this additional clarification. 

It would be interesting to hear what other folks think about this topic. 

The functionality of bulk provisioning is provided in the current
specification by allowing multiple <Device> and multiple <Key> elements to
be repeated. There is also a version that provides a further optimization by
utilizing a separate element <KeyProperties>. When using the <KeyProperties>
element some parameters do not need to get repeated in the individual
<Device> / <Key> elements. Consequently, the XML file would be shorter. 

Now the questions are: 

* Is an optimization providing us a lot? 
* If yes: Do we need this optimization in the main document? 

Ciao
Hannes

>From: Philip Hoyer [mailto:[email-masked]] 
>Sent: 15 December, 2008 18:47
>To: Hannes Tschofenig; [email-masked]
>Subject: RE: [KEYPROV] KEYPROV Meeting Minutes, 9th December 2008
>
>Hannes,
>The ability to carry common attributes about multiple keys in 
>the container was discussed at IETF in Philadelphia and on the list.
>
>The ability to do so via KeyProperties has been discussed by 
>the authors in the calls and outside and usually well received 
>by different parties.
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>Hannes went through the changes he proposed to the PSKC 
>document to improve readability. 
>It might make more sense to discuss it  once in the 
>extensibility section instead. Everyone agreed. 
>
> * During the IETF KEYPROV meeting we discussed whether PSKC 
>extensions should use the version attribute or the a new  URN 
>identifier. It was agreed to use the version attribute and to 
>create a registry for it. Hannes will add a  registry to the 
>IANA consideration section. 
>
> * Hannes suggested to make use of "choice" instead of 
>"sequence" for XML elements in order not to demand a specific  
>element ordering. The question was raised whether there is a 
>specific ordering imposed by the ASN.1 encoding. Sean  has to 
>provide an answer for this question. 
>
> * The Usage->Format specifies Encrypt/Integrity/Unlock usage 
>in addition to CR and OTP usage. There is a detailed  
>description for CR and OTP but not for the other values. 
>Philip mentiones that other values, such as decrypt and key  
>wrap might be missing. Andrea mentioned that DSKPP uses a 
>different way of expressing the same information. Everyone  
>agreed that it does not make sense to have two different ways 
>to specify this functionality.
>Hence,
>we should try to  align it with DSKPP. We should also call 
>this element <action>. 
>
> * Why does the PINUsageMode element need to carry a child 
>element to describe local, prepend, etc.? Philip mentioned  
>that Salah came up with this design and that he believes we 
>should use attributes instead since the current encoding  is 
>very different from everything else that is being used
> * While working on the document Hannes noticed that bulk 
>provisioning used an optimization technique to avoid having  
>to repeat containers.
>However,
>this optimization only provides slight size optimizations that 
>might not make a lot of  sense given that the entire encoding 
>uses XML already, which is very verbose. Hence, there was the 
>question whether  this optimization is useful given that it 
>makes PSKC more complicated. Philip said that the optimization 
>was only  introduced because of the alignment with the
>ASN.1
>encoding. Hannes suggested to ask Sean whether this is really  
>necessary in the ASN.1 based key container. Additionally, the 
>group should be asked whether there is agreement to  have this 
>optimization in the document. 
>
>The next steps for the document editing are: Hannes is going 
>to complete the initial edits. Philip and Hannes will then 
>discuss the detailed edits to identify open issues. 
>