JOSE WG Interim Meeting, April 29-30 Attendees: In Person Jim Schaad Matt Miller John Bradley Brian Campbell Sean Turner Richard Barnes Joe Hildebrand Mike Jones Karen O'Donoghue Peter Saint-Andre Remote 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 meeting. ** 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 document. 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 hash. 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 intervals. 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 pieces. 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 materials. 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. ****************** ACTION LIST: 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