Subject: [KEYPROV] Keyprov Draft Review by Niklas Neumann

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 30 Jun 2007 17:02:53 +0200

I got the following draft review comments from Niklas Neumann.
My forward to the mailing list...

------------------

Short Review of Keyprov Draft

1.3.6. A user renews its symmetric key with the same key ID

    * What is a Key ID in this context? 

1.4.1. Mandatory Requirements

    * Section is called mandatory requirements but only lists recommended 
requirements. 

3.3.1. Four-pass DSKPP

    * Item e: I don't understand why there would be any use of including the 
DSKPP Servers identity at this point. Shouldn't the identity be clear in the 
beginning? 

3.3.2. Two-pass DSKPP

    * "Note that the DSKPP "trigger" message MAY be used to trigger the 
client's sending of the <ClientHello> message.": Isn't that somewhat 
self-explanatory? What else would the DSKPP trigger be doing than to trigger 
the DSKPP Protocol? 

3.10.7. The StatusCode Type

    * "NoSupportedKeyTypes" and following items: "Note that the error will 
only occur if ..." is tautologous to the previous explanation in the same 
paragraph. 

3.10.12. The ProtocolVariantsType and the TwoPassSupportType Types

    * "Because 1-pass DSKPP does include a client request to the server, the 
ProtocolVariantsType type MAY NOT be used to indicate support for 1-pass 
DSKPP.": Should mean "Because 1-pass DSKPP does *not!* ....". Also since the 
ProtocolVariantsType type does not include an element to indicate support for 
1-pass DSKPP it actually isn't an option which MAY be used. On a side note: 
wouldn't it make sense to allow the client to indicate that it supports 
1-pass DSKPP support? Maybe the server can remember the option and use 1-pass 
DSKPP in the future with this client. 

4.2.3. HTTP Headers

    * "There are no other restrictions on HTTP headers, ...": Maybe change it 
to "... besides the requirement to set the Content-Type header value 
according to 4.2.2." to not have redundant information at different locations 
inside the document. Applies to 4.2.7. as well. EDIT: Not sure about this 
anymore myself tbh. 

Overall Syntax and Semantics
The documents structure is clear and good to follow and except for some run-on 
sentences in the beginning it is coherent to read. I only have 1 minor 
remark:

Especially for me as a non-native English speaker the use of SHALL and SHOULD 
in the same document does regularly bring me some confusion. While SHOULD 
indicates a recommendation, SHALL expresses a requirement. I'd therefore 
prefer the use of the word MUST instead of the word SHALL. This maybe only a 
personal issue though :)

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