JOSE Meeting for IETF 82 Meeting Occurred 14 Nov 2011 from 1pm - 3 pm Jim Schaad presented the Agenda. The meeting was designed to cover four documents, and review a list of requirements. Jim began the meeting by noting that the status has changed. This was the inaugural meeting of JOSE as an official IETF working group. Previously, this group met under various names as a BOF or bar BOF. Mike Jones to present three proposed JOSE documents: JWS, JWE, and JWK Mike described motivation: industry would be well served with a common set of simple formats for JSON-based security token, signed objects, encrypted objects, and public keys. The design philosophy emphasizes simplicity - the goal is widespread adoption. Some things are inherently complex; things with complexity need to be possible. The working group is looking to support "all modern web development environments". The ASN.1 based tools considered functionally acceptable, but too complex for deployment. A key design decision incorporated in the current drafts was "Compact, URL-safe representation". This decision reflects a need to restrict length since many browsers limit to 256(2048) characters, others are even more restrictive. Following the motivation, Mike provided background on how the three proposed documents evolved. This is not an entirely new idea: in fact, there were lots of different proposals. Mike decided to try and merge the various proposals to create a single consensus specification. This consensus draft was published December 2010. However, Eric Rescorla (ekr) and Joe Hildebrand were independently pursuing work in parallel. Mike, ekr, and Joe agreed at the Prague IETF to merge these documents. Subsequently, the JWK was published in April 2011, and JWE published Sept 2011. At this point, Peter St Andre asked about IETF IPR considerations. Specifically, Peter asked if the various contributors were aware of the IETF's IPR rules. Mike noted that all of the authors were aware that the goal was an IETF RFC, and there was no negative feedback. Some of these precursor specifications are already in use at some level. OpenID Connect is using the proposed IETF drafts as the basis for work, with at least seven different independent implementations. Mike walked the group through the key decisions in the three specifications proposed for WG adoption: In the JWS, the goal is to "sign" arbitrary content (true digital sigs and HMACs). Sean Turner noted a need to clarify language - HMACs are not digital signatures. Sean noted that documents describing HMACs as signatures are certain to run into trouble in the IESG, so fixing the terminology early makes sense. Mike described the three parts of the JWS format: header, payload, and signature. Each part is base6url encoded. Mike worked through examples of each part. The header is required to specify the type and algorithm. Mike observed that the core decision on the JWS payload was NO CANONICALIZATION. Canonicalization was biggest problem with XML digital signature specification, so the authors just decided not to include that feature. The JWS signature covers the concatenated header and payload separated by a period. The complete JWS is composed of the three base64url encoded components, concatenated with periods as separators. The JWS header has one required and 5 optional parameters ranging from X.509 to bare key. It specifies extremely compact algorithm identifier strings for HMAC, RSA and ECDSA with SHA-256, 384, and 512. The working group briefly discussed the document's representation of HMAC as a digital signature Hannes Tschoefenig asked if the algorithm information should be separated out of the JWS specification. Jim Schaad noted that the charter required two separate documents. Mike Jones indicated he would be happy to be editor for that specification and noted that the document under consideration was developed before the charter, and the content was the result of development process. Next, Mike described the JWE. The JWE is designed to encrypt arbitrary content. Like the JWS, the JWE has three parts: header, encrypted key, & ciphertext. As before, the JWE format is composed of the three base64url encoded and separated by a period. Steve Kent noted that the example works for RSA but might be insufficient for Diffie-Hellman, and asked if the header was extensible. Mike indicated that the intent was for the header to be extensible, but the full contents must be understood by recipient. That was likely to discourage adding options. Steve Kent asked if a version number was currently specified. Mike indicated not at this point. Sean Turner encouraged the working group to add a version number now, since the IESG will probably insist. If the working group decides against a version number, the document will need to explain why a version number is not needed. Jim Schaad indicated that he disliked version numbers in general. Paul Hoffman suggested that a compromise might be for version numbers on the fields rather than the structure. The JWE header has two required fields: the algorithm used to encrypt the key, and the algorithm used to encrypt the plaintext. Optional features include an initialization vector, ephemeral public key, compression algorithm, plus several fields that overlap with JWS optional header fields. Steve Kent noted that "ephemeral" applies to any form of DH. In the draft, "ephemeral" refers strictly to Elliptic Curve Diffie-Hellman. The current draft specifies 5 algorithms (3 asymmetric, 2 symmetric) to encrypt keys but others could be defined and used. The specified symmetric algorithms are AES in CBC mode and AES-GCM. RB (?) asked if the group could reuse some existing registry, perhaps by adding a column, rather than ? Just add a column? Mike Jones agreed that would be better than yet another registry. XXX PSA - Required algorthms???? XXXX see audio Matt Miller asked how does current draft handle multiple recipients? Mike Jones noted that the current draft requires different messages for each recipient, but that it was listed as an open issue. Matt commented that sounded pretty miserable for some applications and specifically for XMPP. Rich Alimi raised requirements from the alto working group, where they have large documents and would prefer not to have to base64url encode them Matt Miller questioned why there was no integrity in header for JWE. Mike Jones noted that there is an integrity check on the header in JWS. Matt indicated that an integrity check for the header in the JWE is a good idea. Mike moved on to the JWK, which specifies the JSON representation of public keys. Through the jabber room, ekr suggested bringing private keys back into scope. Hannes questioned whether the use case was well enough supported to merit the extra effort. Mike worked through an example that showed JWK carrying multiple keys. Leif Johannson asked why the JWK format wasn't as compact as others? Mike Jones indicated that the original use case would not result in transmission of the JWK so compactness wasn't crucial. New scenarios have been identified that do cause transmission of JWKs, so they should make it more compact. Sean Turner noted that format only supports named curves for ECC (i.e., no explicit parameter specifications). He was personally happy with that, but asked if anyone asked for anything else? Mike indicated there were no requests for parameter specifications in the JWK, and the scribe breathed a sigh of relief. There was a discussion of the refactoring that would be required for JOSE if the documents were to be adopted. Primarily, there was a need to split the three documents into four. Specifically, there is a need an algorithms profile with the mandatory to implements. Paul Hoffman suggests moving all the algorithms and string names to the new fourth document, so that string names are defined in the same document where the algorithms are identified. There were a number of open issues #1: do we want pure JSON representation? Wasn't base64url encoded so not URL safe; could be used in http bodies (might address the alto issues) Matt Miller indicated that XMPP could use pure JSON format. Rich Alimi indicated that alto could also use a pure JSON format. #2: do we need additional header params? E.g., what about public keys and certs by value instead of reference? Sean Turner and Matt Miller indicated that additional parameters were needs. #3 what about combining encryption and integrity operations? Could be more compact; would likely result in four-part representation Mike Jones noted that AES-GCM would give you this for free, but was not available in some of the common toolsets. Mike Jones also note that W3C has started a working group "W3C Web Cryptography Working Group". They are working on APIs. Petere St. Andre was at the W3C meeting. He noted that they are starting dedicated discussion list but the charter is a work in progress. At this stage, it is just a wiki; we have plenty of time to keep these coordinated. Three "Next Steps" were identified: * Does WG want to adopt these docs? * What coordination strategy for W3C? * Assuming WG accepts documents, refactor and submit These questions were deferred so that Jim could present the requirements list questions. Jim Schaad presented some questions about the Jose feature set. He had sent emails to list early to mid September. Since he received no replies, he wanted to ask again in a terser manner. Jim reviewed a list of features primarily from the cryptographic message syntax (CMS) that are not currently in the JOSE proposals, and wanted to know which features the working group thought should be considered. (1) 1 pass processing? Will this be used for large enough amounts of data that we can't store? Rich Alimi observed that alto could use 1 pass processing, too. Mike Jones indicated that the current specs are explicitly designed to support one pass processing. Jim indicated that there may be some issues lurking in those specifications that would preclude 1 pass processing. Derek Atkins noted that one pass for creation and one pass for decoding may be different issues, and that he thinks the latter is far more important. (2) Interior content identification: other specifications use OIDs and URLs. This is set up for short strings. Do we need a registry? (3) Content encoding methods - do we need detached signatures? Jim observed this might help alto. (4) Do we need embedded sigs? (5) Parallel signatures - do we need multiple sigs or are nested signatures sufficent? (6) Protected Attributes - Do we need a new class of protected attributes? It might be good to support some attributes and protect them but not cause the recipient to fail if they don't recognize them. Do we need additional attributes? What about things like signing times? On the S/MIME mailing list, Dave Solo had expressed the opinion that attributes should be part of the body and not the signatures. Paul Hoffman noted that there was no expression of support on the list. Sean Turner observed that things like signing time are really useful and are probably needed. Mike Jones indicate that time was in the signing token now, but not in the JWS. (7) Unprotected attributes - do we need them. Jim Schaad indicated that the only useful attribute he could think of would be countersignature. Sean Turner indicated that three unprotected attributes were defined in S.MIME, but not particularly widespread adoption. The sense of the group was it just may not be worth adding unprotected attributes, although no hum was held. From jabber, Phill Hallam Baker recalled that proof chain was motivation for unprotected attributes, and indicated he doesn't think it applies here ... (8) Multiple recipients (9) Recipient encryption methods - should we support pre-shared keys, IBE, or PLASMA? Should we attempt to make it possible, even if we decide not to add new methods at this point? (10) Recipient/signerid (11) Re-serialization Jim Schaad said he doesn't think these are needed. At this point, they held hums on WG adoption of the proposed specifications. The Hums were 100% in favor of adoption. Sean Turner noted that he wants to see more traffic on list Mike Jones indicated he could do the refactoring in about a week if pressed. Jim asked him to aim for the middle of December. Mike noted he needed input on one issue - should the algorithm ids be in the algorithm document, or retained in current drafts? Sean Turner said to learn from the PKIX and SMIME experiences and use one draft. Paul Hoffman noted this also ensures that folks have to review the mandatory to implements. Jim noted that this would be the analog to RFC 3279 plus mandatory to implements. Jim Schaad said he would like to see "signature" replaced with integrity or something else, especially in the title of the JWS WG draft. HUM confirmed that unanimously room supports change Pete Resnick : suggests accepting drafts as is. Can insist on changes in next rev. There were some fragmented discussions to kill time. These discussions covered the KISS principle, versioning, multiple recipients, and the ALTO and XMPP use cases.