[KEYPROV] Review of draft-ietf-keyprov-portable-symmetric-key-container-02.txt

[Hannes Tschofenig <[e-mail]>]

Hi all,

I read through draft-ietf-keyprov-portable-symmetric-key-container-02.txt.
I have a couple of comments.

* There are a couple of editorial issues but I will provide them to the 
authors offline.

* Structure of the document

I believe the structure and presentation of the document could be 
improved by re-arranging
sections and paragraphs it a bit.

Proposal for a modified ToC:

 o Introduction
 o Terminology
 o Use Cases
 o Requirements
 o Key Container
 
 [This is the part that is a bit tricky since you want to describe the 
data model in a way
  that the reader actually understands it. You would have to describe 
all attributes and
  elements in this section but the presentation style needs some 
discussion. ]
 
    o Introduction
      This section starts with the high-level overview of the structure 
of the key container.
      There is text to re-use already in Section 6 (and the 
corresponding figure as well.)
      This text would, for example, indicate  
       * what is the semantic if there are multiple <EncryptionMethod> 
elements within the <KeyContainer> element
       * what is the semantic if there are multiple <Device> elements 
within the <KeyContainer> element
      The text about the <KeyContainer> element is already in Section 6.4.1.
    o Device Element
      Text from Section 5.1 goes in here.
      The <DeviceId>, <Key> and <User> elements are child elements of 
the <device> element.
    o EncryptionMethod Element
      Text from Section 5.1.8 (and Section 6.1.7) goes in here.
    o DigestMethod Element
      Text from Section 5.1.9 (and Section 6.1.8) goes in here.
    o Signature Element
 o XML Schema
 o Security Considerations
 o IANA Considerations
 o References
      
 
 * Why is the <user> element a child element of the <device> element?
   Looking at the figure in Section 6 one would rather get the 
impression that the <user> element
   is a child element of the <KeyContainer> element that happens to have 
a relationship to the
   <device> element.
 * The <data> element is a bit strange. It is the attempt to map a TLV 
or AVP into XML.
   Here is an example (code snippet):

     <Data Name="COUNTER">
        <Value>AAAAAAAAAAA=</Value>
     </Data>

   Depending on the setting of the 'Name' attribute the value is 
interpreted in a different fashion.
   This is a somewhat strange usage of XML. Why don't you just define a 
new type that may contain
   different elements? This would also make the assignment of the data 
types a lot easier and
   would also offer extensibility in a nice fashion.
 * Section 7 contains two XML schemas. I would put them in two separate 
sub-sections since you
   may need to reference them separately in the IANA consideration section.
 * The IANA consideration section for the namespace registration and the 
schema registration is missing.
 * There are internationalization considerations when some of the fields 
are supposed to be processed
   by humans. Is this the case?
 * The Logo schema is pretty complex but it is not really well described 
in the document.
 * Section 5 and section 6 have a lot of overlap. The style is also 
somewhat different.
   Section 6 describes XML schema snippets. This is not good practice 
and not so helpful
   given that Section 7 lists the full schema anyway. It might be more 
helpful to provide
   more examples, if necessary.
   Some elements/attributes that are listed in Section 6 are not listed 
in Section 5 although
   it would be very useful (example: 'expiry').
 * There is no description of the examples. You don't need to put the 
examples in the appendix.
   It is fine to leave them in the main section since many readers are 
for sure going to look
   at the examples; if not only at the examples.
 * Section 5 has each element listed as (OPTIONAL) or (MANDATORY). This 
seems like a nice idea
   but was not done in a consistent fashion nor does it work well when 
you have dependencies to
   the occurrence of other elements/attributes/values.
 * XML element and XML attribute names are not used consistently in the 
same fashion.
 * With regard to the algorithm URIs there is no reference provided to 
Phillip's document.
   Don't you think that would be needed/useful?
 * What exactly is the <UserType> element used for?
 * References: You need to split the references into normative and 
informative references.
   At least the following references are hopefully informative -- 
otherwise we run into problems:
    - [CAP]
    - [OATH]
    - [OATHRefArch]
    - [OCRA]
    - [Schneier]
   Please double-check the other references.
   The reference style is also a bit strange (see, for example, the 
[DSKPP] reference).
   Are you using XML2RFC to edit the document?
   
Ciao
Hannes


_______________________________________________
KEYPROV mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/keyprov