RE: [Bug 26123] New: Key ID definition should be aligned with JWK kid definition

I should add that the NamedKey "name" is far more applicable to the JWK
"kid" than NamedKey's "id" - in use, purpose, and format - but I would
still object to requiring alignment.

That is, we would not file bugs against Microsoft's CNG KSP for using GUIDs
as key identifiers, nor against Apple's Keychain API for using uint32s as
the identifiers; nor should Web Crypto, as an API, be limited to conform to
the choices JOSE has made.

Let's not forget we have already made a variety of other divergences from
JOSE, most notably in the min/max security requirements for keys (eg: 1024
bit keys are legal in Web Crypto)
On Jun 17, 2014 3:55 PM, "Ryan Sleevi" <sleevi@google.com> wrote:

>
> On Jun 17, 2014 3:38 PM, "Mike Jones" <Michael.Jones@microsoft.com> wrote:
> >
> > To the extent that the WebCrypto specs use two values that are described
> as being key identifiers, the onus should be on the working group to make
> the case why they need to be incompatible with one other.
>
> Respectfully, I cannot agree with you at all on this point.
>
> The Web Crypto API is not a JOSE API. This has been repeatedly reaffirmed.
> The removal of aliases further underscores this - they are not meant to be
> 1:1 mappings.
>
> Just because two things look the same, on an abstract level, does not for
> a second mean they have the same purpose or requirements.
>
> >  No, they aren’t the same thing, but I can easily picture use cases
> where it would be convenient to use the same Key ID value in both places.
> >
>
> I seriously doubt this in practice, given the use cases Mark has laid out,
> but sure, for situations in this hypothetical, one can imagine.
>
> >
> >
> > The problem is that while one is a string, one is a base64 encoded
> representation of an octet sequence with a bounded size.  (They’re reusable
> in one direction, but not the other.)  Is there some good reason why both
> can’t just be strings?
> >
>
> Because they identify different things and for different purposes.
>
> The jwk kid is useful for JOSE systems, and in particular JWE/JWS/JWT, and
> relate to JOSE-using protocols.
>
> The NamedKey API is a UA/Hardware abstraction, meant not for JWKs but for
> software developers interacting with the API.
>
> The two are apples and oranges, orthogonal in both purpose and use.
>
> This is the same discussion we have had on Algorithm Names - Web Crypto is
> designed for *API* and programmatic usage, JOSE is designed for
> serialization.
>
> Mark had favored a particular hardware implementation/design space, as
> covered in the F2F. NamedKey IDs are globally unique (eg: no two UAs will
> have the same NamedKey, or at least, that's the plan), whereas JWK kids are
> symbolic identifiers that are tied to a specific context and protocol
> message exchange.
>
> NamedKey IDs are generally assigned out of band by a service provider, and
> identify user as much as user agent, whereas JWK key IDs are generally
> symbolic and lack such context (eg: they contain a date, or a friendly
> name, or a name like 'Mike's encryption key')
>
> Different purposes. Different definitions.
>
> Further, the use of KID is not at all coupled to requiring named key
> discovery. JOSE applications would far more likely use WebCrypto
> CryptoKeys, and store things like kid as supplemental data in their long
> term storage (eg: as the key identifier within IDB).
>
> >
> >
> >                                                                 -- Mike
> >
> >
> >
> > From: Ryan Sleevi [mailto:sleevi@google.com]
> > Sent: Tuesday, June 17, 2014 3:28 PM
> > To: bugzilla@jessica.w3.org
> > Cc: public-webcrypto@w3.org; Mike Jones
> > Subject: Re: [Bug 26123] New: Key ID definition should be aligned with
> JWK kid definition
> >
> >
> >
> > Mike,
> >
> > Can you explain why they should be aligned?
> >
> > Named Key and kid have no relationship. Deserializing a JWK with a kid
> does not yield a NamedKey, and serializing a NamedKey doesn't result in a
> JWK with kid set.
> >
> > Further, their use of id concepts are for separate purposes.
> >
> > While I have little personal interest in NamedKey, this seems like an
> unnecessary/unwarranted change.
> >
> > If kid is going to be handled, you'd do it at the application layer -
> named key or not - and it would not work with wrap/unwrap.
> >
> > Note that CryptoKey (not NamedKey) are equally not meant to be 1:1
> relationships with JWK. They are independent.
>