Folks,
I just posted draft minutes for jose. If you have any comments or
questions, feel free to send them along. Thank you to Peter Yee for the
excellent notes.
Regards,
Karen
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.
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
