Re: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-03.txt

[Sean Turner <turners at ieca.com>]

Here are my comments.  I'd say these were all nits and that the document 
is ready to proceed.  I hope to not duplicate Andrea's comments.

Abstract: r/The standard/A standard

Intro: r/of a IANA/of an IANA

Sec 1.3: r/semantics../semantics.

Sec 3: r/upmost/at most?

Sec 4.1, 'Algorithm': r/[PSKC-ALGORITHM-PROFILES]/[PSKC-ALGORITHM-PROFILES].

Sec 4: r/This attribute is mandatory./This attribute MUST be included.

Sec 4/4.1: (I waffled on whether or not to include this as a comment) 
Should the values used in Figure 2 be referenced in 4/4.1?  e.g., 'Id:' 
 The 'Id' attribute carries a unique identifier for the container.  For 
this example, the value is "exampleID1".  It ties the examples to the 
text, and might help some readers.

Sec 4.1, <Time>: r/dependent)/dependent).

Sec 4.1, Encrypted: r/value/value.

Sec 4.2.2: r/ token)/ token).

Sec 4.2.2: r/has a single mandatory child element/has a single child 
element that MUST be included:

Sec 4.2.3: r/,DC=net/,DC=net.

Sec 4.2.3: r/Although the syntax of the user identifier is defined there 
/Although the syntax of the user identifier is defined, there

Sec 4.2.4 (x2): r/'CheckDigit':  This optional attribute 
indicates/'CheckDigit':  This attribute indicates

Sec 4.2.4: Mandatory isn't an RFC 2119 keyword.  I think we need to 
change where ever 'mandatory' is to work in a MUST.

r/'Encoding':  This mandatory attribute defines/'Encoding':  This 
attribute, which MUST be included in <ChallengeFormat>, defines

r/'Min':  This mandatory attribute defines/'Min':  This attribute, which 
MUST be included in <ChallengeFormat>, defines

r/'Max':  This mandatory attribute defines/'Max':  This attribute, which 
MUST be included in <ChallengeFormat>, defines

r/'Encoding':  This mandatory attribute defines/'Encoding':  This 
attribute, which MUST be included in <ResponseFormat>, defines

r/'Min':  This mandatory attribute defines/'Min':  This attribute, which 
MUST be included in <ResponseFormat>, defines

r/'Max':  This mandatory attribute defines/'Max':  This attribute, which 
MUST be included in <ResponseFormat>, defines

Sec 4.3 (2nd para): r/sending and receiving party/sending and receiving 
parties

Fig 3/5: Should <UserId> be in Fig 3.  It's not in Fig 5?

Sec 6.1: r/Since AES128-CBC does not provide integrity checks a keyed 
MAC/As AES128-CBC does not provide integrity checks, a keyed MAC

Sec 6.1: r/is use as the algorithm/is used as the algorithm

Fig 6: r/ Figure 6: AES-128-CBC Encrypted Pre-Shared Secret Key/Figure 
6: AES-128-CBC Encrypted Pre-Shared Secret Key with SHA1 as HMAC

Sec 6.1: Is there a reason:

HMAC-SHA224    | http://www.w3.org/2001/04/xmldsig-more#hmac-sha224

wasn't included?

Sec 6.3 (last para): r/asymmetric key encryption algorithm/asymmetric 
key encryption algorithm.

Sec 9 (Algorithm URIs): r/The usage of new/The use of new

Sec 9 (Policy): r/the usage of the key/the use of the key

spt

Hannes Tschofenig wrote:
> Hi all, 
>
> This is the 2nd Working Group Last Call for comments on "Portable Symmetric
> Key Container (PSKC)":
> http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-03.txt
>
> Please have comments to the list by Sunday, 27 June.
>
> As always, please remember to send a note in if you've read the document and
> have no other comments other than "its ready to go" - we need those as much
> as we need "I found a problem".
>
> Ciao
> Hannes & Phillip
>
>
>
>
> _______________________________________________
> KEYPROV mailing list
> KEYPROV at ietf.org
> https://www.ietf.org/mailman/listinfo/keyprov