Hi James,
In the JWK case you cite below, both uses of the name "y" would go into the
registry. This would not be a conflict, as their use is differentiated by the
"alg" parameter value. This is already the intent of the spec, but I'll be
sure to re-read and review this language in the next round of revisions to make
sure that this use of the registry is clearly called out as legal and intended.
Likewise, in the second case you cite, the JSON Web Signature and Encryption
Header Parameters registry already makes it clear that "The same Header
Parameter Name may be registered multiple times, provided that the parameter
usage is compatible between the specifications." There is no conflict.
We have no sets of algorithm combinations that take multiple independent keys
as inputs, so there is no need for two "kid" parameters in any header.
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Manger,
James H
Sent: Tuesday, October 23, 2012 4:48 PM
To: Mike Jones; [email protected]
Subject: Re: [jose] xpo
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
