W3C home > Mailing lists > Public > public-webcrypto@w3.org > January 2015

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

From: <bugzilla@jessica.w3.org>
Date: Thu, 15 Jan 2015 07:44:05 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-27814-7213-o8fKkpKsgq@http.www.w3.org/Bugs/Public/>

--- Comment #13 from Ryan Sleevi <sleevi@google.com> ---
(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.

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
2) If the spec does not change at all, what use cases are eliminated?
3) If the spec does not change at all, what benefits are gained?
4) When will this situation come up, if at all?

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.

> I would never call this a key agreement scheme - it does not involve two
> keys so that would be impossible.  I would call it a scheme that is doing
> key derivation of a secret with a KDF algorithm.  I think that is a very
> different beast.

OK. I'm just going to have to strongly disagree with you, but this is moot
since no one is proposing RSA-KEM be added. I think it's likely sufficient to
say that I still disagree on it being a KDF, but that's really best saved for a
discussion of how to express RSA-KEM if and when it was exposed (and the reason
why it wasn't, in this version, is already documented in this group archives).

You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 15 January 2015 07:44:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 January 2015 07:44:10 UTC