Re: [jose] Comments on draft-miller-jose-jwe-protected-jwk-00

["Matt Miller (mamille2)" <[e-mail]>]

Thanks very much for the comments, Jim.


On Feb 15, 2013, at 6:14 PM, Jim Schaad <[e-mail]> wrote:

> Matt,
> 
> 
> 
> Here are some comments to be considered.
> 
> 
> 
> 1.        There is the possibility of confusion in the first sentence of the
> introduction about the transport of symmetric keys.  One place where one
> transports symmetric keys but not in this method is in JWE itself.  I think
> that it would make more sense to talk about transporting private key
> information and define that as including both the private portion of an
> asymmetric key as well as a binary value that can be used either as a
> symmetric key or a MAC key.  This draft would be used when that is the
> primary aim of what is happening, but the necessary security properties
> might not be provided by the methods of transport used. 
> 

Will change for next revision.  Also, should I change "symmetric key" to "shared secret" in said definition?

> 2.       Make the paragraph on defining a password based algorithm separate
> and lengthen it a bit to justify why it is being done.
> 

Will add in next revision.

> 3.       JSON is not a well-known TLA - it needs to be expanded on first use
> (including in the title).
> 

I guess I didn't think it necessary since I've seen a number of drafts recently omit it; the next revision will include JSON expanded.

> 4.       I don't understand the end of the sentence in section 3.2, para 2.
> What input limits are we talking about here?
> 

Here, "inputs limits" means "plaintext length limit".  Will rephrase in next revision.


> 5.       I would suggest adding an optional "hint" parameter to PBKDF2 which
> can contain a hint for the user about what the password is.
> 
> 6.       Suggested/mandated seed and iteration lengths should be in section
> 6.1.1 and 6.1.2 respectively and not in the security considerations (if you
> want you can duplicate).  These should be where people are going to see them
> and remember them and not in a section that they might or might not read.
> 

I went back and forth on that myself.  I'll move to 6.1.x in next revision.

> 7.       You should have text in the section to state the registry that you
> are asking IANA to register things into.
> 

Will add in next revision.

> 8.       What steps should I as a programmer take to enforce the protocol
> requirements in section 8.1?
> 

Good point; this isn't realistically enforceable as written.  I'll try to come up with some alternative text.


> 9.       Section 8.2 - That is nice, why is it a security consideration?
> What actions should I be taking as a programmer to deal with this?
> 

This seemed similar to a concern in XMPP-E2E about offline messages, and so seemed appropriate to add here also.  I will try to come up with some suggested actions one might take. Alternatively, I can remove it if there's consensus this is not a worthwhile concern.

> 10.   Section 8.3 - I can understand why there is a recommendation of being
> bigger than the derived key length, but you should have some justification
> pointer for being smaller than the PRF block size.  What is the effect of
> this being ideal vs RECOMMENDED?
> 

There is text in RFC 2898 that I can incorporate here.  I can also change to the more normative RECOMMENDED.


Thanks again,


- m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.