jose open issue discussion
Skip this Video
Download Presentation
JOSE Open Issue Discussion

Loading in 2 Seconds...

play fullscreen
1 / 15

JOSE Open Issue Discussion - PowerPoint PPT Presentation

  • Uploaded on

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 the change If you care and don’t understand or don’t like the statement vote here

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' JOSE Open Issue Discussion' - tierra

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
  • 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
non aead algorithm as single name
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
add new ecb key wrap function
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
add key wrap functionality for ec
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)
remove no key wrap for ka algs
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
add other than pre shared mac key
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
add key usage both
Add Key Usage “both”
  • Do we need to add the string “both” as a key usage
  • Pro
    • Makes usage explicit
  • Con
    • Implicit by omission
support multiple types for algorithms
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
rsa oaep rsa pss default parameters
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
nist kdf elements
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
nonce timestamp parameter
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
json parsing issues
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
criticality of understanding header fields
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
is kid sufficiently defined
Is KID sufficiently defined?
  • Is the current text for KID sufficiently defined and understood?