Minutes for JOSE at interim-2013-jose-1

Meeting Minutes Javascript Object Signing and Encryption (jose) WG
Title Minutes for JOSE at interim-2013-jose-1
State Active
Other versions plain text
Last updated 2013-05-13

Meeting Minutes

JOSE WG Interim Meeting, April 29-30


In Person
Jim Schaad                      Matt Miller                     John Bradley
Brian Campbell                  Sean Turner                     Richard Barnes
Joe Hildebrand                  Mike Jones                      Karen O'Donoghue
Peter Saint-Andre

Pete Resnick                    Hannes Tschofenig               Prateek Mishra
Stephen Farrell                 Tina Tsou                       Eric Rescola

** Agenda Bashing, Blue Sheets, Note Well

The chairs proposed swapping some of the Monday morning and afternoon agenda
items so that it would be possible to coordinate with David McGrew if he can
get free on the feedback from the CFRG questions.  Those items that directly
related to these questions would then be addressed fallowing his call in.  No
objections were registered.

** Charter Discussions - Sean Turner

Sean shared the current state of the charter update with the group.  While
number of changes, such as removal of the number on the deliverables, has been
done to address comments from the IESG and others, Pete has placed a block on
the current updates to the charter until one more issue has been addressed. 
Specifically he wants a clear pointer to something that says "This is the JSON
object that contains the equivalent to an ASN.1 document".  The problem is that
the charter does not make it clear that what is being produced is a JSON
document rather than something else.

Mike expressed a concern that the charter not be modified so that the
compressed serialization of the formats not be removed from the current set of
WG outputs.

At the end of the discussion, Sean stated that he felt better about
understanding what changes need to be made and he would attempt to meet with
the chairs and get the necessary updates done for the charter update.  The
discussion of milestones and milestone dates was deferred until the end of the

** Issues dealing with the use case document

Richard stated that he thought for the most part the document was finished.  He
had received one use case that needed to be added to the document and needed to
address the review from Mike that had been posted, neither of which he had
looked at yet.  Hannes expressed a worry that some of the use cases in the
document, such as the emergency alerting case, were no longer viable as the
groups had either died or moved on since the document was started.

Hannes also expressed a worry that the use case document did not adequately
address the multiple wrapping use case.  Hannes agreed that he would send some
text to Richard so that this use case can be incorporated into the current

The chairs stated that they would like to start a WGLC on this document as soon
as possible.  Doing so will address one of the questions that had been raised
by Pete dealing with how usable the output of the group is going to be to the
application space.  Doing the IETF last call would address this issue.

It was decided that Richard would undertake to provide an updated version of
the Use Case document before 1 June at which time the chairs would do a review
and start the WGLC with an aim to start IETF last call around the 1 July.

**  Open Issues

The set of open issues in the data tracker was then used as a guidance for
discussions which followed.

**  Issue #6 - Unclear requirement levels on fields

Mike stated that he believed that the current draft of the documents addressed
all of the elements of this issue.  Richard however was not positive that it
had been fully addressed.  Specifically, there were questions about the
position of some of the elements (i.e., should partyUinfo be in the JWA
document) and if the appropriate requirements for each algorithm were correctly
stated (which algorithms require that the partyUinfo member be present).

Richard agreed that he would build a table of all of the algorithms and what
fields need to be present in the header when these algorithms are used.  He
would then share the table and also use the table to do a review of the
document to ensure that this issue has been fully addressed.

**  Issue #9 Add "spi" field
**  Issue #15 At least one key indicator should be mandatory

The two issues together were introduced by the chairs.  Discussions started
with spi.

Richard re-introduced the reasons for having an spi member - that one can have
a number of parameters pre-negotiated and refer to that set of parameters by
the use of the spi member.

In the discussion that followed, it was pointed out that there were three basic
types of negotiation that can occur: - Negotiation of capabilities prior to
sending the message so that both sides will use algorithms that are commonly
supported.  This may be fixed by the protocol or part of the protocol being
used.  This is the case addressed by spi allowing the negotiation to be cached
over multiple invocations. - The use of items transported as part of the
message for identification of keys.  This is what is being done for the OAuth
case where the issuer and audience fields are used to identify which key is
being used. - The definition of a key based on the protocol itself.  An example
of this given was the use of the TLS key extraction process to have a shared
key to be used that is implicitly identified by the protocol.

Next following a discussion about the question of complexity of the solution
with a question of how much space would generally be saved.  As part of this
discussion was the question could the spi proposal be done completely
independently of the base specifications with Mike arguing that this might be
the best option.

Hannes wanted to know what the difference was between using an spi and a kid. 
The response was that if one is only looking at identifying pre-negotiated keys
and not the other algorithm parameters then none.

