I think what Matt was asking was less about how the recipient of an object
knows which fields the sender considers private, and more about how a
sender knows which fields he should mark as private. A naïve reader might
not realize that the "d" component needs to be in the private section, for
example.
I do think the idea of splitting private and public makes sense, but only
really in the context of key wrapping -- private things go inside the
wrapping, and public things outside ("wk" and "kat" in the terms of my
slides at IETF86).
--Richard
On Wed, Mar 20, 2013 at 12:38 AM, Manger, James H <
[email protected]> wrote:
> > 2) Should JWK parameters be marked as private (confidential, secret,
> > privileged, etc etc)? The current documentation set loosely defines
> > this only because they are current split between multiple documents.
> > However, I wonder if there is value in being much more explicit about
> > it, including in a parameter's registration.
>
> Yes, but not with a registry flag.
> Putting the private values in a separate sub-object would be better (eg
> "pri":{"d":...}). It would allow you to notice private values without
> needing to know every key type (or looking up a registry).
>
>
> > 1) Should JWK parameter names be absolutely unique, or are they
> > potentially tied to a specific JWK type? In looking at the specs to
> > date, I think there's only one case where a parameter name is re-used
> > ("d" for both private RSA and ECC keys); currently syntactically and
> > semantically identical, but I'm not sure that's adequate.
>
> If private components are in a "pri" field and public components (and
> common parameters such as a elliptic curve id) are in a "pub" field, then
> it is fairly obvious that these components depend on the type of key so
> there is no need to have a registry for them -- just register key types.
>
> --
> 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
