I would like to first note that the vast majority of the password-based text came from draft-miller-jose-jwe-protected-jwk (discussed a few times on this list), and was included between the end of the JOSE virtual interim (2013-07-15T17:00Z) and the submission deadline.
On Jul 15, 2013, at 7:13 PM, "Manger, James H" <[email protected]> wrote: > draft-ietf-jose-json-web-algorithms-13 adds password-based encryption > algorithms that involve a salt (s) and iteration count (c). I cannot quite > tell how s & c are conveyed. Section 4.9.1 "PBES2-HS256+A128KW" says s & c > come from the "applicable PBKDF2 JWK object". > > Is the "applicable PBKDF2 JWK object" the value of the "jwk" header parameter > in a JWE message? > Or is the "applicable PBKDF2 JWK object" part of each parties > locally-configured key set (which is not part of a message, but can be > referenced by a "kid" header parameter)? The "applicable PBKDF2 JWK object" is whichever of the key-identifying fields ("jwk", "jku", or "kid") works for your application. The intent of these algorithms is to protect private- or symmetric-key JWK objects, and to be as self-contained as possible, so the original examples used "jwk". When this was put together, using JWK objects seemed to make the most sense and fit the syntax and semantics. > > The latter makes little sense as salt and iteration count are parameters of a > particular message, not fixed for a given password. > Those are good points, and favor moving "c" and "s" from a JWK into the JWE header (as implicitly proposed elsewhere in this thread). See above for the original rationale. > The former is at best underspecified. "jwk" is defined as "the public key to > which the JWE was encrypted" > [http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#section-4.1.5]. > s & c obviously are not a public key so that definition would need to change. > > A PBKDF2 JWK object is also defined to have a 'hint' parameter ("a > descriptive clue to the password"). It would be awful if 'hint's were sent in > JOSE messages. JWK needs to do a much better job of separating sensitive > fields (secret key, private key, password hint) from public fields. If we > need text to display when prompting for a password I think we need a > different field to 'hint'. > Do you have suggested changes/replacements. > An example of PBES2-HS256+A128KW would help. > I'll let Mike Jones speak to this revision specifically. An example does exist in the original draft-miller-jose-jwe-protected-jwk. - m&m Matt Miller < [email protected] > Cisco Systems, Inc.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