There was some agreement in the room that it would be ok to allow for
pre-negotiation of keys but not other parameters.

At this point the discussion started focusing in on the question of which key
identifiers need to be present in a message.

There was a discussion on how OAuth is currently identifying keys and Mike
brought up the case of Mozzilla Persona.  In both of these cases there are only
two parties that are sharing keys.  In Persona the key is shared earlier in the
protocol and in OAuth the key is identified by fields in the JWT content.  Part
of the discussion revolved around copying that information up in to the header
for the OAuth case and perhaps using a dummy value for the Persona case.  It
was noted that in the case of OAuth this is part of the reason that there is a
move to clone fields into the header for the decryption case, so that the OAuth
receiver can identify where a message came from in order to identify the key to
use for decryption.

There then followed a discussion on how a JOSE library would be implemented to
handle the cases of finding keys both in general and when the key
identification information was absent.  It was noted by Mike that even if the
kid field was present, this along is not sufficient to identify which key is
being used without knowing what database of keys was being searched.  It was
noted that the code to find the key is therefore going to be app specific more
often than not anyway.

There was a discussion of the possible security implications of not having key
id information or having the wrong one.  In general this is not an issue as the
validation or decryption process would just fail.

At this point Richard put forth a proposal that we say the following:

The sender SHOULD include a key identifier, unless there is a pre-negotiated
key by convention. Recipients MUST fail if there is no key identifier and no
externally provided key.

Additionally, as previously agreed, Mike is going to change some of the
examples to have kid values in them so it will be recognized that this is
something that is a usual case.

There was general agreement that this would be the path forward.

Issue #9, by agreement, will be closed as won't fix in the base drafts.  If can
be done later in a new draft if there is a need for it.

**  Issue #11 - Use RFC 5116 and remove MAC field

Mike argued that keeping the fields separate is a better policy than combining
them together as this is the normal method that most of the cryptographic
libraries are currently using today.  Doing what they are doing is more natural
than forcing the libraries to combine and then break them apart again later.

Richard then made the argument that the RFC 5116 argument that this can be
treated as an opaque blob makes as much sense, allowing the underlying
libraries to take care of the problem.  What is reflected in and out can be
thought of as opaque.

Jim brought up the issue of SIV (Synthetic Initialization Vector) mode, where
the IV is the authentication tag and is computed by the algorithm itself.

In the end it was decided to be left as an issue for the definer of the
algorithm and that the document would be modified to keep the MAC and IV
fields, but to allow the fields to be empty values.

**  Issue # 7 - Algorithm identifiers/parameters incompatible with WebCrypto

Richard gave a summary of the state of algorithm names in the WebCrypto group
after the face-to-face meeting last week.  Following that it was decided that
we really needed to keep the issue open until the WebCrypto group had finalized
what it was going to do with small names.

Richard then asked to re-visit the question of allowing for more complex
structures as algorithm identifiers.  John lead the argument against doing this
as having the composite names allows both for a restriction of options and for
some degree of adult oversight on the registration of new algorithm identifiers
and combinations.

There was no strong desire in the room to do anything other keep the current
set of string identifiers for algorithm identifiers.  However it was decided
that the issue should be kept open until the WebCrypto group has finished
dealing with their short string names to make sure that what they do matches
what we do.  If there is a difference, the item will be revisited then.

** Dealing with the multiple signer/recipient JSON structure case

Richard presented his slides from the presentation JOSE Header Integrity
Options.  Some sections at the end were omitted from the verbal presentation.

Hannes wanted to know what the advantages are to preventing incremental
addition of recipients.  The response was that it prevents forwarding to a new
recipient without doing a re-encrypt operation, but this is a by-product of the
current implementation and not a design goal that was trying to be satisfied.

Pete wanted to know if there are things that need to be protected beyond the
algorithm. The room resounded with a yes.

The group then had a discussion on the merits of the two proposals that were
proposed by Richard.  EKR said that option #1 is inconvenient if you don't want
it but good the rest of the time.  Option #2 is more convenient and flexible
and he was not overly worried about the implementation costs.

Mike was far more worried about the developer issues.  There was the ability to
have fields in two locations that need to be merged and rules need to be
specified for how to do the merging.

Richard pointed out that this was a more JSON looking structure which would
probably placate those worried about the issue.  It would be possible to design
this in such a way that the serialization from the JSON structure to the
compact structure would be able to be done mechanically.

Pete expressed issues the amount of base64 encoding and worried that it was
going to be PITA.  Mike said that the amount was minimized - but it is used
where needed to fix the serialization of items so that it will consistently

A brief discussion was held on the ability to not base64 the content.  With Jim
pointing out that it is needed for the detached content case in signatures (the
ALTO use case).  This was not deemed to be an immediate issue by the group.

