[Bug 27814] Section A.2 - the usage mapping of "enc" is incorrect

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27814

--- Comment #14 from jimsch <ietf@augustcellars.com> ---
(In reply to Ryan Sleevi from comment #13)
> (In reply to jimsch from comment #12)
> > I don't think it would make them any more unhappy than what it currently is
> > doing.  After all complete rejection is easier to code for.
> 
> Which is what is currently specced, and which you seem unhappy about, thus
> this comment leaves me quite confused as to what your desired outcome is now.

Oh - but the next step is to say - since you always error on it, why not just
ignore it because it is "application" data and not something that you should be
enforcing.

> 
> In case it isn't clear, I'm mildly supportive of the outcome, but I'm trying
> to make sure we have sound documentation that's clear - in the context of
> Web Crypto. The argument that "JOSE said so" doesn't really provide much
> guidance, nor is it entirely consistent with other decisions (e.g. algorithm
> names, composites), which is why I'm trying to unpack
> 
> 1) What the developer experience is, today, when writing a JOSE impl. using
> WebCrypto?

That is more or less what I have been doing.  What I am writing is not exactly
JOSE but is almost identical.

> 2) If the spec does not change at all, what use cases are eliminated?

I would say that the JOSE use case is harmed, but not eliminated.  I would say
the same thing if the jwk import format was completely eliminated.

> 3) If the spec does not change at all, what benefits are gained?

none that I know of.

> 4) When will this situation come up, if at all?

The question is one of who do you believe is going to do the import of a key
into the system.  Is it always going to be a piece of library code or is the
user going to want to do it on a regular basis.  If it is always library code,
then that code can be written one and always used.  On the other hand if users
are going to want to write the code so they can do once imports and then use
the key object for the calls to the library then it will affect any user that
runs across an EC key with a use of "enc".   There is no way of knowing how
consistently this will be done at present.

Of the fields currently defined by the JWK specification, the one one I know of
that will be enforced differently than document is the use parameter for an EC
encryption designated key.  The "alg" parameter is not enforced for this case,
it is only enforced for those cases where it is used to extract additional
information - either a key length, a hash length or a curve.

> 
> I think these are all solid criteria, and this discussion has mostly been
> trying to answer these, so that it's clear *why* we're changing in a way
> that can cause interop issues.
>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 15 January 2015 18:40:46 UTC