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 protected]> > 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 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]>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] <[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]<[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#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] > > > > > > > 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 > > > > > > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
