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

From: Mike Jones <[email-masked]>
Date: Tue, 24 Dec 2013 23:26:26 +0000

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#section-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/Overview.html#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.html and no objections were raised there that I'm aware of.

---

From: John Bradley <[email-masked]>
Date: Tue, 24 Dec 2013 21:27:51 -0300

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]> 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#section-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/Overview.html#key-interface) values to be used directly with JWK.  The proposed definition is:
>  
> 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.html and no objections were raised there that I’m aware of.
>  
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 25 Dec 2013 01:52:14 +0100

* 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.

I think "not a good idea" is an understatement here.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Dec 2013 00:56:19 +0000

I agree with your sentiment.  We could add this language to try to discourage multiple unrelated uses:

Multiple unrelated uses SHOULD NOT be specified for a key because of the potential vulnerabilities associated with using the same key with multiple algorithms.  So the combinations "sign" with "verify", "encrypt" with "decrypt", and "wrap" with "unwrap" are permitted, but other combinations SHOULD NOT be used.

The rub is that WebCrypto apparently isn't enforcing this restriction, so we need to provide them syntax to express even the nonsensical combinations - hence the use of SHOULD rather than MUST above.

                                                            -- Mike

From: jose [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Tuesday, December 24, 2013 4:28 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] Two proposed JOSE spec actions to more closely coordinate with WebCrypto

John B.

On Dec 24, 2013, at 8:26 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

   o  "wrap" (encrypt key)

Comments?

                                                            -- Mike

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: John Bradley <[email-masked]>
Date: Tue, 24 Dec 2013 22:14:31 -0300

It was typical Canadian Sarcasm.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 27 Dec 2013 13:05:50 -0500

On Tue, Dec 24, 2013 at 7:56 PM, Mike Jones <[email-masked]>wrote:

> Multiple unrelated uses SHOULD NOT be specified for a key because of the
> potential vulnerabilities associated with using the same key with multiple
> algorithms.  So the combinations “sign” with “verify”, “encrypt” with
> “decrypt”, and “wrap” with “unwrap” are permitted, but other combinations
> SHOULD NOT be used.
>
>
>
> The rub is that WebCrypto apparently isn’t enforcing this restriction, so
> we need to provide them syntax to express even the nonsensical combinations
> – hence the use of SHOULD rather than MUST above.
>

If you're going to have that text, you might as well just make "use" the
array, and have the caveats apply there as well.  I would strongly prefer
that solution to creating a different, incompatible key usage field.

On issue (1), my preference would be to simply delete the implementation
requirements, but failing that, renaming to "JOSE implementation
requirements" or "JWS/JWE implementation requirements" seems OK.  If you
wanted to be extra clean, you could just move the implementation
requirements to a separate registry.

--Richard

>
>
>                                                             -- Mike
>
>
>
> *From:* jose [mailto:[email-masked]] *On Behalf Of *John Bradley
> *Sent:* Tuesday, December 24, 2013 4:28 PM
> *To:* Mike Jones
> *Cc:* [email-masked]
> *Subject:* Re: [jose] Two proposed JOSE spec actions to more closely
> coordinate with WebCrypto
>
>
>
> different key containing the same or different keys to do the same thing.
>
>
>
> 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#section-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/Overview.html#key-interface)
> values to be used directly with JWK.  The proposed definition is:
>
>
>
> *3.3.  "use_details" (Key Use Details) Parameter*
>
> 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.html and
> no objections were raised there that I’m aware of.
>
>
>

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 27 Dec 2013 14:13:14 -0800

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:
> > 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#section-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
> > fine-grained key usage information.  This would enable WebCrypto
> > KeyUsage
> > (https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#key-interface)
> > 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.
> >
> > http://lists.w3.org/Archives/Public/public-webcrypto/2013Dec/0052.html
> > and no objections were raised there that I’m aware of.
> >

---

From: Mike Jones <[email-masked]>
Date: Sat, 28 Dec 2013 01:58:55 +0000

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?)

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.

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

