Presentation on theme: "JOSE Open Issue Discussion Chairs Jim Schaad. Process Room vote for Closure – Three Choices for topics We adopt the change We reject the change We discuss."— Presentation transcript:

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

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

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

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?