On Fri, Dec 27, 2013 at 10:50 PM, Mike Jones <[email protected]>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 > > -----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 >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