-----Original Message-----
From: Ryan Sleevi [mailto:[email-masked]] 
Sent: Friday, December 27, 2013 2:13 PM
To: John Bradley
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] Two proposed JOSE spec actions to more closely coordinate with WebCrypto

"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.
>
> > 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 
> >  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 
> > (https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.htm
> > l#key-interface) values to be used directly with JWK.  The proposed 
> > definition is:
> >
> > 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.
> >

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 27 Dec 2013 18:46:00 -0800

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.

---

From: Mike Jones <[email-masked]>
Date: Sat, 28 Dec 2013 03:50:27 +0000

It's my sense of the JOSE working group that most are strongly opposed to breaking changes at this point.  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".

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]; John Bradley; [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.

>  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.

>  "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 Dec 24, 2013, at 8:26 PM, Mike Jones 
> > <[email-masked]>
> >  wrote:
> >
> > > Hi all,
> > >
> > > like to propose the two JOSE spec actions to more closely 
> > > coordinate
> > with WebCrypto:
> > >
> > > Requirements" to "JOSE Implementation Requirements" in the JSON 
> > > Web Signature and Encryption Algorithms Registry 
> > > JWK (such as WebCrypto).  This changes only non-normative text and 
> > > is
> > non-breaking.
> > >
> > > l#key-interface) values to be used directly with JWK.  The 
> > > proposed definition is:
> > >
> > >    in the IANA JSON Web Key Use Details registry defined in 
> > > Section
> > 7.3.
> > > 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.
> > >
> > > Mike
> > > http://lists.w3.org/Archives/Public/public-webcrypto/2013Dec/0052.
> > > ht ml and no objections were raised there that I'm aware of.
> > >

---

From: Richard Barnes <[email-masked]>
Date: Sat, 28 Dec 2013 18:12:30 -0500

On Fri, Dec 27, 2013 at 10:50 PM, Mike Jones <[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

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
>
> 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.
>
> >
> > > > (

---

From: Tim Bray <[email-masked]>
Date: Sat, 28 Dec 2013 15:30:59 -0800

On Fri, Dec 27, 2013 at 7:50 PM, Mike Jones <[email-masked]>wrote:

> breaking changes at this point.  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".
>

As far as I know, the predominant JOSE-based construct that has widespread
deployment is JWT, and I agree that there has been pretty ferocious
resistance (from me among others) to breaking that, simply because it seems
to work well in practice.  I suspect that improvements which succeed in not
breaking the JWT installed base would get careful open-minded consideration.

---

From: John Bradley <[email-masked]>
Date: Sun, 29 Dec 2013 18:21:21 -0300

It seems that WC is wanting something that coverers future key disclosure given a secure (or at least logically separate element) performing the low level crypto operations.

On the wire with JOSE where in at-least one common use case the JWK is public and "use" is used to differentiate between public keys that could be used to sign or encrypt with the same alg (say PKCS#1.5) the current single element is sufficient and understood by at-least the SAML community.

If WC wants to prevent disclosure of keys from a key store to applications that is a diffrent use case and I can see using a separate element.  
I don't know that "use_details"  without locking down the alg as well will be sufficient.  Given that some one wanting to extract a key likely has the ability to submit chosen plain texts and alg if left open, I am guessing that keys will still be disclosed.   

I would prefer to think of meta-data for secure key storage as a separate issue from the on the wire use case.   That is likely why Mike is proposing two elements.

I think for storage and protection of symmetric keys especially the alg and modes of that alg need to be locked down otherwise we my windup with something that doesn't have the required security properties.

John B.

---

From: Mike Jones <[email-masked]>
Date: Mon, 30 Dec 2013 19:40:09 +0000

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.

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".

>  -- Deprecate "use", recommending that new applications use "ku"; if

> both  are present, "use" MUST be ignored.

>  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.

> > Cc: [email-masked]<mailto:[email-masked]>; John Bradley; [email-masked]<mailto:[email-masked]>

> > Subject: Re: [jose] Two proposed JOSE spec actions to more closely

> > >  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

> > >  For symmetric keys, Sign/Verify operations are actually the same,

> > > so in  that case, this is a distinction without a difference.

> > > 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?)

> > 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

> > 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

> > -

> > > distinctions, but also only use a single key with a single

> > > algorithm - therefore no security problem.

> > > simple things  simple and WebCrypto being a low-level API that

> > > tries

> > to

> > be complete.

> > 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.

> > 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.

> > >  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.

> > > 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.

> > > 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).

> > > 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)

> > > >  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.

> > > > <[email-masked]<mailto:[email-masked]>>

> > > > > participants about JWK usage by WebCrypto over the holidays,

> > > > > I'd like to propose the two JOSE spec actions to more closely

> > > > > 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

> > > > > 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

> > > > >    The "use_details" (key use details) member identifies

> > fine-grained

> > > > >    key use details values.  Values defined by this

> > > > > specification

> > are:

> > > > >    o  "decrypt" (decrypt content and verify decryption, if

> > applicable)

> > > > >    Other values MAY be used.  Key Use Details values can be

> > registered

> > > > >    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"

> > > > >    If both "use" and "use_details" JWK members are present,

> > > > > the

> > usages

> > > > >    specified by them MUST be consistent.  In particular, the "use"

> > > > value

> > > > >    "use" values are present, the "use" member SHOULD NOT be

> > present,

> > > > > 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"

> > > > > "signOnly,verifyOnly", which I believe is their current plan

> > > > > of

> > > > record.

> > > > > P.S.  This proposal was already discussed on the WebCrypto

> > > > > list in the thread

---

From: Axel Nennker <[email-masked]>
Date: Mon, 30 Dec 2013 20:57:01 +0100

I support Mike's proposal. I addresses WebCrypto's use cases and keeps the
spec backward compatible.

I am opposed to reinventing X509 in JSON (or other complicated specs)
http://en.wikipedia.org/wiki/X.509#Extensions_informing_a_specific_usage_of_a_certificate

use_details keeps it simple enough I think

-Axel

2013/12/30 Mike Jones <[email-masked]>

>  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]
>
> *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.
>
>
>
> 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
>
>
>
> >  <[email-masked]>wrote:
>
> >
>
> 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.
>
>
>
> > > From: Ryan Sleevi [mailto:[email-masked] <[email-masked]>]
>
> > > >  From: Ryan Sleevi [mailto:[email-masked]<[email-masked]>
> ]
>

