Jose open issue discussion
This presentation is the property of its rightful owner.
Sponsored Links
1 / 15

JOSE Open Issue Discussion PowerPoint PPT Presentation


  • 78 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

JOSE Open Issue Discussion

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


Jose open issue discussion

JOSE Open Issue Discussion

Chairs

Jim Schaad


Process

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


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?


  • Login