The JOSE (JSON Object Signing and Encryption) working group met on 7/30/2013 from 13:00 to 15:00 hours. The meeting started with a status report about the group from the chairs. Since the last meeting in Orlando, the group has successfully been re-chartered. A face-to-face meeting and 3 virtual ad hoc meetings were also held. Next Richard Barnes gave a presentation on Issue #23 "Direct Signing (without Base 64)" The Goal: flexibility of inputs and outputs so that applications don't have to conform to JOSE expectations to make use of it. Richard's proposal is that for a signed object without a protected header, the signing input is just the unencoded payload. (For cases with a protected header, the original specification of a dot preceding the payload is retained.) List input indicated that this scheme was more complex. Richard argues that the complexity only shows up with the non-protected header case, so the complexity shouldn't really be a problem. Jim Schaad had previously noted (on the list) that there was a concern about shifting data between the protected header and the content. Without requiring encoding prior to the concatenation of the two (as would the case without a protected header), it's possible to shift the data from the header into the content with a dot introduced between them and end up with an equivalence after encoding. In short, the benefits are greater JWS applicability at the cost of some possible complexity and splicing/fusion risks. John Bradley noted that at the meeting the previous day, there was a randomized signature presentation that strongly argued for using protected headers. This might not be a very frequently used stream in that case. A number of people in the room expressed that there was a possible attack based on the fact that there were now multiple ways of doing things and it would be possible to force the relying parting to use one or the other behavior. Richard stated that CMS was a case where this type of mode existed and it was not an issue. Paul Hoffman disputed this based on the interop events that were held for S/MIME and he will, within 10 days, supply information on how CMS (S/MIME) dealt with splicing/fusion risks. Next John Bradley gave a presentation on the current set of issues for JOSE in the tracker database. * Issue #5 - Unclear instructions for key management. Jim Schaad noted that he had forgotten to close this from a previous telechat and would do so now. * Issue #7 - Algorithm/identifiers parameters incompatible with WebCrypto. Richard noted that this onus is really on the WebCrypto team at this point and as it is just a watch item we should close it. * Issue #13 - Enable AEAD key wrapping. Mike Jones stated that the changes keeping this issue open were placed in the -13 version of the document. It should now be closed. * Issue #14 - Support longer wrapped keys than OAEP allows. Richard noted that the slides did not adequately reflect the fact that what could be done is to wrap a JWK object rather than a symmetric key. He also noted that this might be a method that is used in the WebCrypto group, but they are not currently coming to closure on the issue. He also stated that he asked for feedback from two WebCrypto participants but had not received any. Under those circumstances he felt is was OK to close the issue. * Issue #15 - Address MAC key lifetime concerns Jim stated that this was being kept open only as a reminder to himself. He would close and open a new issue as needed. * Issue #18 - Address MAC key lifetime concerns Mike stated that he had added in a set of security considerations to the version 14 draft that was just published. At this point people need to review the text and determine if it is sufficient. Reviews should be completed in two weeks after which a decision on closing this issue will be made. The chairs stated that they would like to get input from Micheal Peck as this was his issue before making a final determination. * Issue #25 - Detached content for the ALTO use case Richard said that he would like to close this, but it might be helpful to describe how to do this. John was worried that this would be a rat hole as it was really an application space issue to find these things. Mike stated that he would be willing to add this to the document where Jim requested some detail about what he planned to say. Mike said that applications could sign indirect content by computing a digest of it and then including that digest in the main message content. Applications would then need to specify how to find the content and what the normalization process would be. Jim then asked if digest algorithms would need to be defined here. Richard said that he disagreed with the approach suggested. Mike and Richard will work on producing some text for the list to consider and details will be worked out then. The issue will be resolved at the next conference call. * Issue #26 - Allow for signature payload not to be base64 encoded John said that this issue should wait for something like a compact binary serialization. Joe Hildebrand said see CBOR and Richard nodded vigorously. Jim said he could live with deferring the issue until an updated version. * Issue #28 - AES-GCM should not be allowed for content encryption in combination with Direct Encryption key management mode This issue is basically the same as issue # 18. The resolution will be the same. * Issue #29 - Add an explicit "aad" field to JWE Mike state this was completed in version 13 and the issue can now be closed. Richard concurred and will raise new issues with the implementation. * Issue #30 - Align key usages with WebCrypto John stated that we should not change from the current single value behavior because having a single key usage or a single algorithm is a good thing. If WebCrypto wants to add new restrictions that is fine. Mike stated that this was a conscious choice adopted by the JOSE WG. Jim noted that currently for WebCrypto the importKey functionality requires that a key be marked with both the key wrap and decryption key usages. Richard noted that it is common practice to use the same asymmetric key pair for both signature an encryption operations. John responded - don't do that. The issue is to be resolved as won't fix in the tracker and a request for it to be done in the WebCrypto working group will be done. * Issue #31 - Add extractability field for JWK Jim noted that it was not really semantically undefined - for the WebCrypto group this was a simple boolean. This was echoed by Richard. Mike and John stated that since they know what they want, then we should have them register the header. The issue will be closed as won't fix. The final presentation by Richard was addressing two new JW* Issues Richard is raising two issues from his review of the drafts: 1. Ambiguities in public key formats 2. COMSEC requirements jku/x5u URIs EC and RSA keys differ in what they contain. RSA keys can be leading zero padded which can lead to incorrect assumptions about the strength of the key if such an evaluation is made purely based on key length and not content. RSA key lengths don't work well with base64 padding removal. Richard suggests encoding and padding rules for RSA keys to remove those issues. Mike Jones disagrees with Richard's characterization of the RSA key formatting as being "developer hostile". Mike will update the current drafts to reflect removing leading zeros when dealing with unsigned integers. Richard believes that the EC public key format doesn't really define what a big-endian representation of a finite field element is, among several ambiguities. Richard prefers the SEC1 format in place of the current JOSE format, particularly as this format is used by many other specifications (CMS, TLS, IPsec, etc.). Sean Turner notes that the compressed EC key format has IPR issues, so only uncompressed points should be specified. However it was pointed out that this is true just by using EC even without compression will generate the IPR issues. The discussion of using the SEC1 is to be continued on the mailing list. If there is an x5u pointing to a certification issued by a major CA, is TLS required for the HTTP query used to retrieve this certificate? TLS shouldn't be needed since the certificate is a signed object. Therefore, the "MUST" use TLS for cert retrieval should be changed to "SHOULD". This is an application decision. Mike Jones doesn't want removal of TLS in the case where there's no external means to verify the retrieved key. Matt Miller: agrees with the jku case, but argues that for x5u, there is a class of applications where it isn't known if the retrieved object is self-protecting (like a certificate) until after it is retrieved. Even if the object appears to be self-protecting, if the retriever doesn't have a trusted root for that object, it might not be able to verify the protection anyhow. So it use of TLS might still be preferable instead of having to potentially retrieve an object twice, once over HTTP and then over HTTPS. Joe Hildebrand wanted to know what the upside of this proposal is. Richard says it saves on TLS handshakes; Hildebrand envisions a world where TLS is ubiquitous. Paul Hoffman said that a similar issue in DANE ended up being dropped after a couple of months of discussion. Richard agreed to drop the TLS MUST to SHOULD proposal. Mike Jones will make the public key format changes. Jim Schaad noted that if HTTPS is required for any of these URLs, then a signature/integrity protection should be required when the URL is in the JOSE message. Richard is concerned about cases in which the signature over the URL is computed using a certificate specified by the URL. This issue will be taken to the mailing list. The final issue on the agenda was what processing needed to be done going forward. Any outstanding issues should be broached real soon now. On the next call, it's expected that all issues will be entered and an assessment of how long it will take to close them can be made. This will affect when the documents move to WGLC. Sean Turner wants this to happen sooner rather than later. While nothing precludes issues from being raised during WGLC, the chairs would prefer to see technical issues closed prior to WGLC. Matt Miller has some issues he hope to have submitted before the end of next week. Sean Turner points out that there are opportunities to submit issues during WGLC and IETF LC. Upcoming conference calls will be agreed based on what times work best for the participants.