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

On Jun 17, 2014 4:01 PM, "Mike Jones" <Michael.Jones@microsoft.com> wrote:
>
> If Mark agrees with you, at a minimum, these kinds of usage assumptions
(such as uniqueness, being a hardware abstraction, etc.) motivating the
choice of data structure should be described in the spec.
>
>
>
> If he does agree that it needs to remain an encoded representation of an
octet sequence, I’ll file a separate bug, which is that it should be
base64url encoded, rather than base64 encoded, since WebCrypto
implementations will already be using base64url encoding in other contexts
but aren’t elsewhere using base64 encoding.
>

No, they aren't, outside of import/export, so I would similarly object to
such a bug as being unnecessary and hostile (towards use of btoa/atob)

>
>
>                                                                 -- Mike
>
>
>
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Tuesday, June 17, 2014 3:55 PM
> To: Mike Jones
> Cc: public-webcrypto@w3.org
> Subject: RE: [Bug 26123] New: Key ID definition should be aligned with
JWK kid definition
>
>
>
>
> 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.