It was then questions how to do the same type of thing for signatures.  Richard
when to the white board to provide the following example.

    data: "...",
    signatures: {
            jwk: "...",
            sig: "...",
            signed_attributes: base64({"alg":"PSS+SHA256"})

The mechanical conversion from the above structure to the compact notation was
then discussed.

It was the basic sense of the room that we should adopt proposal #2 as the path
going forward.

The chairs then asked Mike to do a write up of the discussion and send it to
the participants so that we could validate that it matched our discussions.  He
said he would try to do it before tomorrow.

** CFRG feedback

Jim gave a summary of the feedback that we have received from the questions
that were asked of the CFRG.  We asked four questions and have received no
input on the two questions dealing with protection requirements for key
management and content encryption algorithms.

The information we have recived is that RSA-PSS needs to have a consistant hash
algorithm to truely prevent hash substitution attacks and there may be no way
to prevent them for ECDS.  Hashing the algorithm makes it more difficult for
secure hash algorithms.

It is good algorithm hygiene to keep the key wrapping and data wrapping
algorithms as sepearted as possible.

PBKDF2 needs to have a good set of security requirements associated with it so
that it remains strong.

Shared secrets need to have good hygiene and be rolled over at regular

Based on the discussions, the following items were looked at.  We need to
review the current set of security considerations in order to make sure that we
have covered all of the bases.

There was a discussion about adding RSA-PSS into the base specification.  At
this time it is not present, however there was a strong desire in the room to
add it to the current set of JOSE algorithms.  In doing so however, it was
decided that it needed to be done correctly rather than in a way which will
work with todays implementations.  This means that when the hash algorithm is
defined, it will be the same hash algorithm in all three locations (content
hash, filler hash and in mgf1).

The conversation then started on the question of the use of direct for HMAC. 
The discussion was put on hold until the second day.

**  Issue #12 - Corrected Language to deal with this issue

Brian noted that the this issue was originally opened to deal with a question
of language on recipient vs sender for certificate,  The issue of x5c was then
expanded from this.

Mike has noted that he believes that the language issues have been dealt with
in the latest draft.  Brian will review the new text and see if it addresses
his issues there.  Nothing is going to be done about removing x5c in this
context .

**  Issue #8 - No security analysis problems

This issue was looking at the question, is there a security issue that has not
been addressed by allowing for the case of key agree to directly produce a
content encryption key rather than using an independently generated CEK and
wrapping that with a key derived from the key agreement operation.

Jim state that he did no believe that there was any issue that he knew of from
a security point of view.  The major one would be an issue of making sure that
there was always a random component in the key agreement operation either from
a truly ephemeral key, or from the use of the paryUinfo field.

John wanted to know what the demand for this mode was as he did not see a large
savings in bytes by using it.

The chairs took an action to query the list for use cases where the direct mode
is required and the key wrap mode cannot be used.

** Issue #? - URI Fragment

James Manger has presented a case and a solution for having the JOSE group
define a URI fragment for use with JWK sets.  The group discussed the solution
presented and did not find a real strong case.  However in response Mike is
going to add additional text on the use of the kid field for disambiguation
when using a key set referenced from the jku member.

One of the issues that come up was the question of having a single kid value
for two keys which had different use member values.  It was decided that this
should not be allowed by the specification.

** Issue #17

Issue should be closed

**  Crit Text

Two questions were raised for dealing with the cirt field.  Does the crit field
need to be signed and do the members listed in the crit field need to be signed.

There was no consensus in the group at this time as we adjourned for the day

****************  Tuesday

Richard attempted to make an argument that the crit structure is not a
necessary component to the base specification.  It has nothing to with the
cryptographic functions that are the core to the JSON structures.  This field
only deals with non-cryptographic function verifications.

Mike and John both pushed back on this citing cases where, which it is
non-cryptographic, such validation needs to be done.  This was supported by the
use of the EKR expire time member.

Richard then made an argument that crit should be moved into a separate
specification.  However this was not deemed to be a good fit as then crit could
not be relied on to exist in base specifications.

Joe at this point argued that we need to have a solid use case that people can
see and implement using the base specification as many implementers do just the
minimal needed to get a specification running and then ignore the rest of

After the meeting, there was an agreement that this would be addressed by
adding some test cases that use the crit field.

An additional argument was raised about the MUST NOT that currently exists
regarding the presence of base specification fields in the crit member.  That
is should "crit":{"alg"} be a cause for a message to be rejected as invalid. 
No suitable compromise was arrived at during the meeting although a suggestion
of MUST NOT on the sender and allow the recipient was suggested.

**  Key Wrapping issues

Richard gave his second presentation at this point.  As part of the
presentation Richard said that one could not use AES-GCM as a key wrap
algorithm in JSON.  Mike disputed this saying this would be done by the
definition of a new algorithm with appropriate fields.  Richard responded
saying that this would need to be done for any new AEAD algorithm, and the room
agreed with some saying it was a good thing.

What followed then was a large discussion about the question of what it means
to say that different algorithms should be used in different locations in the
specification to separate the handling of data content from keys.  One of the
questions was if it was sufficient to allow for the same cryptographic
algorithm, but with different identifiers so that the code could distinguish
based on the identifier what the content was going to be.

Mike then made an attempt to separate the different types of wrapped keys.  He
divided things between ephemeral wrapped CEKs, which are used in a particular
wrapping, and encrypted keys designed to be used in a different content.  The
latter needing to have attributes about the key.

The final outcome of the discussions was as follows:

Richard is going to update his key wrap draft based on the input provided
Mike will provide a new draft showing how to define and use AEAD algorithms for
key wrapping purposes. When that is complete the chairs will evaluate the
drafts fro completeness and then request a discussion from the list.

** PKIX wrapping

Matt and Brian then talked about the desire to have certificates stored in JWK
structures.  There are two known use cases as this time, the first is to
associate keys with https and the second is some OpenId key management methods.

There was then a long discussion on the correct way to include x5c in a JWK
structure.  Should it be a separate key, with potentially the same kid value,
or should it be included with a JWK that contains the public key.  The former
is consistent with saying it is a different key, the later is consistent with
saying that it is jut a different representation of the same key.

It was generally agreed that this should be treated as a different
representation, but then questions arose about mixing and matching the fields
that were in the certificate with equivalent fields in the key representation.
(I.e., taking the key from the n/e fields, but using the name from the
certificate.)  After extensive discussions the following language was agreed
to.  If the certificate is used, then the certificate MUST be used for all
fields in the certificate.  Other fields in the JWK MAY be used iff there is
not equivalent data in the certificate.  The creator of a JWK structure MUST
ensure that the data in the certificate and the data in the JWK structure are
consistent with each other.

Finally, it was decided that one could place an x5u or an x5t in the key field.
 If these are present, then they would be treated as indirections to the
certificate itself.

**  Round two of the JWE structure

The group then re-visited the JWE structure discussions from the previous day
looking at the e-mail that Mike sent out to the attendees.  It was determined
that what was in the mail did not quite match what was discussed the previous
day.  After some argument, there was consensus on what the structure should
look like both for the case of doing a single recipient compressed
serialization and a single/multiple recipient JSON serialization.  The
documents will be updated to reflect the final consensus.  The  text file that
we used for arriving at the consensus is posted as part of the meeting

We agreed that for the compact serializations (which only support a single
recipient or signer), we will continue to require that all header fields be
integrity protected.

** HMAC syntax question

The group then revisited the question of allowing for doing key derivation with
MAC keys from the previous day.  There was a feeling that there would be an
improved level of security if one could derive a new key from the shared secret
rather than using it directly.  The question then was did this require that we
do the full set of key management from the JWE module, or could we do it in a
simpler way.

John suggested that one could define a new algorithm that was of the form
HMAC+KDF.  This would allow one to run a KDF on the shared secret, with the
appropriate parameter, and then run the HMAC function using the output of the
KDF.  This would be a way to address the problem of having many messages sent
using a single shared secret and still derive a new ephemeral key for each of
the messages sent.

The group did not decide that it needed to be added as a new algorithm at this
time, but left the possibility open for later.

**  Future

There is an intention to have a teleconference call in the middle of June. 
Details will come around the end of the month.


Hannes - Provide use case text to Richard dealing with multiple wrapping use
case Richard - Publish an update to the Use Case document before 1 June Richard
- Create algorithm table reflecting member requirement levels before 1 June
Mike - Add RSA-PSS to the set of algorithms Chairs - query list about key agree
direct. Mike - Add text dealing with key identifiers (based on richard supplied
text in meeting) - addressing issue # 15 Chairs - Close Issue #9 Mike - add
text dealing with empty IV and authentication tag fields - Issue #11 Chairs -
Update state of Issue # 7 to reflect that this is a watch item not an active
item Mike - Add RSA-PSS to the list of algorithms with consistant hash
throughout Brian - Verify tht Issue #12 has been dealt with in the new update
(DONE) Chairs - Query the list to see what use exists for key agree direct vs
key agree with key wrapping - Issue #8
       - by end of week
Chairs - URI Fragment - Close Issue #16 as won't fix
Mike - Add text on using kid as disambuation - include text for JWKs on when
kid must be present Chairs - Close Issue #17 to match list discussion Richard -
Add evaluation for protection to table of all all fields being made above
Richard update key wrap draft - May 10thn Mike - key wrap draft for
AES-GCM-keywrap - May 15th Chairs - evalute and the query list for opinions -
post drafts exist