Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00

[Russ Housley <[e-mail]>]

Jim:

Thanks for the careful review.  I just posted -01 to resolve your comments.

The biggest change is the addition of Section 5 on key derivation.

Russ


> On Nov 9, 2018, at 2:05 AM, Jim Schaad <[e-mail]> wrote:
> 
> Abstract:  Needs to be re-worded " if existing syntax the does not
> accommodated them."
> 
> Section 1: Needs to be re-worded "if current syntax the does not
> accommodated them."
> 
> Section 1: Needs to be re-worded: " by mixing with a strong PSK with the
> output"
> 
> Section 2 -  Which key? "generates the key"  Pushing something from the next
> two sentences forward would be useful.  Not talking about generating the
> ephemeral DH key.
> 
> Section 2 - you have not introduced the KDK yet and now I am creating one.
> Perhaps a simple discussion on how what happens is that an additional key
> wrap is inserted using ...
> 
> Section 2 - It would be nice to add a sentence where you say that you are
> introducing two new management techniques to say that they are agnostic
> towards the underlying key management technique.
> 
> Section 3 - I am wondering if it would make more sense to use the
> KEKIdentifier structure instead of just having an octet string for the
> PreSharedKeyIdentifier type?
> 
> Section 4 - This is twice that I have read this and am unclear what we are
> doing.  The sentence "private key and recipient's public key to generate a
> pairwise key"  From this and from information in my mind I am not completely
> clear that this is the DH pairwise key or something else.
> 
> Summary:  Is it your thought that I should be able to implement this
> document as written?  A the moment I do not believe that this is possible.
> Do we need to define how the KDF function operates?
> 
> Jim
> 
> 
> 
> 
>