---

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 30 Dec 2013 10:25:27 -0800

> > > simple things  simple and WebCrypto being a low-level API that tries
> > to
> > be complete.
> > > But they're  designed to address different goals for different kinds
> > of
> > applications.
> > still
> > > sign and verify (or MAC and  verify, if you prefer, but we're
> > splitting
> > hairs here).
> > >

---

From: Mike Jones <[email-masked]>
Date: Mon, 30 Dec 2013 21:11:21 +0000

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),
>  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.

>  operations for a key.  That's part of why I proposed adding "use_details",
>  different treatment of the "use" field (ignoring it).  My proposal is not
>  a breaking change, since "use" continues to mean what it always has.
>  Richard's proposal does.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 30 Dec 2013 12:47:08 -0800

Mike,

---

From: Mike Jones <[email-masked]>
Date: Mon, 30 Dec 2013 21:29:08 +0000

... 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.
________________________________
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

-- Mike

Mike,

---

From: John Bradley <[email-masked]>
Date: Mon, 30 Dec 2013 18:55:05 -0300

Right,   I do think that they are quite different use cases.  and unlikely to be used together. 

use is intended to disambiguate between public keys (generally publicly published or at-least not secret) that can be used for multiple operations such as signing or encryption.

use_details seems to be more meta data about keys that are transmitted confidentially (probably encrypted with some master key) to a HSM or secure storage device that will then use that meta-data to control what operations can be performed in the HSM environment and if the key can be extracted by the run time environment.   If the key is extractable then the limits are advisory as opposed to enforced by the storage.

