On Mar 20, 2013, at 8:01 AM, Richard Barnes <[email protected]> wrote: > 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. >
Basically this.
> 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).
>
>
One way or another (-:
- m&m
Matt Miller < [email protected] >
Cisco Systems, Inc.
> 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
>>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
