[jose] draft minutes for jose wg meeting at IETF87

[Karen O'Donoghue <[e-mail]>]

The following draft minutes have been posted to the IETF87 Proceedings 
(http://www.ietf.org/proceedings/87/minutes/minutes-87-jose). A big 
thank you to our excellent minute taker... Any corrections or additions 
are welcome...

Regards,
Karen



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.