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 protected]]
Sent: Friday, December 27, 2013 6:46 PM
To: Mike Jones
Cc: [email protected]; John Bradley; [email protected]
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 protected]]
> Sent: Friday, December 27, 2013 2:13 PM
> To: John Bradley
> Cc: Mike Jones; [email protected]
> 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 protected]>
> > 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.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 protected]
> > > https://www.ietf.org/mailman/listinfo/jose
> >
> > _______________________________________________
> > jose mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/jose
> >
>
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
