It seems the choice is between (mod, xpo) and (n, e). A number of people have already expressed a preference for the latter. What do others think? -- Mike P.S. I'm sending this message from this address because it bounced when I tried to send it from my regular e-mail address. Please continue interacting with me at my regular e-mail address [email protected]: [email protected] To: [email protected] Date: Fri, 19 Oct 2012 11:46:52 +0200 CC: [email protected] Subject: Re: [jose] xpo
Structure means “more bytes”. I guess that was the reason to go for xpo. (I cannot find the arguments on the mailing list) I changed my mind: Although I don’t like xpo I think that instead of going back we should now live with xpo. Changing any implementation to understand xpo is not that much work.And it is better to minimize breaking changes. Axel From: Manger, James H [mailto:[email protected]] Sent: Friday, October 19, 2012 9:18 AM To: Nennker, Axel; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: RE: [jose] xpo “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. --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 expCase3: 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 Sent: Wednesday, October 17, 2012 3:09 PM To: Vladimir Dzhuvinov / NimbusDS Cc: [email protected] Subject: Re: [jose] xpo +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 -- Vladimir Dzhuvinov : www.NimbusDS.com : [email protected] -------- Original Message -------- Subject: Re: [jose] xpo From: Richard Barnes <[email protected]> Date: Wed, October 17, 2012 12:15 am To: "Manger, James H" <[email protected]> Cc: Mike Jones <[email protected]>, "[email protected]" <[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 _______________________________________________ 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
