Seems strange to insist on a flat structure when the reason for choosing JSON was that we got a richer structure than name value pairs.
Having this be an object with its own attributes makes it clear that a number of parameters all belong together and is easier to move them around together in implementations. Also, I would REALLY like to see the parameters have single purpose across JWE and JWS. It makes debugging an implementation much easier. One does not have to have other context to know what a parameter means. Speaking from experience here. :) -- Dick On Oct 23, 2012, at 4:47 PM, "Manger, James H" <[email protected]> wrote: > Mike is right that with only a handful or so parameters we could muddle > through with a flat structure. The fact that we have already had a clash > ("exp") is annoying, and not a good sign about the flat structure, but we > could muddle through anyway. A parameter registry is supposed to help. > > But there are already other problems... > JWK [section 4. "JSON Web Key (JWK) Format"; section 6.1.1. "Registration > Template"] says parameters should be registered; says different kinds of key > can use the same parameter name for kind-specific parameters; and establishes > a registry that assumes parameter names are unambiguous. Those three points > cannot all work together. > > For instance, an elliptic curve key can use "y" for the x-coordinate of a > point; while a > DSA key could use "y" for the public key (an integer). What goes in the > registry? > > The "exp" clash theoretically isn’t a clash anyway, since the JWK parameter > registry is *separate* from the JWE/JWS header parameter registry. Of course > we don't want different names for the same sort of metadata in JWS & JWK -- > that would be annoying. This suggests we have arranged the registries > incorrectly. > > You can also see this issue in JWE & JWS. They share a common registry: "JSON > Web Signature and Encryption header Parameters Registry" [JWS section 7.1]. > JWS puts "kid" in this registry, pointing to JWS section 4.1.7. where it is > defined as an identifier for the originator's key. JWE puts the same name > "kid" in the same registry, but points it to JWE section 4.1.10. where it is > defined as an identifier for the recipient's key. Ugh? What will go in the > registry? What happens when an originator and recipient key are both involved? > > > Perhaps this mess can be sorted out by putting more care into which > registries are defined and what details go into them. Perhaps a parameter > registry that is common for JWE/JWS/JWK, but allows names to be registered > that (instead of pointing to one definition for the parameter) mark that > parameter as dependant on the value of, say, the "alg" value in the same > context? > > Actually, this sounds more complex than just using some structure in the > messages. > > -- > James Manger > > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Mike Jones >> Sent: Tuesday, 23 October 2012 7:33 PM >> To: [email protected] >> Subject: Re: [jose] xpo >> >> Scoping would make sense if we anticipated there being many many key >> parameters in the future, such that future naming conflicts were >> likely. In practice, there are all of eight key parameters defined at >> present ("alg", "crv", "x", "y", "mod", "xpo", "use", and "kid"). I've >> heard discussions of maybe one or two more that people might anticipate >> adding in the future (expiration time is the only one I can remember >> off the top of my head). So at least within the next few years, the >> number might reach a dozen or so. And we already have a registry >> defined that would avoid parameter conflicts. >> >> Adding structure to avoid potential conflicts among at most a dozen or >> so parameter names seems like significant overkill. In the spirit of >> keeping simple things simple, in practice, I'm sure that a flat >> structure will continue to work out just fine. >> >> Cheers, >> -- Mike >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Richard Barnes >> Sent: Monday, October 22, 2012 1:52 PM >> To: Manger, James H >> Cc: [email protected]; [email protected]; [email protected]; >> [email protected]; [email protected] >> Subject: Re: [jose] xpo >> >> >> On Oct 19, 2012, at 3:18 AM, Manger, James H wrote: >> >>> "exp" wouldn't clash if we used some JSON structure in a JWK. For >> instance, separate the maths fields of the public key (n, e, ...) from >> the administrative parts (key-id, certificate, usage...). Instead, JWK >> goes for a flat bucket for all a key's info. Hence, we have potential >> problems with clashes of names from quite separate domains. We should >> fix the structure, instead of tinkering with the name. >> >> Yes. This. >> >> Most of this WG's problems arise from using flat buckets. Flat buckets >> don't hold water :) >> >> --Richard >> >> >> >> >> >>> >>> -- >>> James Manger >>> >>> From: [email protected] [mailto:[email protected]] On Behalf >> Of [email protected] >>> Sent: Friday, 19 October 2012 5:50 PM >>> To: [email protected] >>> Cc: [email protected]; [email protected]; >> [email protected] >>> Subject: Re: [jose] xpo >>> >>> I don't know why the exp in jwk needs to be changed. From a developer >> POW there is no need. You always know which "exp" is the right one. >>> I would reverse the change from exp to xpo. Developers don't need it >> and many did not update their implementation to incorporate the exp- >>> xpo transition. >>> >>> Actually I don't care (much) how the parameters are named. Although I >> would like to stick to the 3-letter scheme I am OK with the n,e >> proposal. >>> But please stop making breaking changes (especially renaming >> parameters which leads only to more work and no gain). >>> >>> Case1: harm is already done -> stick with xpo and don't change AGAIN. >>> Case2: Most implementation haven't changed yet -> revert to exp >>> Case3: xpo is just stupid -> n,e is better -> another change -> Oh no >> -> revert to exp >>> >>> Again: I suggest to revert to exp and make the implementers happy. >>> >>> Axel >>> >>> Cc'ing Nat because I don't want to give away his developer's emails >> without asking. >>> >>> >>> From: [email protected] [mailto:[email protected]] On Behalf >> Of Brian Campbell >>> >>> +1 (if a parameter name change is going to happen anyway) >>> >>> On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS >> <[email protected]> wrote: >>> +1 >>> >>> -------- Original Message -------- >>> From: Richard Barnes <[email protected]> >>> >>> +1 >>> >>> On Oct 16, 2012, at 6:55 PM, Manger, James H wrote: >>> >>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 >>>>> * Changed the name of the JWK RSA exponent parameter from exp to >> xpo so as to allow the potential use of the name exp for a future >> extension that might define an expiration parameter for keys. (The exp >> name is already used for this purpose in the JWT specification.) >>>> >>>> "n" and "e" would be better than "mod" and "xpo". >>>> "n" and "e" are very widely used for the RSA modulus and public >> exponent. >>>> >>>> s^e = m mod n >>>> >>>> -- >>>> James Manger > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
