Minutes for JOSE WG @ IETF 88
Thursday 7 November 2013, 0900-1130 PST

Jim Schaad and Karen O'Donoghue called the meeting to 
order. The Note Well was presented, and the blue sheets 
circulated. Peter Yee agreed to take the minutes, and 
Joe Hildebrand volunteered as the jabber scribe. 

The chairs covered the current status of the working 
group. The use cases document has been sent to the IESG. 
The JWS, JWE, JWK, and JWA have had a total of 185 
issues (many with multiple parts) entered against them. 
There are 129 closed issues. The co-chairs and editor 
have had several meetings this week and previously 
resulting in agreements for 49 issues. These issues are 
either awaiting editor implementation, awaiting 
implementation verification, or awaiting external input 
or verification. The remaining 7 issues will be 
discussed today. 

#54 (JWA), #55 (JWA), #141 (JWS)
All three of these are related to the concat issue. Jim 
Schaad wants to separate nonce from PartyUName and is 
concatenated to it to form the PartyUInfo.  Default 
PartyUName and PartyVName should be 'Sender' and 
'Recipient' respectively, to deal with the NIST Concat 
algorithm specification.  The current scheme is that the 
nonce is built into the PartyUName and PartyUInfo is the 
same as PartyUName.  And currently, PartyUName and 
PartyVName default to empty strings.  Mike Jones and 
Richard Barnes disagree with the nonce scheme.  While 
JOSE has already deviated from the NIST specification, 
the question comes down to whether a FIPS-compliant 
usage is possible.  Sean Turner doesn't feel hard over 
on the point.  Schaad's changes are not adopted, 
although one edit to [do something] will be made.

#74-C (JWK)
If a JWK has only an x5u member in it, is this a legal 
construct and how does one say this matches a bare 
public key?  What is the minimum set of fields must be 
present in the JWK.  Barnes: a JWK for private/public 
key should always specify the public key fields.   Matt 
Miller: the kty should be specified.  And having the 
full key is of great benefit.  Jones: the document 
already says that use of the key types is required and 
for specific algorithms the required fields are listed, 
so X.509 carriage doesn't contravene those requirements.

#77
'x5c' requirements are that certs are in chain but don't 
have to form a complete chain.  An incomplete chain 
requires cert chain building.  Should we just say the 
certs are in a bag and not a chain except that the first 
cert must be the end-entity cert.  Barnes: TLS does 
something similar to what's in our document now.  
Schaad: does TLS require a full chain to be present.  
Barnes: everything except the self-signed root (which 
you already have) must be included (paraphrased by 
Schaad).  Miller: the chain just needs to be present up 
to the point where the software has sufficient data to 
complete the chain or agree that it trusts the chain.  
Bags would be much worse without a lot of benefits.  
John Bradley: chain checking is hard enough now; bags 
won't make that easier.  Schaad: the language will not 
be changed but will checked to see that it is clear in 
the case of partial chains.

#93
Non-normative appendix to JWS that summarizes the ways 
to find a key based on fields in messages and JWK 
structures.  Schaad's proposal enumerates the ways he 
has been told that keys could be found, but he may have 
missed something.  Barnes gave a smaller set of ways 
that he believes are sufficient if not as complete.  
Brian Campbell: clarification: finding a key is not the 
same as trusting a key.  Miller: good point.  For trust, 
make sure keys are fetched over HTTPS unless they were 
integrity protected within the message.  Barnes' 
proposal is pretty solid and software that doesn't 
understand x5u and x5t should drop processing them.  
Barnes: The focus for this spec is making the crypto 
work.  Authentication systems can be layered on top of 
that.  Campbell: I'm not looking for exhaustive trust 
establishment text, just a note of caution.  Jones: From 
Turner: a key is only as trusted as the method by which 
it was obtained.  Miller: I agree with Jones.  Maybe the 
topic of trust should be addressed at the beginning of 
the paragraph.  How to establish trust in keys is a big 
rathole. Robin Wilton: we need to be sensitive to the 
idea that an EE platform notices a software agent 
looking for key stores might be indistinguishable from 
an attack.  Jones: Agreed, we don't want to down the 
rathole of specifying trust methods.  Turner: don't say 
how it is done, but say that it should be done and to 
what level it should be done.  Schaad: this item will 
stay open until a volunteer supplies text.

