Subject: [KEYPROV] I-D Action:draft-ietf-keyprov-pskc-00.txt

From: [email-masked]
Date: Tue, 13 Jan 2009 12:30:01 -0800 (PST)

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           : Portable Symmetric Key Container (PSKC)
	Author(s)       : P. Hoyer, et al.
	Filename        : draft-ietf-keyprov-pskc-00.txt
	Pages           : 58
	Date            : 2009-01-13

This document specifies a symmetric key format for transport and
provisioning of symmetric keys (for example One Time Password (OTP)
shared secrets or symmetric cryptographic keys) to different types of
crypto modules, such as a strong authentication device.  The standard
key transport format enables enterprises to deploy best-of-breed
solutions combining components from different vendors into the same
infrastructure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Jan 2009 16:47:47 -0500

First off congratulations of deleting almost 40 pages from the ID!  It 
is much easier/quicker to read now.  My comments are mostly editorial in 
nature with a few questions sprinkled in.

General:
#1) If it's possible, I think you should say which element, child 
element and attributes are mandatory/optional.  What you did in Sec 4.2 
for <Key> (i.e., grouping mandatory/optional elements) was clear, but to 
avoid too much work all you'd need to do is add optional or mandatory at 
the beginning of the description.  For example:

<Manufacturer>:  This **mandatory** element indicates the manufacturer 
of the device.

#2) There are a few mays/musts.  Just wanted to make sure they're all 
not supposed to be MAY/MUST.

Specific comments/questions:

Sec 4:

r/This is useful when needing to refer to an/This is useful when 
referring to an

r/one <Device> elements/one <Device> element

r/Multiple <Device> elements may be/Multiple <Device> elements can be

Sec 4.1:

r/The <DeviceInfo> element allows to uniquely identify/The <DeviceInfo> 
element uniquely identifies

r/IssuerDN/Issuer Distinguished Name
Add "." to end of <SerialNo> and <Model> paragraphs.

Which of the <DeviceInfo> child elements are mandatory/optional?

Sec 4.2:
r/Section 4.4 There/Section 4.4.  There

r/element, namely/element, namely:

r/in that they must support/in that they MUST support

r/integrity checks, may be/integrity checks, MAY be

r/or BINARY/or BINARY.

Which of the child elements for <Data> are mandatory/optional?

If CheckDigit is included and Encoding is not DECIMAL is the checkDigit 
ignored?  If so I think you should say that.

Shouldn't <Policy> be listed as a mandatory/optional child element of <Key>?

Sec 5
r/The element may also be repeated/The element MAY also be repeated

r/i.e., the key may be utilized/i.e., the key MAY be utilized

Which of the elements are mandatory/optional?

Sec 6.1:
Any reason HMAC-SHA224 was omitted?

Which of the elements are mandatory/optional?

Appendix A.1
r/such as [DSKPP]/such as [DSKPP].

spt

[email-masked] wrote:
> ------------------------------------------------------------------------
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 14 Jan 2009 00:34:20 +0200

Hi Sean, 

Thanks for your quick feedback. 

>First off congratulations of deleting almost 40 pages from the 
>ID!  It is much easier/quicker to read now.  My comments are 
>mostly editorial in nature with a few questions sprinkled in.
>
>General:
>#1) If it's possible, I think you should say which element, 
>child element and attributes are mandatory/optional.  What you 
>did in Sec 4.2 for <Key> (i.e., grouping mandatory/optional 
>elements) was clear, but to avoid too much work all you'd need 
>to do is add optional or mandatory at the beginning of the 
>description.  For example:
>
><Manufacturer>:  This **mandatory** element indicates the 
>manufacturer of the device.

It was our intention to indicate the mandatory elements, see note in Section
2. 

Obviously we do not yet have it consistently in the doc. 

>
>#2) There are a few mays/musts.  Just wanted to make sure 
>they're all not supposed to be MAY/MUST.

I also spotted some may/should statement that should use RFC 2119 language
instead. 

>r/This is useful when needing to refer to an/This is useful 
>when referring to an
>
>r/The <DeviceInfo> element allows to uniquely identify/The 
><DeviceInfo> element uniquely identifies
>

I would say none. The identification for different types of devices may vary
and hence it would be difficult from the list to say what element is always
present for all devices. 

>Which of the child elements for <Data> are mandatory/optional?

The XML schema says none of them is mandatory. 

>
>If CheckDigit is included and Encoding is not DECIMAL is the 
>checkDigit ignored?  If so I think you should say that.
>

Yep. I has to be indicated as an optional child element of <Key> 

>Which of the elements are mandatory/optional?

These are only optional elements

>Any reason HMAC-SHA224 was omitted?

Nope
(at least not from my point of view)

>Which of the elements are mandatory/optional?

Good point

I would say:

     <EncryptionKey>
         <ds:KeyName>Pre-shared-key</ds:KeyName>
     </EncryptionKey>
     <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
     </MACAlgorithm>

And 

                 <Secret>
                     <EncryptedValue>
                         <xenc:EncryptionMethod
                         Algorithm=
                         "http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                         <xenc:CipherData>
                         <xenc:CipherValue>
                         pgznhXdDh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=
                         </xenc:CipherValue>
                         </xenc:CipherData>
                     </EncryptedValue>
                     <ValueMAC>zdrZbGBj9BDZJzunbfAG3kyZyYc=
                     </ValueMAC>
                 </Secret>

>r/such as [DSKPP]/such as [DSKPP].

Thanks. 

Ciao
Hannes