Discussion on Proposed Changes to Algorithm Specifications in .JOSE

1. JOSE Open Issue Discussion Chairs Jim Schaad

2. Process • Room vote for Closure • Three Choices for topics • We adopt the change • We reject the change • We discuss the change • If you care and don’t understand or don’t like the statement vote here • After all voting is done, a Short Discussion on each topic with a significant discuss vote followed by second poll

3. Non AEAD algorithm as single name • Change current treatment of AES-CBC + HMAC to use a single content encryption name • OLD: {“enc”:”A128CBC”,”int”:”HS256”,”kdf”:”CS256”} • NEW: {“enc”:”A128CBC+HS256+CS256”} • PRO • Restricts combinations • Shorter Text • Con • Restricts Combinations

4. Add new ECB key wrap function • Add a new ECB key wrap function to the algorithm specification • Pro • Probably wider implemented than AES key wrap • Con • Does not have internal integrity protection • Security People will object

5. Add key wrap functionality for EC • Do we need to require the ability for doing Key Agree followed by Key Wrap to get the CMK? • Pro • Required for a multiple recipient case • Con • Unnecessary for single recipient case (spec bloat)

6. Remove no key wrap for KA algs • Should we remove the ability to go directly from a Key Agreement algorithm to the CMK without a key wrap step • Pro • Saves space for single recipient case • Con • Two code paths – single vs multiple recipient cases

7. Add other than pre-shared MAC key • Should we add the ability to have a randomly generated MAC key protected by a different key. The other key could be either a pre-shared symmetric key or a public key. • Pro – Security issue based on number of key uses • Con – Not supported by current structure

8. Add Key Usage “both” • Do we need to add the string “both” as a key usage • Pro • Makes usage explicit • Con • Implicit by omission

9. Support multiple types for algorithms • Should support be mandated to allow an algorithm to be both a string and an object • Example: “alg”:{“name”:”RSA-OAEP”, “hash”:”S256”} • Pro • Puts parameters into non-global space • Con • Can be expressed in the text name

10. RSA-OAEP/RSA-PSS default parameters • Should SHA1 be the default parameters for these algorithms? • Pro • What is current deployed • Con • It is the only use of SHA-1 in the specification

11. NIST KDF elements • Do we need to add NIST recommended elements to the KDF algorithm defined. Elements would be Algorithm Identifier, Output Length and optional Party Info. • SETTLED – Will be done

12. Nonce/timestamp Parameter • Do we need to define a nonce/timestamp parameter in the base specification? • Pro • Likely to be commonly used • Con • Spec bloat

13. JSON Parsing Issues • Do we need to require additional JSON parsing restrictions beyond what exists today? • Excess characters before and after object • Possible problems with duplicate fields • Pro • Opens new attack surface • Con • Requires additional code by implementer

14. Criticality of understanding header fields • Different set of questions • YES – all header fields are critical • NO – all header fields are non-critical • MAYBE – header fields are marked as (non)-critical • DISCUSS – we need more discussion

15. Is KID sufficiently defined? • Is the current text for KID sufficiently defined and understood?