[jose] Collated Responses to April 11, 2013 JOSE Questions

[Mike Jones <[e-mail]>]

So that it will be easy for us to use to the data gathered in response to questions that Karen sent to the working group on April 11, 2013 during the interim meeting next week, I took a stab at collating all the responses and extracting the additional proposals and comments made.  What follows is a reporting of the data from the responses sent - with no conclusions drawn.

If any of you believe that I incorrectly or incompletely captured your responses, please reply and I'll correct the spreadsheet accordingly, ideally in time for the working group meetings on Monday and Tuesday.

I'll look forward to seeing many of you next week!

                                                            -- Mike

Collated Responses to April 11, 2013 JOSE Questions


#7 - Alg IDs

Tally

Response


17

1.  Continue have the JWA algorithm identifiers be strings, and not objects.


1

2.  Switch to using the algorithm identifier structures defined in the WebCrypto draft.


0

3.  Another resolution (please specify in detail).


0

0.  I need more information to decide.

#8 - spi


14

1.  Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations.


0.5

2.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory feature.


1.5

3.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature.


1

4.  Another resolution (please specify in detail).


0

0.  I need more information to decide.

#11 - 5116


14

1.  Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.


3

2.  Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three values.


1

3.  Another resolution (please specify in detail).


0

0.  I need more information to decide.

#12 - x5c


9

1.  Retain the "x5c" header parameter in JWE.


3

2.  Remove the "x5c" header parameter (and possibly other related key specification parameters) from JWE.


0

3.  Another resolution (please specify in detail).


0

0.  I need more information to decide.


2

Don't care

#15 - Key ID


19

1.  Yes - Use cases where key information is exchanged by means other than the JWS or JWE headers are important.


0

2.  No - Use cases where key information is exchanged by means other than the JWS or JWE headers are not important.


0

0.  I need more information to decide.


1

Other


Individual Responses



#7 - Alg IDs

#8 - spi

#11 - 5116

#12 - x5c

#15 - Key ID

Dick Hardt

1

3

1

1A

James Manger

1b

2b

1A

Axel Nennker

1

1

1

1

1A

Roland Hedberg

1

1

1

1

1

Hideki Nara

1

1

1

1

1

Mike Jones

1

1

1

1

1

Richard Barnes

2b

2 or 3

3

Don't care

Other

Nov Matake

1

1

1

Don't care

1

Anthony Nadalin

1

1

1

1

1

Matias Woloski

1

1

1

1

Breno de Medeiros

1

Edmund Jay

1

1

1

1

1

John Bradley

1

1

1

1

Matt Miller

1

2

1*

Justin Richer

2

Charles Marais

1

1

1

1

1

Sascha Preibisch

1

1

1

Javier Rojas Blum

1

1

1

2

1

Nat Sakimura

1

1

1

Vladimir Dzhuvinov

1

1

1

0

1*

Russ Housley

4

2

Michael Peck

2

Salvatore D'Agostino

1

1

1

1


Additional Proposals and Comments


#7 - Alg IDs

Richard Barnes

2b - Switch to a structure more like the WebCrypto structure, in which algorithm parameters are collected alongside the algorithm name


#8 - spi

James Manger

1b - Have "spi" as a separate (optional) spec.  Change its definition so it does not change the crypto.

Russ Housley

4 - Combination of 1 and 2.  The field needs to be in the base specifications, but the only rule that needs to be included in the base specification is an exact match of the identifier.


#11 - 5116

James Manger

2b - Switch to using RFC 5116.  A JWE should have separate nonce and ciphertext fields (but no separate integrity value field).

Richard Barnes

3 - RFC 5116 doesn't do anything with IVs, and all libraries I know of have a separate IV and cipher text fields.  So we let's keep those separate.

John Bradley

1 ish - in favour of the current serialization while wanting to support the crypto from  draft-mcgrew-aead-aes-cbc-hmac-sha2


#12 - x5c

Matt Miller

I personally would rather limit key indication to a JWK (and wrapping "x5c" in a JWK), or a reference to a JWK ("kid", and maybe "jku")


#15 - Key ID

Dick Hardt

1A -  a key indicator SHOULD be included. (not a MUST)

James Manger

1A - A key indication SHOULD be included (and certainly must be present in all the examples in the spec)

Axel Nennker

1A - A key indicator SHOULD  be included but can be omitted because use cases where key information is exchanged by means other than the JWS or JWE headers are important.

Richard Barnes

Other - there needs to be a "pre-negotiated mode" in which headers are not mandatory in addition to the "stand-alone mode" where everything needs to be expressed in the headers

Matt Miller

1* - while I do think that key information exchanges outside of the JWE/JWS headers are important, I do think a reference to the resultant key is mandatory

Vladimir Dzhuvinov

1* - No key indicator should be mandatory. The app / higher-level protocols should decide on that.