Subject: RE: [KEYPROV] Keyprov Draft Review by Niklas Neumann

From: "Doherty, Andrea" <[email-masked]>
Date: Wed, 4 Jul 2007 16:06:32 -0400

Niklas,
Thanks for your comments.   Please see responses below.
Andrea 

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Saturday, June 30, 2007 11:03 AM
To: [email-masked]
Cc: Niklas Neumann
Subject: [KEYPROV] Keyprov Draft Review by Niklas Neumann

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? 

(adoherty)It is like a serial number for the key that is associated with
a user's account (or a GUID associated with a user's account).  The
"same key ID" refers to the ID associated with the old K_TOKEN that is
being renewed.

1.4.1. Mandatory Requirements

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

(adoherty)This will be corrected.

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? 

(adoherty)RFC4758 states that "The server's identity is an optional
identifier for the service that has stored the generated key.  The
cryptographic token may store this identifier associated with the key in
order to simplify later lookups."

(adoherty)Note that for the DSKPP draft, the server's identity is part
of the key container, no longer explicitly part of <ServerFinished>.
Hence, item (e) will be corrected to refer to the container, which might
include this type of information, such as specified in PSKC spec (ref
[7]).

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? 

(adoherty)Yes, you are right...perhaps the sentence should be rephrased
to "the client's sending of the <ClientHello> message can be OPTIONALLY
triggered by the server if it first sends a DSKPP Initialization
message."

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. 

(adoherty)Yes, it is "redundant" and will be fixed ("tautologous"...I
had to look that one up :-) )

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. 

(adoherty)Good catch!

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. 

(adoherty)It seems more complete, to be sure.  For now, I'll add it
unless there are objections.

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. 

(adoherty)Good catch on the redundancies...these will be removed.

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 :)

(adoherty)I think this is a perfectly reasonable request!

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

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