On Mon, December 30, 2013 11:40 am, Mike Jones wrote: > As further background for the discussion, the current "use" definition is > based on widely deployed existing practice - the SAML metadata > specification > (http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf), > which defines "use" as follows in section 2.4.1.1: > use [Optional] > Optional attribute specifying the purpose of the key being described. > Values are drawn from the > > KeyTypes enumeration, and consist of the values encryption and signing. > > > > This has been shown to be sufficient in practice for its intended purpose, > as has the JWK "use" field. >
Mike, I feel like you're arguing all the more strongly for WebCrypto not to use JWK, in that you're arguing that JWK's "intended purpose" is to match SAML. I can understand where this fits within the JWT and OpenID Connect workflows, but as a "JSON key description" format, it is unquestionably much more restrictive and ill-suited. If the goal is to continue to evolve JWK to parallel the SAML workflows, then I don't see how WebCrypto can in good conscience encourage JWK. There's nothing preventing authors from translating JWK into any sort of API form that WebCrypto requires - much in the same way that they can translate the composite JWA algorithms (which are suitable for transport) into WebCrypto's broader, more generic algorithms (which are suitable for an API targeting application development). Arguably, the only reasons to use JWK are to prevent introducing "yet another key format". While laudable, if JWK is trying to mirror SAML, then it would seem that JWK is not trying to be a key format, per se, and such risk would be low. Again, I'm perfectly fine if JOSE would rather that JWK be kept as minimal and as specific for the JWT use case, and we can easily use a descriptive WebIDL within WebCrypto to describe the key formats it operates with (in addition to SPKI and PKCS#8). Comments so far from this WG give me the sense that there's strong opposition by some to seeing JWK evolve to be as flexible or generic as SPKI/PKCS#8. That's fine by me, but that's extensibility that WebCrypto wants, and if JWK isn't it, we can use something else. OpenID Connect and JWT can continue to use JWK as suited for their needs, and if for some reason someone wants to use JS to interact with these, they can use a translation shim, just as they would for JWE/JWS or for *any other* cryptographic application, since WebCrypto is "just" an API. > > > I understand your point, Ryan, that for the WebCrypto API use case, there > is sometimes value in distinguishing between the producer and consumer > operations for a key. That's part of why I proposed adding "use_details", > so those distinctions can be made for the use cases where they do make a > difference. > > > > As for Richard's proposal, the problem with it is that it would be a > breaking change, since if "ku" was present, his proposal would require > different treatment of the "use" field (ignoring it). My proposal is not > a breaking change, since "use" continues to mean what it always has. > Furthermore, my proposal requires that "use" and "use_details" convey > consistent information, if both are present. That seems significantly > simpler for consumers of JWKs use than requiring conditional behaviors, as > Richard's proposal does. > > > > Best wishes, > > -- Mike > > > > -----Original Message----- > From: Ryan Sleevi [mailto:[email protected]] > Sent: Monday, December 30, 2013 10:25 AM > To: Richard Barnes > Cc: Mike Jones; [email protected]; John Bradley; [email protected] > 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 protected]<mailto:[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 > > > > As I expressed within WebCrypto, this to me strikes a much more sensible > balance of backwards compatibility and extensibility, and hopefully in a > way that allows existing deployments to cleanly transition while allowing > new deployments to avoid the limitations of the current drafts. > > > > I very much prefer this over use_details for Web Crypto's use cases. > > > > > > > > I believe my proposal is the best-available solution, given the > > > current > > > > realistic constraints. It might have made better sense for a > > > > WebCrypto spec to define "use_details" than JOSE, but if WebCrypto > > > > isn't going to do it, I believe that we'll all be better off in the > > > > long run if JOSE then does and WebCrypto uses it. > > > > > > > > Cheers, > > > > -- Mike > > > > > > > > -----Original Message----- > > > > From: Ryan Sleevi [mailto:[email protected]] > > > > Sent: Friday, December 27, 2013 6:46 PM > > > > To: Mike Jones > > > > Cc: [email protected]<mailto:[email protected]>; John Bradley; > > [email protected]<mailto:[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]<mailto:[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]<mailto:[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#se > > > > ction-7.1 > > > > ). > > > > > > > This will make it clearer that the Implementation > > > > > > > Requirements apply only to JWS and JWE implementations - and > > > > > > > not other uses of JWK (such as WebCrypto). This changes only > > > > > > > non-normative text and is > > > > > > non-breaking. > > > > > > > > > > > > > > 2. Define the new JWK field "use_details" for recording > > > > > > > intended fine-grained key usage information. This would > > > > > > > enable WebCrypto KeyUsage > > > > > > > (https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overvi > > > > > > > ew.h > > > > > > > tm > > > > > > > l#key-interface) values to be used directly with JWK. The > > > > > > > proposed definition is: > > > > > > > > > > > > > > 3.3. "use_details" (Key Use Details) Parameter > > > > > > > The "use_details" (key use details) member identifies > > > > fine-grained > > > > > > > details the intended use of the key. Its value is an array > > of > > > > > > > key use details values. Values defined by this > > > > > > > specification > > > > are: > > > > > > > > > > > > > > o "sign" (compute signature or MAC) > > > > > > > o "verify" (verify signature or MAC) > > > > > > > o "encrypt" (encrypt content) > > > > > > > o "decrypt" (decrypt content and verify decryption, if > > > > applicable) > > > > > > > o "wrap" (encrypt key) > > > > > > > o "unwrap" (decrypt key and verify decryption, if > > applicable) > > > > > > > o "deriveKey" (derive key) > > > > > > > o "deriveBits" (derive bits not to be used as a key) > > > > > > > > > > > > > > Other values MAY be used. Key Use Details values can be > > > > registered > > > > > > > in the IANA JSON Web Key Use Details registry defined in > > > > > > > Section > > > > > > 7.3. > > > > > > > The use details values are case-sensitive strings. > > > > > > > Duplicate use details values MUST NOT be present in the > > array. > > > > > > > Use of the "use_details" member is OPTIONAL, unless the > > > > application > > > > > > > requires use this member to record fine-grained key usage > > > > details. > > > > > > > (Note that the "use_details" values intentionally match the > > > > > > > "KeyUsage" > > > > > > > values defined in the WebCrypto [WebCrypto] specification.) > > > > > > > > > > > > > > If both "use" and "use_details" JWK members are present, > > > > > > > the > > > > usages > > > > > > > specified by them MUST be consistent. In particular, the > > "use" > > > > > > value > > > > > > > "sig" corresponds to "sign" and/or "verify". The "use" value > > > > > > > "enc" corresponds to all other values defined above. > > > > > > > If "use_details" values corresponding to both "sig" and "enc" > > > > > > > "use" values are present, the "use" member SHOULD NOT be > > > > present, > > > > > > > and if present, its value MUST NOT be either "sig" or "enc". > > > > > > > > > > > > > > This is a non-breaking change - allowing simple applications > > > > > > > that want to distinguish between signing and encryption > > > > > > > operations to continue doing so as they do today, while also > > > > > > > providing a multi-valued key usage details field to be used by > > > > > > > applications that want to record fine-grained distinctions > > > > > > > among potential key usages, including distinguishing between > > > > > > > producer and consumer > > > > operations. > > > > > > > > > > > > > > As I see it, while having two related key usage > > > > > > > representations isn't ideal, it's far better than having > > WebCrypto overload "use" > > > > > > > with multi-valued values encoded in strings, such as > > > > > > > "signOnly,verifyOnly", which I believe is their current plan > > > > > > > of > > > > > > record. > > > > > > > > > > > > > > Comments? > > > > > > > > > > > > > > -- > > > > > > > Mike > > > > > > > > > > > > > > P.S. This proposal was already discussed on the WebCrypto > > > > > > > list in the thread > > > > > > > http://lists.w3.org/Archives/Public/public-webcrypto/2013Dec/0052. > > > > > > > ht ml and no objections were raised there that I'm aware of. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > jose mailing list > > > > > > > [email protected]<mailto:[email protected]> > > > > > > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > > > > > _______________________________________________ > > > > > > jose mailing list > > > > > > [email protected]<mailto:[email protected]> > > > > > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > jose mailing list > > > > > [email protected]<mailto:[email protected]> > > > > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > > > > > > _______________________________________________ > > > > jose mailing list > > > > [email protected]<mailto:[email protected]> > > > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > _______________________________________________ > > > jose mailing list > > > [email protected]<mailto:[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