#114-C Section 4.1.10 'crit'
If an extensions is place in a 'crit' header, must that 
extension be signed?  Currently there is no statement 
requiring that.  Bradley: it makes as much sense as 
saying can optionally not be integrity protected.  Not 
terribly enthusiastic.  Certainly the 'crit' field has 
to be protected or it doesn't mean anything, but not 
sure of enforcing that the extension is integrity 
protected.  But I could also go with integrity protected 
everything.  Joe Hildebrand: I could see protecting 
everything.  Barnes: I don't see a need for normative 
protection, but guidance okay.  Jones: people seem to be 
saying that guidance that should say 'crit' could be 
integrity protected.  Bradley: there is a community that 
says you should always protect everything, but there are 
others who don't think this is required.  A 
recommendation for integrity protection unless there's a 
need not to would be pretty well received.  Jones: in 
Denver we came to a compromise that maximize consensus 
and I'm against reopening the point for this particular 
questions.  Hildebrand: agreed, no need to relitigate 
this point.  Schaad: so this one will be closed as 
'won't fix'.

Next steps:
Jones will get a version of the document out in the next 
week with all changes he has to date.  Jones: there are 
hundreds of changes to be made, but I will get out a 
version that covers the changes to the normative text, 
especially in regards to the MtI text.  We would then be 
done with changing normative requirements.  Schaad: The 
full document with edits is targeted for mid-December.  
Jones: Agreed.  O'Donoghue: mid-December would be when 
we close all issues except for the one that Brian will 
open today and #93 which needs text.  Jones: I don't 
want to make promises I can't keep due to other 
commitments, so I'll get the near-term changes next week 
and the full version of the document by the end of the 
year.  Schaad: an interim meeting makes sense after the 
full document is out.  Proposing January 13, 2014 for a 
virtual interim meeting. 

Cookbook Document: 
Schaad: our charter calls for a cookbook document, which 
hasn't shown up yet.  Our AD requested this.  Not sure 
what goes into it.  We need to decide to do about that 
charter requirement.  Miller: I was one of the ones 
asked to work on it and I have batted ideas around with 
Barnes.  There would be solid examples of the large 
number of permutations that are possible.  Turner: one 
example of how to make an interoperable system suffices.  
Two is fine but not necessary.  Barnes: this would be a 
document showing how to use all of the different 
features we have in our documents.  There might be 
guidance on how to create an application using the JOSE 
tools.  Turner: this document just needs to get us 
through the IESG process, it doesn't have to be 
encyclopedia.  Miller: will get together with Turner to 
discuss further.

 Jones: Signing detached content came up on the mailing 
list and should be discussed here.  Schaad: I sent out 
to the list on this idea.  Jones had a different way of 
doing things.  Schaad replied with some minor edits to 
Jones' text.  Barnes: this is too complicated.  It 
should be just you slice off the payload and tell people 
how to put it back.  There's no need to this 'hash 
thing', but it's really more complicated than necessary.  
Jones: we had discussed that with the hash-based method, 
the application has to know which hash function to use.  
That would require JOSE names for those functions.  I 
had thought we could do that, but it seems like 
undesirable scope creep.  I would be amenable to 
dropping my second method.  Schaad's method has no 
normative effect on JOSE libraries, so it should be an 
appendix.  Schaad: an appendix is fine.  Barnes: agreed, 
this is suggestions on how to build an application.  It 
could even go in the cookbook.  Miller: +1.  Schaad: the 
indirect signature version will be removed and the 
detached signature version will be placed in an 
appendix.
 Barnes: once the cookbook is done, are we finished?

 Turner: use case document going forward is great for 
the IESG.  Will the rest of the documents go forward at 
once.  Schaad: only the cookbook may be late.  Turner: 
good.  Barnes: would the cookbook make the other four 
documents be easier for the IESG to understand?  Turner: 
probably, but I'm willing to push it as I'm a lame duck.  
Barnes: not so worried about IESG concerns, but we could 
try to accelerate the cookbook document to help with 
getting the other documents through the IESG.  Schaad: 
when could you have a rough draft ready.  Miller: if we 
sit down this week, we could probably have enough time 
to have an outline before we leave the meeting.  The 
actual document could be ready in January.

The meeting adjourned.