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

From: "Jim Schaad" <[email-masked]>
Date: Fri, 15 Feb 2013 17:14:51 -0800

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. 

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

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

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

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.

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

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

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?

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?

Jim

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 19 Feb 2013 15:32:04 +0000

Thanks very much for the comments, Jim.

> 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?

> and lengthen it a bit to justify why it is being done.

Will add in next revision.

> (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.

> What input limits are we talking about here?

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

> 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.

> are asking IANA to register things into.

Will add in next revision.

> requirements in section 8.1?

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

> 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.

> 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 < [email-masked] >
Cisco Systems, Inc.