The JOSE working group met on 1 August 2012 from 9:00 to 11:30. The meeting started with an anouncement that Karen O'Donoghue will replace Tony Hansen as co-chair of the working group. This was followed by Jim Schaad presenting an overview of the current status of the working group. Mike Jones gave a presentation on the current status of the working group documents. He expressed the opinion that the documents are currently very stable with only a few remaining issues that need to be resolved before they can progress. Richard Barnes expressed disagreement over the current level of stability on the documents stating that there has been significan discussion on many issues and suggesting that we should start using the tracker to have better management of the open issues. Joe Hildebrand wanted to know more about the complexity of the current implementations from the specfications. Mike responded that the signature and key specification implementations are trivial while the encryption specification does have some branching points that need to be taken into consideration. David McGrew then presented on a proposed combined hashing and encrypting authenticated encryption algorithm. There was a discussion on the differences between using and not using a Key Derivation Function (KDF) to expand a smaller key as oppose to transporting a larger key. The document he presented is still a draft and has not yet progressed to RFC status. Erik Rescorla wanted to know how integrity-only modes were defined in this scheme and was told that this is currently handled via the signature specification and not the encryption specification. Mike Jones then gave a presentation on the proposed JSON serialization documents to support multiple recipients. Joe said that he sees potential problems with doing the association by indexing into multiple arrays and suggested that a more tightly coupled method of associating the data be looked at. Richard Barnes argued that the documents are currently presented do not really solve the necessary problems and the group needs to re-consider the contents of these documents and see if it influences the base specifications. The chairs then asked for a show of hands for adopting the documents as working group documents as requested. The results in the rooms was 7 for and 3 against. This will be taken to the list for further discussions. Richard Barnes then talked about the Uses Case document. There are some additional groups that are looking at potentially using the JOSE work in other groups such as MILE. There was a discussion on how much there are limits on the length of JWT tokens in some of there use cases as part of URLs with Microsoft IE being cited as one example where there is a length limitation still. The current state of progression of the Use Case document as a working group document is still up in the air. Richard then presented an alternative serialization document. This document is far more JSON based in the presentation of the structures. Richard argues that there is much less need for doing integrity protection on the headers than is currently believed and that removing it would ease problems of doing multiple recipients as recipient specific data would not need to be protected. This was followed by a discussion of the integrity protection that is available in a variety of different protocols. The discussion ended with Richard stating that he will make more specific suggestions to the list. The chairs then when through a list of current open issues on the documents looking to try and get closure on them. The format of the discussion was to go through each of the issues and take a fast poll followed by going back to some issues for expanded discussions. Results of the fast poll were * Non AEAD algorithm as a single name - 12 yes, 2 no 0 discuss * Add new ECB key wrap functionality - 2 yes, 5 no, 5 discuss * Add key wrap functionality for EC - 12 yes, 1 no, 1 discuss * Remove no key wrap for Key agree algorithms - 1 yes, 6 no, 0 discuss * Add other than pre-shared MAC key - 3 yes, 5 no, 3 discuss * Add Key Usage "both" - 1 yes, 11 no, 0 discuss * Support multiple types for algorithms (string and object) - 1 yes, 5 no, 4 discuss * RSA-OAEP/RSA-PSS uses other than SHA1 for internal structure - 0 yes, 5 no, 3 discuss * Add a nonce/timestamp Parameter - 6 yes, 0 no, 1 discuss * JSON Parsing issues - the question was deemed insufficiently clear for a vote * What criticality level should be used for header fields - 2 critical, 0 non-critical, 4 some critical, 3 discuss * Is KID sufficiently defined - 2 yes, 0 no, 1 discuss The group then discussed a number of the issues from above. Add new ECB key wrap functionality -- Mike Jones states that about 50% of systems currently don't support AES key wrap and therefore ECB should be supported. Jim Schaad said that he has discussed this issue with Tom Polk and it is unclear if NIST would be happy with a situation where no integrity was provided on the key wrap. Dave McGrew pointed out that ECB would not be usable for key sizes greater than one block length so that an AES key wrap would be required in any event. On repeating the poll the results were 2 yes, 10 no, 0 discuss. Add other than pre-shared MAC key -- Mike Jones points out that there are no fields to do this and we should not add the feature unless there are known use cases for this. Jim Schaad (individual) expressed concern about how often the MAC key is rolled over, over use of a key will lead to security problems. Richard points out that if we change the structure then this becomes a trivial addition. Repeating the poll yielded 4 yes, 3 no, 0 discuss. Mike Jones said that we could potentially support this in JWE with a null encryption algorithm. Paul Leach said that you are going to want an integrity only algorithm sooner or later. Criticality of understanding header fields - Joe said that he was a yes, but moving to maybe - it might be better to add a non-critical than critical by default, perhaps criticality should be context-sensitive. Mike Jones stated that implementers are hurt by "maybe", but acknowledged that it might be needed for extensibility. There was then a long discussion on where criticality should be specified and what it has done in some other protocols, most notability X.509. The re-poll yielded 5 yes, 1 no, 7 maybe, 0 discuss.l Matt Miller then presented what he is doing in the XMPP context for end-to-end work. Matt raised the issue of using base64URL vs base64 in many locations. The XMPP documents uses the non-URL version and there may be resistance to adopting the URL safe version in some cases. It was pointed out that most decoders can do both ways without any problems. Mike Jones then presented a chart with the results of an implementation survey of the different cryptographic algorithms.