Folks,
Here are some raw notes from the jose meeting. Special thanks to Carl
Wallace for these. They have not yet been turned into minutes. That will
hopefully be done shortly. Any corrections to these notes are welcome in
anticipation of minutes.
Regards,
Karen
JOSE WG - IETF 85 Agenda
========================
Wednesday, 7 November 2012, 900-1130 EDT (1400 - 1630 UTC)
******************************************************************************************
JWA, JWE, JWK, JWS Document Updates
******************************************************************************************
John Bradley presented slides
(http://www.ietf.org/proceedings/85/slides/slides-85-jose-4.pdf).
No questions or comments.
******************************************************************************************
JWS, JWE, JWA, JWK Way forward
******************************************************************************************
Nat Sakimura presented slides
(http://www.ietf.org/proceedings/85/slides/slides-85-jose-1.pptx).
Richard Barnes: One might observe that requiring all fields to be critical and
requiring
a nonce invites abuse. Process-wise, should revisit these after some other
discussions.
********Algorithm issue********
Jim Schaad: Heard interesting presentation during KITTEN, they were discussing
requirements for supporting Suite B in Kerberos. Though shalt not SHA1
anything. Even
though there are no known issues with HMAC-SHA1, it is not permitted by a Suite
B version
of the system, this may or may not cause changes here. This is potentially a
good time
to ask W3C to implement the specs.
John Bradley: Same point, for Suite B if OAEP w/ SHA1 were made mandatory then
folks would
get into scenario where could not be Suite B and JOSE compliant. Having it
available for
use but omitted in government implementations should be fine. The debate is
still open.
Probably not going to see the world agree on an OAEP variant.
Joe Hillenbrand: One thing discussed early on was to select small number of
things to increase
interoperability. Not suggesting things be nailed down to one, but if we are
going to pick
one mandatory to implement make it Suite B compatible.
Richard: Thought we were not going to have mandatory to implement algs. The
alg definitions
in the web crypto spec allow for separate specification of params to OAEP.
That spec is not
finalized but that is current state.
Stefan Santesson: Really really bad for protocol to specify mandatory to
implement algs.
Joe: Having users define their own MTI makes sense but guidance can be provided
to help
make choices.
Mike Jones: Background info about how the specs currently handle the status of
whether some things
are required, optional or deprecated. Illustrious AD Sean suggested that
practice be followed
where a field is added to the registry for algorithms and explicitly give
designated experts
to change status over time as crypto landscape changes. There will be initial
values, but
fully expected that some new algs will be added, downgraded, etc. Not in an
inflexible
situations. Additionally, always part of JOSE to create interoperable specs.
Which is why
the question keeps coming up about PKCS1.5. Should OAEP be supported at all,
use default in RFC 3347
or do something else. Studies of existing libraries indicate that this is the
only feasible
choice today. Would like to see this issue put to bed.
Richard: If MTI question is to be pursued, should it be run to ground now or
flagged as issue.
Karen O'Donoghue: Flag as an issue.
Stefan: Secdir may define a document with IETF wide algorithm statements.
Would be a good
approach even if not fitting the timeframe for this group.
Sean Turner: Suite B does not define RSA for signature stuff, so perhaps we
should just let it be.
Karen: Any objections? No. Will take to list for closure. On to criticality
of fields.
********Criticality issue********
Richard: If we do not allow non-critical fields we invite folks to stuff things
into critical fields
that don't really fit. There are some syntactic ways to support non-critical
fields. NC fields
is a good idea.
Jim: Question about bullet 2 on criticality slide. Can you tell me why
mandating applications to decide
which fields are critical would not provide same security levels.
John: the receiver must understand what it is being sent. Sender may have a
different understanding than
receiver.
Jim: Application should define in a specification to address understanding
mismatch. Lets it live outside
of the core spec.
John: It may be possible to leave to all things that use the JOSE specs but
thinks this would lead
to interop issues.
Hannes Tschofenig: If you think about the usage of these, different apps have
very different semantics and
require specs anyway. So there is no additional security problem with leaving
decision to apps. For example,
S/MIME defines different CMS fields than other apps.
John: Agrees with Richard that if multiple things are using these specs, all
may need a way to indicate
non-critical elements. We will wind up with interop issues otherwise. Can't
assume isolation between
apps, for example SAML tokens.
Hannes: <missed comment>
Richard: We will encode it all in DER:-) Some of the suggestions on the list
have been to make two
buckets instead of one (critical and non-critical instead of just critical).
Mike: A number of syntaxes have been proposed. For example, include a list of
fields that may be allowed
to be not understood.
John: Mike is saying, that no one is expressing the opinion that all fields are
non-critical. Everyone
agrees that at least some fields should be critical but no one is saying all
should be critical. Though
there may be some folks who hold this opinion (i.e. all critical).
Mike: List traffic indicated there were people who held this view. Simplicity
is one reason. Code can simply
look at each field, ask do I understand it, fail if not. Alternative is
inventing a mechanism for
per field behavior.
Joe: We've had good success with forward compatibility. If you've updated one
side but not the other, its
tough to know what to send if sending something new breaks the other side.
Mike said from the floor
that this argues not to send it. However, this inhibits future change. If we
think we won't need
different params in the future fine, but that's probably not the case.
John: Disagrees with Mike since other protocols will need to include different
information into the headers
for different reasons, including encrypted body. Saying everything in headers
must be understood is going
to far.
Sean: Conservative in sending, liberal in receiving. Are we sure we have
everything we'll need identified?
Jim: It is just as simple to pass in a list of headers that the application
understands to make applications
responsible instead of libraries.
Matt Miller: Should not make everything mandatory. In XMPP, we include a rough
timestamp. It works for XMPP
but won't work for most cases. Thus some headers need to be non-critical.
Need not be in the protocol, could
be app specified.
Mike: Not philosophically opposed to having a list of fields that indicate
fields to ignore. To Jim's point
about apps defining such, the current spec is completely agnostic to that. As
long as app understands, spec
allows it to be used. <scrum at mic and floor>
Karen: Before we spend more time, if there is a small group that could work
with Mike to make the change could
a solution be reached? Perhaps with Richard and John.
Mike: Perfectly willing to write up something.
Stefan: Is there a thought that the header fields might be expanded in the
future.
Karen: Uncomfortable precluding expansion. So we've decided all fields are non
critical and will figure out
right text offline.
********Nonce issue********
Jim: I have proposed a means for putting a timestamp parameter in. Got a
number of comments "but do you
have a concrete reason for needing this parameter"? If you don't, there is no
reason to include a time
of signing parameter. Without a use case, acceptance was thin. Not sure what
should be done with the proposal.
Hannes: There a couple of different aspects. Does not matter if defined now or
later. Apps will define new
stuff anyway. Where should you put it - header or body? Also does not matter
since it needs to be signed.
Gets to question how much stuff into base specs and how much into applications.
Should not be too religious
as it does not matter at the end of the day.
John: Since we will resolve the criticality issue, this is less important.
Need to determine if multiple folks
will need it.
Joe: Seems reasonable that more than one app will want protection against
replay.
Mike: Not disagreeing. Restating some comments from the list, folks who have
implemented this at Google
and elsewhere, if you don't have an expiration with a nonce then you are
implying infinite storage.
Jim: The proposal had no nonce and was strictly a time. However, given
resolution to previous item then this
is less important at this time.
Karen: Will take this issue up later. It will not impact WGLC decision. Three
issues coming in.
WGLC will be discussed at the end.
******************************************************************************************
JOSE Use Case Document
******************************************************************************************
Richard Barnes presented slides
(http://www.ietf.org/proceedings/85/slides/slides-85-jose-2.pdf).
Jim: Would support adopting this as a WG item.
Matt: I also think this would be a good document to adopt.
Karen: Any objections. None. Will be adopted.
Sean: Procedural point. Will need to re-charter since charter limits the
number of docs.
Should be easy to address.
******************************************************************************************
Serialization Documents
******************************************************************************************
Mike Jones presented slides
(http://www.ietf.org/proceedings/85/slides/slides-85-jose-3.pptx).
Richard/Mike: <missed exchange regarding slide 7>
Matt: Re: XMPP, know who is being sent to but not which end point is receiving.
Mike: Fair point. May want to distribute cipher text before knowing which key.
Matt: In XMPP, this always occurs.
Sean: Recharter or stick this stuff into existing docs? Recharter should be
easy.
Jim: Prefer us to recharter or include in docs?
Sean: Publish docs.
John: If the right structure is to have as separate doc, we should not let
charter issue
get in the way.
Karen: For purpose of today, consensus is to adopt as separate docs. Will
worry about
charter later.
Richard: Aside from process points, current docs are not a good starting point.
<missed rationale>
******************************************************************************************
Wrapped Keys
******************************************************************************************
Matt Miller presented slides
(http://www.ietf.org/proceedings/85/slides/slides-85-jose-7.pdf).
Richard: This is a great idea. We have JWE with key mgmt mech and makes sense
to use it.
Proposal 2 is the right way to go. Proposal 1 is riddled with issues. All
sorts of questions
about which algs to use. Much cleaner to use Proposal 2.
Jim: You mentioned integrity. Are you doing two separate integrity checks on
original msg
and key exchange?
Matt: Yes.
John: My understanding is that the initial message is JWE but recipient does
not have decryption
key yet. Recipient can ask for the key. Backwards to what usually happens.
Mike: Is there concrete syntax for proposal 2?
Matt: Yes, previous two slides. Strawman syntax at present.
Mike: Different thing from JWK.
Jim: Procedure question. How will strawman get incorporated into one or more
docs?
Matt: Will prepare a draft or work with Mike to see if changes can be made
directly to JWK.
Mike: Gut reaction is to see individual draft first. Short draft is fine.
Matt: OK.
Jim: Anyone else to scream and yell? No. A draft will be prepared for group
review.
******************************************************************************************
SPI
******************************************************************************************
Richard Barnes presented slides
(http://www.ietf.org/proceedings/85/slides/slides-85-jose-6.pdf).
John: I don't hate it. Observes that in Open ID connect pre-negotiation
occurs. Would not
want to remove the ability to specify params in each message. For typical
case, the two
parties will have negotiated out of band and this will save a pile of octets.
Joe: Likes the idea. Did you mean random for spi name? Or something like a
UUID? Or something
like a hash.
John: Probably protocol dependent.
Richard: No randomness requirements. Probably some uniqueness requirements,
within some
scope.
John: Will need to determine if sender is identified separately or if
uniqueness is global,
but this can be sorted out.
Matt: This will be application dependent.
Richard: Proposes this go in as text to JWS and JWE. Will provide text to Mike.
Karen: Anyone against this? No. Are folks comfortable with Richard and Mike
working to modify
the base docs?
John: Would prefer to see a short draft before mucking with base docs.
Richard: Probably not a draft, but an email.
******************************************************************************************
Key Requets from W3C
******************************************************************************************
Mike Jones presented slides
(http://www.ietf.org/proceedings/85/slides/slides-85-jose-5.pptx)
John: As I recall, initial hesitation was with public keys risk of disclosure
is small, but with
private keys we are taking on large expansion in responsibility. Somewhat
hesitant but this
is going to be done anyway so we should best grapple with it. Potential for
getting it wrong is
dire.
Justin ?: Add support for it. Add another use case: configuration of bare keys
in apps.
Would like to use JSON based formats for storing raw keys and not have to do
and create
a certificate.
Ryan Sleevi: If the WG does not adopt this, then the Wc3 work will pursue it
since use cases
demand such. JOSE seems to be the consistent place to do this work. If JOSE
rejects, then
WebCrypto group will standardize.
Joe: Have always wanted this. Overjoyed to have use cases for this. Thinks
the WG is
good place to do the work. Enthusiastically supports.
Matt: Earlier presentation was argument for wrapped sym key, as others have
said private key
piece would be useful. Thinks security issues can be addressed and not made
worse.
Jim: Has not read the draft, puzzled what it is that is required for symmetric
key usage? Do
you want algs as well since key is just a base64 string.
Mike: Yes. Would identify the algorithm and key blob. Analogous to X.509
SubjectPublicKeyInfo.
Richard: A couple of desires: 1) wrapped key format for import/export; 2) keys
that have attributes
attached.
Mike: Already have key ID. Could define more.
Jim: Clarifying if attributed private key is desired. Are you proposing that
we accept as a
work item, protection mechanisms.
Mike: No request so far.
Joe: I am making that request. Necessary to have complete suite.
John: Violently opposed to doing the work without protection mechanisms.
Sean: Procedurally, nice that it went this route instead of through liaison
process.
John: Not making comparisons to previous attempts by IETF to define
alternatives to X.509.
Karen: Will address under rechartering discussion.
******************************************************************************************
Private Key Formats
******************************************************************************************
Mike Jones presented slides
(http://www.ietf.org/proceedings/85/slides/slides-85-jose-8.pptx).
Richard: Should merge this with the stuff Matt talked about earlier. May make
sense to address
in JWK.
Matt: Need to write drafts first and see what they look like. Multiple docs
may make things
more readable.
Joe: Have you defined a protection mechanism yet?
Mike: No
John: Agree that Matt is pushing private keys around and needs protection.
Wrapped symmetric
key more specifically, Lots of overlap with this.
Joe: Start with an email to the list describing the overall architecture. Here
are the pieces, how
they fit, etc. Let's see it at least in high level form then decide how to
best allocate to
documents.
Mike: Three layers: public key, key representations for private and symmetric
keys, key protection
mechanisms.
******************************************************************************************
Re-chartering questions
******************************************************************************************
Sean: The milestones are separate from charter so just send an email with new
dates.
Karen: Back to WGLC questions. One open issue on criticality of headers:
Richard, John and Mike
will address. Private key work and SPI work effect core docs.
Jim: Richard, would you like to have mandatory to implement (MTI) algorithm
argument now?
Richard: Sure. The broad outline is whether these specs should require a given
set of algs.
A similar arg went through WC3 web crypto group. They decided against.
Argument in favor
is interoperability. Counter view is placing alg requirements makes it hard
for apps to make sure
certain algorithms are available. For example, multi-platform browsers that
use OS crypto.
Jim: Make clear, IESG will complain if there is not a mandatory to implement
alg. May be able to
get away with pushing to application.
Richard: Yes. CMS and PKIX do not have required algs. This is not DNSSEC
which is a global
infrastructure. In this case, the communications are between two parties who
can figure out
what they want to do.
Mike: Every draft for last two years has had some set of MTI algs. Having a
small core helps.
Request is that if we are changing, there should be a consensus call. Change
is a fairly big deal.
Re: Web crypto decision, their use case is different. In our case, a small set
of algs is proposed
to promote interop. They are defining general purpose low level mechanism.
Russ Housley: Interop is the whole point with MTI. However, algs will change
over time. Do
not put this in base spec. We have made that mistake before, don't repeat.
Reason PKIX does
not have MTI alg is that certs are used in many apps. Each app defines MTI
achieving separation
of MTI from syntax.
Barry Leiba: Would rather see MTI in registrations of these things.
Appreciates that apps
should define. Given reuse of apps, there is concern about not stating
something. (from floor) use case?
No use case, just thinking ahead.
Mike: The spec initializes a set of use, don't use, etc in a registry.
Russ: Please don't confuse a registry with MTI.
Richard: Re: cross-app usage, for interop there are often specs to iron out
details anyway. Just
another detail in those.
Joe: Fine with punting to apps. For example, for XMPP these are MTI, etc.
Karen: So, hearing generally agreement to move out of base spec except from
Mike. AD has asked to do a hum then
will take it to a list. Hum indicates remove from base spec wins. Will bring
up on the list. There
are four open issues. Another rev of docs will be required before WGLC. How
long will it take to rev drafts?
Richard and Matt?
Richard: SPI should be quick. By end of year.
Matt: For draft of wrapped keys. Similar time frame. Integrating with others
is a different discussion.
Mike: Private key, wrapped key, etc. is much bigger chunk of work. Would like
JWK go to WGLC sooner.
Jim: Does current JWK define anything about field criticality?
Mike: Follows other docs.
Jim: So we need a rev for that too.
Richard: Matt's private key bits should just be shuffling stuff between docs.
Should not be large effort.
Karen: I though W3C work would take longer.
Jim: Opposed to including private keys with a doc describing protection.
Sean: Would like to see this work taken on.
Karen: A few issues to incorporate. Aim is to issue WGLC in early 2013.
Mike: Assuming we make decisions on these issued before WGLC, chairs should
assume a consensus call will be
held on the list.
Jim: I assume you preference would be to update JWA and JWK specs to include
private keys?
Mike: I would prefer to go forward with public key docs as is and write a new
draft that would update and
add fields to JWK structure but in a separate draft for private, sym and
wrapped keys.
Richard: I think I would split todos into piles: 1) things that go into a JWE;
2) things like private keys, sym keys and
attributes. Push wrapped keys into JWK. Provide feedback to W3C as well.
Mike: I have a different model of what JWK is for vs Richard. JWK is just a
key representation. If you want
to wrap it, that's a different object that uses JWK. It's not a part of the key
but a container. Would write
container separately.
Richard: JWK defines how to send keys on the wire.
Joe: Would be nice to have one short email with architecture. Too early to say
how docs will be split. Leave
that out of new charter.
Karen: Who is going to write architecture email.
Joe: Mike nodded in a way that indicated he may do that.
Mike: OK, if I get some input on best practices for wrapped keys.
Joe: Let's find a white board this week, then send notes from that board to the
list.
Karen: Strongly agree.
Joe: I will fill the whiteboard.
Karen: Next thing is use cases doc. Charter will be updated. Ditto
serialization draft, which will
be incorporated somehow. Charter will be updated for this as well. Final is
W3C work will be documented
in email generated by the white board team. Anything else?
Jim: Joe, do you want volunteers?
Joe: Sending note to the list right now.
Matt: One thing that has come up on the list is key derivation stuff. Some
disalignment with NIST 800-56a.
PBKDF2 as defined says a password is an octet string. <missed comments>
Mike: Primary thing in specs, is to address legitimate concerns about use of
concat KDF. Initially no length prefix.
So there was ambiguity. With length prefix, ambiguity is gone. What is it
possible for everyone to easily implement?
With concat, it's a string concat and a hash. Everyone can do that. At least
6 implementations.
Richard: Are we actually saving anything. Are we sending more info to identify
KDF than if we just sent key, since
KDF is intended to allow use of shorter keys.
Mike: You do need KDF for ECDH anyway. Anything with key agreement will have
KDF already.
Matt: In that case, implementing PBKDF is not much more difficult.
Mike: Iterations are just more work.
Jim: Iterations can be set to 1.
Matt: Looking at things that do PBKDF and concat KDF, it's not hard to
implement PBKDF.
?: Is subject KDFs or password based KDFs?
Jim: KDFs
?: Don't we have a real KDF? Why not use that? Lots of work going on about
improving PBKDFs. Not sure
marrying to PBKDF2 is wise.
Matt: Not saying we only implement PBKDF2, saying for things we register don't
see why not PBKDF2.
Mike: Given decision to specify AEAD, there's nothing to say you could not
define another alg, say CBC with a different
KDF. Various iterations with ADs etc to make sure use of concat is clean.
Same issues would come up
for any other KDF. Similar sets of inputs. Not any simpler to use different
KDF.
Matt: <missed comments>
Richard: Our need to have this discussion is a consequence of alg IDs. If alg
ID included this things then
this would not be an issue. May want to figure out how to separate this out to
be more configurable.
Mike: That's a closed issue.
Karen: Issuer tracker will be used going forward. Read the docs now and get
comments out now
to spare work during WGLC.
Kevin Igoe: There is a draft that does composite AEAD <missed>. May want to
look at that.
Mike: WG did have a presentation last time. Discussion was that it is an alg
that could be added should it
mature.
Kevin: Why not just steal their params?
Mike: There was a length expansion there that we don't need.
Richard: Please post to the list how using a longer key compares to using a
KDF.
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