The two seem quite different,  from experience we have a good handle on "use" I think.  Meta-data for key management and provisioning like KMIP http://en.wikipedia.org/wiki/Key_Management_Interoperability_Protocol is a large ball of wax that should not be underestimated.  
I am assuming that the Web Crypto WG has worked through all the issues and has decided that a single element holding an array is going to work for them.

Re-using JWK seems like a perfectly fine idea.  However I don't think overloading the one element to do do both things is going help interoperability.

I would even suggest that use_details might be clearer if it were called secure_storeage_use or something along that line.

John B.

On Dec 30, 2013, at 6:29 PM, Mike Jones <[email-masked]> wrote:

> From: Mike Jones
> To: [email-masked]
> Cc: Richard Barnes; John Bradley; [email-masked]
> From: Ryan Sleevi
> Cc: [email-masked]; Richard Barnes; John Bradley; [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Mon, 30 Dec 2013 22:34:19 +0000

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<mailto:[email-masked]>
Sent: ‎12/‎30/‎2013 1:55 PM
To: Mike Jones<mailto:[email-masked]>
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]>
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.

>  Sent: ý12/ý30/ý2013 1:12 PM
>  Cc: Richard Barnes<mailto:[email-masked]>; John
>  Bradley<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>  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
>  Sent: ý12/ý30/ý2013 12:47 PM
>  Cc: [email-masked]<mailto:[email-masked]>; Richard
>  Barnes<mailto:[email-masked]>; John Bradley<mailto:[email-masked]>;
> >                                                              Best
> > wishes,
> > > > > the same  algorithm with the same key - just in a
> > producer/consumer
> > > role.
> >
> > > > > having both simple and  detailed key usage representations seems
> > odd
> > > at first.
> >
> > > > > > that is not a good idea,  and making it easy makes people think
> > it
> > > is a good idea.
> >
> > > > > >
> >

---

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 30 Dec 2013 13:55:07 -0800

---

From: Richard Barnes <[email-masked]>
Date: Tue, 31 Dec 2013 12:03:11 -0500

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:

>   ------------------------------
> 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]
>
> >  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]>>
> > >  simpler for consumers of JWKs use than requiring conditional
> behaviors,
> > > as
> > >  Richard's proposal does.
> > >
> > >
> > >
> > >                                                              Best
> > > wishes,
> > >
> > >                                                              -- Mike
> > >
> > >
> > >
> > > >  <[email-masked]<mailto:[email-masked]
> >>wrote:
> > >
> > > >
> > >
> > > > > Cc: [email-masked]<mailto:[email-masked]>; John
> Bradley;
> > > > [email-masked]<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
> > >
> > > > > > > >    details the intended use of the key.  Its value is an
> array
> > > > of
> > >
> > > > > > > > [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: Richard Barnes <[email-masked]>
Date: Tue, 31 Dec 2013 12:08:11 -0500

On Mon, Dec 30, 2013 at 2:40 PM, Mike Jones <[email-masked]>wrote:

> different treatment of the "use" field (ignoring it).
>
Fair enough.  This revised proposal is not a breaking change:
 -- 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"
-- Define the expansion of "use" values to "ku" values
** If both "ku" and "use" are present, then recipients use the union of the
two

That way, both "ku" and "use" are positive grants of permission, and they
combine.  This solution "fails safe" in the sense that if a recipient
doesn't support one or the other, then at worst it will not allow a key to
be used for a given purpose.

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.
>
Nope nope nope.  Requiring consistent behavior is a terrible idea, because
then you have to specify what a recipient does if they're not consistent.
The above revised proposal is deterministic (not conditional; just take the
union), not a breaking change, and doesn't have this brittleness.

--Richard

---

From: Mike Jones <[email-masked]>
Date: Tue, 31 Dec 2013 19:18:03 +0000

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]<mailto:[email-masked]>> wrote:
There's nothing wrong with different use cases with different needs supplying different key metadata.

>  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]>
> >