Subject: Re: [jose] Two proposed JOSE spec actions to more closely coordinate with WebCrypto

From: John Bradley <[email-masked]>
Date: Mon, 6 Jan 2014 21:43:00 -0300

Use was originally optional so going back to that is fine.

Having the Web Crypto WG sort out meta-data for key usage by the crypto subsystem and or secure storage with other elements is fine with me.

I think they are different use cases one for private or secret keys and the other for public keys.

I do think that for storage restricting the alg will be required if disclosure to the application layer is to be prevented, but the WC WG can work on that without holding up the JWK spec as long as they have the extension point.

John B.

On Dec 31, 2013, at 4:18 PM, Mike Jones <[email-masked]> wrote:

> The context that some participants may not be keeping in mind is that when “use” was defined, JWKs were intentionally limited to representing public keys.  The “use” field is used for distinguishing between public signing keys and encryption keys.  The use case where a set of public keys is publicly advertised for use by a protocol participant is quite common.  “use” is intentionally designed for that use case and works great there.
>  
> Sometime later, we added the ability to represent private and symmetric keys to JWK – at the request of the WebCrypto WG.  This expanded the possible use cases for JWKs to include transporting non-public keys between protocol participants.  With the addition of non-public keys, additional key uses became possible, including the possibility of the same key being legally used for two things (signing/verification, etc.).  The “use_details” representation makes sense for those use cases.
>  
> I’d be fine relaxing the language saying that “use” must be present, because I agree it’s not a good fit if non-public keys are present.  I suspect not requiring “use” would make people happier in the non-public use cases.  And we could explicitly say that “use” is intended for use cases where only public keys are present.  Do people agree with this change?
>  
> Given our goal of keeping simple things simple, I believe that “use” should be retained as-is for the very common use case of sets of public keys.  It already works great there.
>  
> I’d also be fine saying that applications should specify which of “use” and “use_details” they will use and that the other will be ignored.  I’m also fine changing the name of “use_details” to “eku” (extended key usages) or something similar – reflecting the fact that then “use” and “eku” aren’t intended to be used together.  And we would say that this field is intended for use cases where both public and non-public keys may be present.  Do people agree with this change?  If so, what name do you want us to use for the expanded key usages field?
>  
>                                                             -- Mike
> From: Richard Barnes [mailto:[email-masked]] 
> Sent: Tuesday, December 31, 2013 9:03 AM
> To: Mike Jones
> Cc: [email-masked]; John Bradley; [email-masked]
> Subject: Re: [jose] Two proposed JOSE spec actions to more closely coordinate with WebCrypto
>  
> However, in advocating for two, parallel extensions to JWK for essentially the same purpose, you're basically arguing that "use" is not generally applicable to JWK -- it applies to OpenID/SAML-like stuff, but not much more broadly.  (You can't really say the same thing about the more detailed version, since it's a superset.)  But if "use" is not a generally useful feature of JWK, then it shouldn't be part of the spec.
>  
> In other words, if a feature is going to be part of the JWK spec, then it needs to meet the requirements that participants in this group put forth.  If we're choosing not to meet those requirements (as "use" does not), then it needs to come out of the spec.
> 
> I think there's still room for compromise here (see my other reply on the proposal directly).  But if there's no compromise, then there's no consensus, and "use" needs to go.
>  
> --Richard
> 
> 
> 
>  
> 
> On Mon, Dec 30, 2013 at 5:34 PM, Mike Jones <[email-masked]> wrote:
> There's nothing wrong with different use cases with different needs supplying different key metadata.
> 
> The ability to do that is an indication of the versatility and usefulness of the JWK format - not a deficiency.
> From: Ryan Sleevi
> Sent: 12/30/2013 1:55 PM
> To: Mike Jones
> Cc: Mike Jones; [email-masked]; Richard Barnes; John Bradley; [email-masked]
> 
> Subject: Re: [jose] Two proposed JOSE spec actions to more closely coordinate with WebCrypto
> 
> On Mon, December 30, 2013 1:29 pm, Mike Jones wrote:
> >  ... and lest there be any confusion, the JWK spec doesn't require the use
> >  of "use".  WebCrypto can specify that it not be used and require the use
> >  of "use_details" if that best meets the needs of your use case.
> 
> So you're still arguing for two, incompatible ways of expressing use
> within the base spec. The current draft (-19) proposes that "A 'use'
> member SHOULD be present, unless the application uses another means or
> convention to determine the intended key usage".
> 
> That is, if draft-19 were pushed to WGLC, it would leave authors confused
> as to when to use either. As specified, the language still strongly
> prefers "use", and continues to suggest "use_details" as a subset, when
> it's not really.
> 
> Richard's solution is much more sensible, in that it makes it clear that
> there is a single clean way to communicate use going forward, and a
> deprecated way from existing specs. Existing keys can continue to be
> imported into new versions of the spec - it's only an issue when a new
> version of the spec is used to interoperate with an older version. I don't
> think it's fair to suggest that's "backwards compatibility" - that's an
> issue of "forwards compatibility", and one that is far trickier to get
> right, and arguably far less important here - and one that can be
> addressed in *new* implementations by choice or config.
> 
> Let me try to state the problem differently:
> 
> Is "use" generically suitable for use cases of JWK? Can you envision other
> scenarios where it can be gracefully extended?
> 
> As I see it, the answer is clearly "no", as already evidenced by
> WebCrypto's intended use, but also demonstrated by Axel's example of "do
> not want" (which is X.509's 'extended key usages' field). As such, we
> should try to fix that spec before finalizing, rather than bolt-on
> additions and try to rush things through WGLC, or we should accept that
> this is a problem the spec/spec authors are not interested in solving
> cleanly, and WebCrypto can move to a solution that does.
> 
> Both specs are still in their infancy of both implementation and adoption
> and we should try to do things right while we can.
> 
> >  ________________________________
> >  From: Mike Jones<mailto:[email-masked]>
> >  Sent: ý12/ý30/ý2013 1:12 PM
> >  To: [email-masked]<mailto:[email-masked]>
> >  Cc: Richard Barnes<mailto:[email-masked]>; John
> >  Bradley<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> >  Subject: Re: [jose] Two proposed JOSE spec actions to more closely
> >  coordinate with WebCrypto
> >
> >  Ryan, this isn't an either-or situation. JWK is intended to be a general
> >  key representation format. It's extensible exactly so information for any
> >  use cases that need info not in the base spec can add it.  I'm still
> >  puzzled why some in WebCrypo felt uncomfortable using this extensibility
> >  by defining and registering a new field for WebCrypyo's representation of
> >  use info. But observing that to be the case, I'm attempting to be as clear
> >  as possible (through spec actions!) that there's absolutely no reason for
> >  WebCrypto not to use JWK.
> >
> >  There's no plans to "continue to evolve JWK to parallel the SAML
> >  workflows" that I'm aware of. Rather, I believe the only further addition
> >  being considered before completing the spec is one motivated by
> >  WebCrypto's use case rather than SAML - "use_details".
> >
> >  I believe that the current JWK spec already meets WebCrypto's needs as-is.
> >   Is there any reason not to just use it and move on to addressing other
> >  issues needed to be resolved to complete both JOSE and WebCrypto, both of
> >  which I see as being complementary and important to the industry?
> >
> >  -- Mike
> >  ________________________________
> >  From: Ryan Sleevi<mailto:[email-masked]>
> >  Sent: ý12/ý30/ý2013 12:47 PM
> >  To: Mike Jones<mailto:[email-masked]>
> >  Cc: [email-masked]<mailto:[email-masked]>; Richard
> >  Barnes<mailto:[email-masked]>; John Bradley<mailto:[email-masked]>;
> >  [email-masked]<mailto:[email-masked]>
> >  Subject: Re: [jose] Two proposed JOSE spec actions to more closely
> >  coordinate with WebCrypto
> >
> >  On Mon, December 30, 2013 11:40 am, Mike Jones wrote:
> > >  As further background for the discussion, the current "use" definition
> > > is
> > >  based on widely deployed existing practice - the SAML metadata
> > >  specification
> > >  (http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf),
> > >  which defines "use" as follows in section 2.4.1.1:
> > >  use [Optional]
> > >  Optional attribute specifying the purpose of the key being described.
> > >  Values are drawn from the
> > >
> > >  KeyTypes enumeration, and consist of the values encryption and signing.
> > >
> > >
> > >
> > >  This has been shown to be sufficient in practice for its intended
> > > purpose,
> > >  as has the JWK "use" field.
> > >
> >
> >  Mike,
> >
> >  I feel like you're arguing all the more strongly for WebCrypto not to use
> >  JWK, in that you're arguing that JWK's "intended purpose" is to match
> >  SAML. I can understand where this fits within the JWT and OpenID Connect
> >  workflows, but as a "JSON key description" format, it is unquestionably
> >  much more restrictive and ill-suited.
> >
> >  If the goal is to continue to evolve JWK to parallel the SAML workflows,
> >  then I don't see how WebCrypto can in good conscience encourage JWK.
> >
> >  There's nothing preventing authors from translating JWK into any sort of
> >  API form that WebCrypto requires - much in the same way that they can
> >  translate the composite JWA algorithms (which are suitable for transport)
> >  into WebCrypto's broader, more generic algorithms (which are suitable for
> >  an API targeting application development).
> >
> >  Arguably, the only reasons to use JWK are to prevent introducing "yet
> >  another key format". While laudable, if JWK is trying to mirror SAML, then
> >  it would seem that JWK is not trying to be a key format, per se, and such
> >  risk would be low.
> >
> >  Again, I'm perfectly fine if JOSE would rather that JWK be kept as minimal
> >  and as specific for the JWT use case, and we can easily use a descriptive
> >  WebIDL within WebCrypto to describe the key formats it operates with (in
> >  addition to SPKI and PKCS#8). Comments so far from this WG give me the
> >  sense that there's strong opposition by some to seeing JWK evolve to be as
> >  flexible or generic as SPKI/PKCS#8. That's fine by me, but that's
> >  extensibility that WebCrypto wants, and if JWK isn't it, we can use
> >  something else. OpenID Connect and JWT can continue to use JWK as suited
> >  for their needs, and if for some reason someone wants to use JS to
> >  interact with these, they can use a translation shim, just as they would
> >  for JWE/JWS or for *any other* cryptographic application, since WebCrypto
> >  is "just" an API.
> >
> > >
> > >
> > >  I understand your point, Ryan, that for the WebCrypto API use case,
> > > there
> > >  is sometimes value in distinguishing between the producer and consumer
> > >  operations for a key.  That's part of why I proposed adding
> > > "use_details",
> > >  so those distinctions can be made for the use cases where they do make
> > > a
> > >  difference.
> > >
> > >
> > >
> > >  As for Richard's proposal, the problem with it is that it would be a
> > >  breaking change, since if "ku" was present, his proposal would require
> > >  different treatment of the "use" field (ignoring it).  My proposal is
> > > not
> > >  a breaking change, since "use" continues to mean what it always has.
> > >  Furthermore, my proposal requires that "use" and "use_details" convey
> > >  consistent information, if both are present.  That seems significantly
> > >  simpler for consumers of JWKs use than requiring conditional behaviors,
> > > as
> > >  Richard's proposal does.
> > >
> > >
> > >
> > >                                                              Best
> > > wishes,
> > >
> > >                                                              -- Mike
> > >
> > >
> > >
> > >  -----Original Message-----
> > >  From: Ryan Sleevi [mailto:[email-masked]]
> > >  Sent: Monday, December 30, 2013 10:25 AM
> > >  To: Richard Barnes
> > >  Cc: Mike Jones; [email-masked]; John Bradley; [email-masked]
> > >  Subject: Re: [jose] Two proposed JOSE spec actions to more closely
> > >  coordinate with WebCrypto
> > >
> > >
> > >
> > >  On Sat, December 28, 2013 3:12 pm, Richard Barnes wrote:
> > >
> > > >  On Fri, Dec 27, 2013 at 10:50 PM, Mike Jones
> > >
> > > >  <[email-masked]<mailto:[email-masked]>>wrote:
> > >
> > > >
> > >
> > > > > It's my sense of the JOSE working group that most are strongly
> > >
> > > > > opposed to breaking changes at this point.
> > >
> > > >
> > >
> > > >
> > >
> > > >  Please don't claim to represent the WG.  There is a significant
> > >
> > > > contingent  who care about breaking changes, but also a significant
> > >
> > > > group who would  prefer the best, most usable spec we can make,
> > >
> > > > regardless of the sins of  the past.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > > However, I also believe that most JOSE participants share the
> > >
> > > > > sentiment of many WebCrypto participants that it would be better for
> > >
> > > > > all for WebCrypto to use real JWKs, rather than something
> > >
> > > > > "JWK-like".
> > >
> > > > >
> > >
> > > >
> > >
> > > >   How about this for a compromise proposal:
> > >
> > > >  -- Leave "use" in for backward compatibility.
> > >
> > > >  -- Define a new field "ku" (Key Usage, or something similar) that has
> > >
> > > > detailed key usage information.
> > >
> > > >  -- Deprecate "use", recommending that new applications use "ku"; if
> > >
> > > > both  are present, "use" MUST be ignored.
> > >
> > > >  -- Define the expansion of "use" values to "ku" values
> > >
> > > >
> > >
> > > >  That doesn't break backward compatibilty, but makes detailed control
> > >
> > > > the  default going forward.
> > >
> > > >
> > >
> > > >  --Richard
> > >
> > >
> > >
> > >  As I expressed within WebCrypto, this to me strikes a much more
> > > sensible
> > >  balance of backwards compatibility and extensibility, and hopefully in
> > > a
> > >  way that allows existing deployments to cleanly transition while
> > > allowing
> > >  new deployments to avoid the limitations of the current drafts.
> > >
> > >
> > >
> > >  I very much prefer this over use_details for Web Crypto's use cases.
> > >
> > >
> > >
> > > >
> > >
> > > >  I believe my proposal is the best-available solution, given the
> > >
> > > > current
> > >
> > > > > realistic constraints.  It might have made better sense for a
> > >
> > > > > WebCrypto spec to define "use_details" than JOSE, but if WebCrypto
> > >
> > > > > isn't going to do it, I believe that we'll all be better off in the
> > >
> > > > > long run if JOSE then does and WebCrypto uses it.
> > >
> > > > >
> > >
> > > > >                                 Cheers,
> > >
> > > > >                                 -- Mike
> > >
> > > > >
> > >
> > > > > -----Original Message-----
> > >
> > > > > From: Ryan Sleevi [mailto:[email-masked]]
> > >
> > > > > Sent: Friday, December 27, 2013 6:46 PM
> > >
> > > > > To: Mike Jones
> > >
> > > > > Cc: [email-masked]<mailto:[email-masked]>; John Bradley;
> > > > [email-masked]<mailto:[email-masked]>
> > >
> > > > > Subject: Re: [jose] Two proposed JOSE spec actions to more closely
> > >
> > > > > coordinate with WebCrypto
> > >
> > > > >
> > >
> > > > > On Fri, December 27, 2013 5:58 pm, Mike Jones wrote:
> > >
> > > > > >  I disagree that "use" allows multiple uses.  Sign/Verify both use
> > >
> > > > > > the same  algorithm with the same key - just in a
> > > producer/consumer
> > > > role.
> > >
> > > > > > There  would only be a security problem if the same key was used
> > >
> > > > > > with
> > >
> > > > > > *different*  algorithms.
> > >
> > > > > >
> > >
> > > > > >  For symmetric keys, Sign/Verify operations are actually the same,
> > >
> > > > > > so in  that case, this is a distinction without a difference.
> > >
> > > > > >
> > >
> > > > > >  You may consider the producer/consumer distinction to be multiple
> > >
> > > > > > uses,  but only in an academic sense.  You have to perform both
> > >
> > > > > > with the same key  pair or symmetric key for the end-to-end
> > >
> > > > > > cryptography to
> > >
> > > > > be meaningful.
> > >
> > > > > >  Doing one without the other is incomplete.  (What good is signing
> > >
> > > > > > if the  signature is never verified?)
> > >
> > > > >
> > >
> > > > > Hi Mike,
> > >
> > > > >
> > >
> > > > > I don't think it's fair to compare them as the same, and it's very
> > >
> > > > > much a practical, and not an academic case.
> > >
> > > > >
> > >
> > > > > In a Sign() operation, the input is arbitrary plaintext and the
> > >
> > > > > output is a signature corresponding to that plaintext; an oracle, if
> > >
> > > > > you will - as you would want.
> > >
> > > > >
> > >
> > > > > In an API (although not necessarily in JWE/JWS, and understandably
> > >
> > > > > so), a
> > >
> > > > > Verify() operation permits arbitrary plaintext as the input, but
> > >
> > > > > also requires the signature to be verified. The only output is a
> > >
> > > > > boolean - whether or not the signature is correct.
> > >
> > > > >
> > >
> > > > > The goal of "restricting" the uses here would be to allow key
> > >
> > > > > storage not necessarily under the control of the caller. In
> > >
> > > > > WebCrypto, this is the distinction between the executing JS (served
> > >
> > > > > by the web page) and the UA implementation. It's a concept borrowed
> > >
> > > > > from any number of other good cryptographic APIs (eg: those that are
> > >
> > > > > designed with the notion of opaque key storage)
> > >
> > > > >
> > >
> > > > > With a symmetric key only permitted for a "Verify" operation, the
> > >
> > > > > only way to generate a signature for an arbitrary message is
> > >
> > > > > a) Compromise the key storage
> > >
> > > > > b) Iterate through all possible signature combinations until you get
> > >
> > > > > "true" as the Verify() result.
> > >
> > > > >
> > >
> > > > > b) may be aided by any number of implementation issues (eg:
> > >
> > > > > non-constant time comparisons, among others), but is ultimately
> > >
> > > > > "tricky". a) is dependent on implementations, and can be aided or
> > >
> > > > > harmed through a variety of means.
> > >
> > > > >
> > >
> > > > > Combining these two usages into a single use case - which, I agree,
> > >
> > > > > is probably perfectly acceptable if imagining as a transport-only
> > >
> > > > > exchange
> > >
> > > > > -
> > >
> > > > > can thus have real and meaningful differences when used at an API
> > > > level.
> > >
> > > > >
> > >
> > > > > >
> > >
> > > > > >  Likewise, Encrypt/Decrypt and Wrap/Unwrap make producer/consumer
> > >
> > > > > > distinctions, but also only use a single key with a single
> > >
> > > > > > algorithm - therefore no security problem.
> > >
> > > > > >
> > >
> > > > > >  ====
> > >
> > > > > >
> > >
> > > > > >  For what it's worth, I think the different key use representation
> > >
> > > > > > choices  stems from JOSE being a high-level API that tries to make
> > >
> > > > > > simple things  simple and WebCrypto being a low-level API that
> > >
> > > > > > tries
> > >
> > > > > to
> > >
> > > > > be complete.
> > >
> > > > > >  Both are valid and useful.  These differences show up in lots of
> > >
> > > > > > places  besides just key usage representations.
> > >
> > > > >
> > >
> > > > > Absolutely agree here. This is why WebCrypto explored whether we
> > >
> > > > > should do something "JWK-like", but suitable at an API layer and for
> > >
> > > > > it's goals, and "trivially" convertable with JWK - but by script
> > >
> > > > > authors. The WebCrypto WG wasn't fond of it, which is
> > >
> > > > > understandable, and why I'm here.
> > >
> > > > >
> > >
> > > > > >
> > >
> > > > > >  Anyway, the purpose of my proposal is to try to make things
> > >
> > > > > > easier for  WebCrypto.  I hope people will get behind it.  Yes,
> > >
> > > > > > having both simple and  detailed key usage representations seems
> > > odd
> > > > at first.
> > >
> > > > > > But they're  designed to address different goals for different
> > >
> > > > > > kinds
> > >
> > > > > of
> > >
> > > > > applications.
> > >
> > > > > >  The alternatives (such as "signOnly,verifyOnly", etc.) that are
> > >
> > > > > > currently  being considered are much worse.
> > >
> > > > > >
> > >
> > > > > >                               -- Mike
> > >
> > > > >
> > >
> > > > > I agree that changing to an array will almost certainly break every
> > >
> > > > > implementation to date.
> > >
> > > > >
> > >
> > > > > I agree that comma-separated is horribad and should be avoided, even
> > >
> > > > > if it "solves" the backwards compat issue.
> > >
> > > > >
> > >
> > > > > I think your solution is a reasonable attempt to mediate the issues
> > >
> > > > > of backwards compatibility with the use cases of WebCrypto. However,
> > >
> > > > > I'm still on the fence as to whether or not it really is
> > >
> > > > > unreasonable to "break"
> > >
> > > > > backwards compatibility here - there seems to be a compelling case
> > >
> > > > > here as to why even something like ["sign", "verify"] should be
> > >
> > > > > distinct usages.
> > >
> > > > > I
> > >
> > > > > know the bar is incredibly high right now, given JOSE's momentum,
> > >
> > > > > but I didn't think that JOSE was past the point of no return.
> > >
> > > > >
> > >
> > > > > >
> > >
> > > > > >  -----Original Message-----
> > >
> > > > > >  From: Ryan Sleevi [mailto:[email-masked]]
> > >
> > > > > >  Sent: Friday, December 27, 2013 2:13 PM
> > >
> > > > > >  To: John Bradley
> > >
> > > > > >  Cc: Mike Jones; [email-masked]<mailto:[email-masked]>
> > >
> > > > > >  Subject: Re: [jose] Two proposed JOSE spec actions to more
> > >
> > > > > > closely coordinate with WebCrypto
> > >
> > > > > >
> > >
> > > > > >  I'm sorry, John, but by your logic, JOSE is not following your
> > >
> > > > > > own
> > >
> > > > > advice.
> > >
> > > > > >
> > >
> > > > > >  "enc" is already a multiple-use for a key - it allows for both
> > >
> > > > > > encryption  and decryption. For that matter, wrap and unwrap,
> > >
> > > > > > which are supposed to be  inferred based on algorithm, which is a
> > >
> > > > > > JWE/JWS specific aspect, and not  an intrinsic aspect of
> > >
> > > > > JWK-as-key-representation.
> > >
> > > > > >
> > >
> > > > > >  Likewise, "sig" implies sign AND verify, which is meant to be
> > >
> > > > > > unambiguous,  because the assumption is always that you sign with
> > >
> > > > > > a private key and  verify with a public key, but as a conceptual
> > >
> > > > > > framework breaks down for  schemes like HMAC, which ostensibly
> > >
> > > > > > have sign and verify (or MAC and  verify, if you prefer, but we're
> > >
> > > > > splitting
> > >
> > > > > hairs here).
> > >
> > > > > >
> > >
> > > > > >  WebCrypto desires to be *more* precise than JOSE's imprecise and
> > >
> > > > > > overly  broad, implicitly multi-use syntax. That "enc" means four
> > >
> > > > > > possible uses,  or that "sig" means two , is a clear sign that
> > >
> > > > > > JOSE is already actively  encouraging multiple uses for the same
> > > > key.
> > >
> > > > > >
> > >
> > > > > >  Mike's proposal is basically an admission that the ship has
> > >
> > > > > > sailed on this  implicit, multi-valued usage semantic - which, I
> > >
> > > > > > can understand and  sympathize with, in the name of backwards
> > >
> > > > > > compatibility for an in-draft  spec, but let's recognize that as
> > >
> > > > > > spec'd today, JOSE is preferring and  encouraging multiple uses
> > >
> > > > > > for the same key in ways that will  unquestionably encourage
> > >
> > > > > > people to make bad mistakes (such as multiple  parties using the
> > >
> > > > > > same encryption key for traffic in either direction -  requiring
> > >
> > > > > > some degree of IV sync)
> > >
> > > > > >
> > >
> > > > > >  On Tue, December 24, 2013 4:27 pm, John Bradley wrote:
> > >
> > > > > > >  Having it be an array encourages multiple uses for the same
> > >
> > > > > > > key.  I have  stated many times that encouraging people to do
> > >
> > > > > > > that is not a good idea,  and making it easy makes people think
> > > it
> > > > is a good idea.
> > >
> > > > > > >
> > >
> > > > > > >  You can use the single value field and have multiple entries
> > >
> > > > > > > with different key containing the same or different keys to do
> > >
> > > > > > > the same thing.
> > >
> > > > > > >
> > >
> > > > > > >  On the practical side "use_details" is better than creating
> > >
> > > > > > > crazy dot separated como uses.
> > >
> > > > > > >
> > >
> > > > > > >  John B.
> > >
> > > > > > >
> > >
> > > > > > >  On Dec 24, 2013, at 8:26 PM, Mike Jones
> > >
> > > > > > > <[email-masked]<mailto:[email-masked]>>
> > >
> > > > > > >  wrote:
> > >
> > > > > > >
> > >
> > > > > > > > Hi all,
> > >
> > > > > > > >
> > >
> > > > > > > > Having reflected upon discussions among WebCrypto and JOSE
> > >
> > > > > > > > participants about JWK usage by WebCrypto over the holidays,
> > >
> > > > > > > > I'd like to propose the two JOSE spec actions to more closely
> > >
> > > > > > > > coordinate
> > >
> > > > > > > with WebCrypto:
> > >
> > > > > > > >
> > >
> > > > > > > > 1.  Change the JWA registry field name from "Implementation
> > >
> > > > > > > > Requirements" to "JOSE Implementation Requirements" in the
> > >
> > > > > > > > JSON Web Signature and Encryption Algorithms Registry (
> > >
> > > > > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-18#se
> > >
> > > > > ction-7.1
> > >
> > > > > ).
> > >
> > > > > > > >  This will make it clearer that the Implementation
> > >
> > > > > > > > Requirements apply only to JWS and JWE implementations - and
> > >
> > > > > > > > not other uses of JWK (such as WebCrypto).  This changes only
> > >
> > > > > > > > non-normative text and is
> > >
> > > > > > > non-breaking.
> > >
> > > > > > > >
> > >
> > > > > > > > 2.  Define the new JWK field "use_details" for recording
> > >
> > > > > > > > intended fine-grained key usage information.  This would
> > >
> > > > > > > > enable WebCrypto KeyUsage
> > >
> > > > > > > > (https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overvi
> > >
> > > > > > > > ew.h
> > >
> > > > > > > > tm
> > >
> > > > > > > > l#key-interface) values to be used directly with JWK.  The
> > >
> > > > > > > > proposed definition is:
> > >
> > > > > > > >
> > >
> > > > > > > > 3.3.  "use_details" (Key Use Details) Parameter
> > >
> > > > > > > >    The "use_details" (key use details) member identifies
> > >
> > > > > fine-grained
> > >
> > > > > > > >    details the intended use of the key.  Its value is an array
> > > > of
> > >
> > > > > > > >    key use details values.  Values defined by this
> > >
> > > > > > > > specification
> > >
> > > > > are:
> > >
> > > > > > > >
> > >
> > > > > > > >    o  "sign" (compute signature or MAC)
> > >
> > > > > > > >    o  "verify" (verify signature or MAC)
> > >
> > > > > > > >    o  "encrypt" (encrypt content)
> > >
> > > > > > > >    o  "decrypt" (decrypt content and verify decryption, if
> > >
> > > > > applicable)
> > >
> > > > > > > >    o  "wrap" (encrypt key)
> > >
> > > > > > > >    o  "unwrap" (decrypt key and verify decryption, if
> > > > applicable)
> > >
> > > > > > > >    o  "deriveKey" (derive key)
> > >
> > > > > > > >    o  "deriveBits" (derive bits not to be used as a key)
> > >
> > > > > > > >
> > >
> > > > > > > >    Other values MAY be used.  Key Use Details values can be
> > >
> > > > > registered
> > >
> > > > > > > >    in the IANA JSON Web Key Use Details registry defined in
> > >
> > > > > > > > Section
> > >
> > > > > > > 7.3.
> > >
> > > > > > > >    The use details values are case-sensitive strings.
> > >
> > > > > > > >    Duplicate use details values MUST NOT be present in the
> > > > array.
> > >
> > > > > > > >    Use of the "use_details" member is OPTIONAL, unless the
> > >
> > > > > application
> > >
> > > > > > > >    requires use this member to record fine-grained key usage
> > >
> > > > > details.
> > >
> > > > > > > >    (Note that the "use_details" values intentionally match the
> > >
> > > > > > > > "KeyUsage"
> > >
> > > > > > > >    values defined in the WebCrypto [WebCrypto] specification.)
> > >
> > > > > > > >
> > >
> > > > > > > >    If both "use" and "use_details" JWK members are present,
> > >
> > > > > > > > the
> > >
> > > > > usages
> > >
> > > > > > > >    specified by them MUST be consistent.  In particular, the
> > > > "use"
> > >
> > > > > > > value
> > >
> > > > > > > >    "sig" corresponds to "sign" and/or "verify".  The "use"
> > > value
> > >
> > > > > > > >    "enc" corresponds to all other values defined above.
> > >
> > > > > > > >    If "use_details" values corresponding to both "sig" and
> > > "enc"
> > >
> > > > > > > >    "use" values are present, the "use" member SHOULD NOT be
> > >
> > > > > present,
> > >
> > > > > > > >    and if present, its value MUST NOT be either "sig" or
> > > "enc".
> > >
> > > > > > > >
> > >
> > > > > > > > This is a non-breaking change - allowing simple applications
> > >
> > > > > > > > that want to distinguish between signing and encryption
> > >
> > > > > > > > operations to continue doing so as they do today, while also
> > >
> > > > > > > > providing a multi-valued key usage details field to be used by
> > >
> > > > > > > > applications that want to record fine-grained distinctions
> > >
> > > > > > > > among potential key usages, including distinguishing between
> > >
> > > > > > > > producer and consumer
> > >
> > > > > operations.
> > >
> > > > > > > >
> > >
> > > > > > > > As I see it, while having two related key usage
> > >
> > > > > > > > representations isn't ideal, it's far better than having
> > > > WebCrypto overload "use"
> > >
> > > > > > > > with multi-valued values encoded in strings, such as
> > >
> > > > > > > > "signOnly,verifyOnly", which I believe is their current plan
> > >
> > > > > > > > of
> > >
> > > > > > > record.
> > >
> > > > > > > >
> > >
> > > > > > > > Comments?
> > >
> > > > > > > >
> > >
> > > > > > > >                                                             --
> > >
> > > > > > > > Mike
> > >
> > > > > > > >
> > >
> > > > > > > > P.S.  This proposal was already discussed on the WebCrypto
> > >
> > > > > > > > list in the thread
> > >
> > > > > > > > http://lists.w3.org/Archives/Public/public-webcrypto/2013Dec/0052.
> > >
> > > > > > > > ht ml and no objections were raised there that I'm aware of.
> > >
> > > > > > > >
> > >
> > > > > > > > _______________________________________________
> > >
> > > > > > > > jose mailing list
> > >
> > > > > > > > [email-masked]<mailto:[email-masked]>
> > >
> > > > > > > > https://www.ietf.org/mailman/listinfo/jose
> > >
> > > > > > >
> > >
> > > > > > >  _______________________________________________
> > >
> > > > > > >  jose mailing list
> > >
> > > > > > >  [email-masked]<mailto:[email-masked]>
> > >
> > > > > > >  https://www.ietf.org/mailman/listinfo/jose
> > >
> > > > > > >
> > >
> > > > > >
> > >
> > > > > >
> > >
> > > > > >  _______________________________________________
> > >
> > > > > >  jose mailing list
> > >
> > > > > >  [email-masked]<mailto:[email-masked]>
> > >
> > > > > >  https://www.ietf.org/mailman/listinfo/jose
> > >
> > > > > >
> > >
> > > > >
> > >
> > > > > _______________________________________________
> > >
> > > > > jose mailing list
> > >
> > > > > [email-masked]<mailto:[email-masked]>
> > >
> > > > > https://www.ietf.org/mailman/listinfo/jose
> > >
> > > > >
> > >
> > > >  _______________________________________________
> > >
> > > >  jose mailing list
> > >
> > > >  [email-masked]<mailto:[email-masked]>
> > >
> > > >  https://www.ietf.org/mailman/listinfo/jose
> > >
> > > >
> > >
> > >
> > >
> > >
> > >  _______________________________________________
> > >  jose mailing list
> > >  [email-masked]
> > >  https://www.ietf.org/mailman/listinfo/jose
> > >
> >
> >
> >  _______________________________________________
> >  jose mailing list
> >  [email-masked]
> >  https://www.ietf.org/mailman/listinfo/jose
> >
>

---

From: Mark Watson <[email-masked]>
Date: Tue, 7 Jan 2014 13:04:25 -0800

So, where are we with this one ?

I am fine with either Mike's proposal or Richard's (revised) proposal.
Defining a new attribute was what I originally proposed in WebCrypto. The
objections to that were related to backwards-compatibility and consistency
between the two attributes, however I think if JOSE specifies the new
attribute and the interaction with the existing one (as discussed in this
thread) then those concerns may be mitigated. Or, if appropriate, WebCrypto
could register a new attribute with guidance on those issues from JOSE.

...Mark

On Mon, Jan 6, 2014 at 4:43 PM, John Bradley <[email-masked]> wrote:

> Having the Web Crypto WG sort out meta-data for key usage by the crypto
> subsystem and or secure storage with other elements is fine with me.
>
> I do think that for storage restricting the alg will be required if
> disclosure to the application layer is to be prevented, but the WC WG can
> work on that without holding up the JWK spec as long as they have the
> extension point.
>
> John B.
>
> The context that some participants may not be keeping in mind is that when
> “use” was defined, JWKs were intentionally limited to representing public
> keys.  The “use” field is used for distinguishing between public signing
> keys and encryption keys.  The use case where a set of public keys is
> publicly advertised for use by a protocol participant is quite common.
>  “use” is intentionally designed for that use case and works great there.
>
> Sometime later, we added the ability to represent private and symmetric
> keys to JWK – at the request of the WebCrypto WG.  This expanded the
> possible use cases for JWKs to include transporting non-public keys between
> protocol participants.  With the addition of non-public keys, additional
> key uses became possible, including the possibility of the same key being
> legally used for two things (signing/verification, etc.).  The
> “use_details” representation makes sense for those use cases.
>
> I’d be fine relaxing the language saying that “use” must be present,
> because I agree it’s not a good fit if non-public keys are present.  I
> suspect not requiring “use” would make people happier in the non-public use
> cases.  And we could explicitly say that “use” is intended for use cases
> where only public keys are present.  Do people agree with this change?
>
> Given our goal of keeping simple things simple, I believe that “use”
> should be retained as-is for the very common use case of sets of public
> keys.  It already works great there.
>
> I’d also be fine saying that applications should specify which of “use”
> and “use_details” they will use and that the other will be ignored.  I’m
> also fine changing the name of “use_details” to “eku” (extended key usages)
> or something similar – reflecting the fact that then “use” and “eku” aren’t
> intended to be used together.  And we would say that this field is intended
> for use cases where both public and non-public keys may be present.  Do
> people agree with this change?  If so, what name do you want us to use for
> the expanded key usages field?
>
>                                                             -- Mike
> *From:* Richard Barnes [mailto:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, December 31, 2013 9:03 AM
> *To:* Mike Jones
> *Cc:* [email-masked]; John Bradley; [email-masked]
> *Subject:* Re: [jose] Two proposed JOSE spec actions to more closely
> However, in advocating for two, parallel extensions to JWK for essentially
> the same purpose, you're basically arguing that "use" is not generally
> applicable to JWK -- it applies to OpenID/SAML-like stuff, but not much
> more broadly.  (You can't really say the same thing about the more detailed
> version, since it's a superset.)  But if "use" is not a generally useful
> feature of JWK, then it shouldn't be part of the spec.
>
>
> In other words, if a feature is going to be part of the JWK spec, then it
> needs to meet the requirements that participants in this group put forth.
> If we're choosing not to meet those requirements (as "use" does not), then
> it needs to come out of the spec.
> I think there's still room for compromise here (see my other reply on the
> proposal directly).  But if there's no compromise, then there's no
> consensus, and "use" needs to go.
>
> --Richard
>
>
>
>
> ------------------------------
> *From: *Ryan Sleevi <[email-masked]>
> *Sent: *12/30/2013 1:55 PM
> *To: *Mike Jones <[email-masked]>
> *Cc: *Mike Jones <[email-masked]>; [email-masked]; Richard
> Barnes <[email-masked]>; John Bradley <[email-masked]>; [email-masked]
>
>
> *Subject: *Re: [jose] Two proposed JOSE spec actions to more closely
> >  From: Mike Jones<mailto:[email-masked]<[email-masked]>
> >
> >  Cc: Richard Barnes<mailto:[email-masked] <[email-masked]>>; John
> >  Bradley<mailto:[email-masked] <[email-masked]>>; [email-masked]<
> mailto:[email-masked] <[email-masked]>>
> >  From: Ryan Sleevi<mailto:[email-masked] <[email-masked]>>
> >  To: Mike Jones<mailto:[email-masked]<[email-masked]>
> >
> >  Barnes<mailto:[email-masked] <[email-masked]>>; John Bradley<
> mailto:[email-masked] <[email-masked]>>;
> >  [email-masked]<mailto:[email-masked] <[email-masked]>>
> > >  (
> http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf),
> > >  From: Ryan Sleevi [mailto:[email-masked] <[email-masked]>
> ]
> > > >  <[email-masked]<mailto:[email-masked]
> >>wrote:
> > >
> > > >
> > >
> > > > > From: Ryan Sleevi [mailto:[email-masked]<[email-masked]>
> ]
> > >
> > > > [email-masked]<mailto:[email-masked] <[email-masked]>>
> > >
> > > > > >  From: Ryan Sleevi [mailto:[email-masked]<[email-masked]>
> ]
> > >
> > > > > >  Cc: Mike Jones; [email-masked]<mailto:[email-masked]<[email-masked]>
> >
> > >
> > > > > > > > (
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overvi
> > >
> > > > > > > > ew.h
> > >
> > > > > > > > tm
> > >
> > > > > > > > [email-masked]<mailto:[email-masked] <[email-masked]>>
> > >
> > > > > > >  [email-masked]<mailto:[email-masked] <[email-masked]>>
> > >
> > > > > >  [email-masked]<mailto:[email-masked] <[email-masked]>>
> > >
> > > > > [email-masked]<mailto:[email-masked] <[email-masked]>>
> > >
> > > >  [email-masked]<mailto:[email-masked] <[email-masked]>>
> > >

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Jan 2014 21:38:32 +0000

Where I think we are is choosing the right name for the extended key use field.  Names that have been discussed are:
               use_details - which I no longer think is the right name
               ku (key usage) - I think this name would be misleading
               eku (extended key usage) - I think this would be fine
               uses - I also think this would be fine

And I think we're also waiting for people to weigh in on the proposal that "use" no longer be so strongly recommended, in light of the fact that it's designed for distinguishing between public key usages - not all key usages.

I'm sure that this will be discussed during the call on Monday at 1900 EDT, 1600 PDT.  See the thread "[jose] JOSE WG virtual interim, Monday 13 January 2014, 2400 UTC" for call-in instructions.

                                                            -- Mike

From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, January 07, 2014 1:04 PM
To: John Bradley
Cc: Mike Jones; Richard Barnes; [email-masked]; [email-masked]
Subject: Re: [jose] Two proposed JOSE spec actions to more closely coordinate with WebCrypto

I am fine with either Mike's proposal or Richard's (revised) proposal. Defining a new attribute was what I originally proposed in WebCrypto. The objections to that were related to backwards-compatibility and consistency between the two attributes, however I think if JOSE specifies the new attribute and the interaction with the existing one (as discussed in this thread) then those concerns may be mitigated. Or, if appropriate, WebCrypto could register a new attribute with guidance on those issues from JOSE.

...Mark

On Mon, Jan 6, 2014 at 4:43 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
Use was originally optional so going back to that is fine.

John B.

On Dec 31, 2013, at 4:18 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

The context that some participants may not be keeping in mind is that when "use" was defined, JWKs were intentionally limited to representing public keys.  The "use" field is used for distinguishing between public signing keys and encryption keys.  The use case where a set of public keys is publicly advertised for use by a protocol participant is quite common.  "use" is intentionally designed for that use case and works great there.

Sometime later, we added the ability to represent private and symmetric keys to JWK - at the request of the WebCrypto WG.  This expanded the possible use cases for JWKs to include transporting non-public keys between protocol participants.  With the addition of non-public keys, additional key uses became possible, including the possibility of the same key being legally used for two things (signing/verification, etc.).  The "use_details" representation makes sense for those use cases.

I'd be fine relaxing the language saying that "use" must be present, because I agree it's not a good fit if non-public keys are present.  I suspect not requiring "use" would make people happier in the non-public use cases.  And we could explicitly say that "use" is intended for use cases where only public keys are present.  Do people agree with this change?

Given our goal of keeping simple things simple, I believe that "use" should be retained as-is for the very common use case of sets of public keys.  It already works great there.

I'd also be fine saying that applications should specify which of "use" and "use_details" they will use and that the other will be ignored.  I'm also fine changing the name of "use_details" to "eku" (extended key usages) or something similar - reflecting the fact that then "use" and "eku" aren't intended to be used together.  And we would say that this field is intended for use cases where both public and non-public keys may be present.  Do people agree with this change?  If so, what name do you want us to use for the expanded key usages field?

                                                            -- Mike
From: Richard Barnes [mailto:[email-masked]]
Sent: Tuesday, December 31, 2013 9:03 AM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>; John Bradley; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Two proposed JOSE spec actions to more closely coordinate with WebCrypto

--Richard

On Mon, Dec 30, 2013 at 5:34 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
There's nothing wrong with different use cases with different needs supplying different key metadata.

Cc: Mike Jones<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Richard Barnes<mailto:[email-masked]>; John Bradley<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

>  To: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>  Bradley<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
>  Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; Richard
>  [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
> >  which defines "use" as follows in section 2.4.1.1<http://2.4.1.1/>:
> >  use [Optional]
> >  Cc: Mike Jones; [email-masked]<mailto:[email-masked]>; John Bradley; [email-masked]<mailto:[email-masked]>
> > >  <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>wrote:
> >
> > >
> >
> > > > Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; John Bradley;
> > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
> >
> > > > >  Cc: Mike Jones; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
> >
> > > > > > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> >
> > > > > >  wrote:
> >
> > > > > >
> >
> > > > > > > Hi all,
> >
> > > > > > >
> >
> > > > > > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
> >
> > > > > >  [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
> >
> > > > >  [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
> >
> > > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
> >
> > >  [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
> >

---

From: Mark Watson <[email-masked]>
Date: Tue, 7 Jan 2014 15:36:58 -0800

Ok, thanks. Unfortunately, I can't make the call on Monday. However, I
don't have a strong opinion on how this is done, only that it is done and
in a way that allows WebCrypto keys to be accurately represented.

...Mark

On Tue, Jan 7, 2014 at 1:38 PM, Mike Jones <[email-masked]>wrote:

>  Where I think we are is choosing the right name for the extended key use
> field.  Names that have been discussed are:
>
>                use_details – which I no longer think is the right name
>
>                ku (key usage) – I think this name would be misleading
>
>                eku (extended key usage) – I think this would be fine
>
>                uses – I also think this would be fine
>
>
>
> And I think we’re also waiting for people to weigh in on the proposal that
> “use” no longer be so strongly recommended, in light of the fact that it’s
> designed for distinguishing between public key usages – not all key usages.
>
>
>
> I’m sure that this will be discussed during the call on Monday at 1900
> EDT, 1600 PDT.  See the thread “[jose] JOSE WG virtual interim, Monday 13
> January 2014, 2400 UTC” for call-in instructions.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* Mark Watson [mailto:[email-masked]]
> *Sent:* Tuesday, January 07, 2014 1:04 PM
> *To:* John Bradley
> *Cc:* Mike Jones; Richard Barnes; [email-masked]; [email-masked]
>
>   The context that some participants may not be keeping in mind is that
> when “use” was defined, JWKs were intentionally limited to representing
> public keys.  The “use” field is used for distinguishing between public
> signing keys and encryption keys.  The use case where a set of public keys
> is publicly advertised for use by a protocol participant is quite common.