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 00:29:29 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-27814-7213-0PeFnd6j8Z@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27814

--- Comment #8 from jimsch <ietf@augustcellars.com> ---
I happen to disagree.  I believe that the argument "because JOSE says so" is
the strongest possible argument that can be made.  The argument goes along the
lines of:

JOSE defined the JWK structure.
JOSE defined the "use" parameter within that structure.
JOSE defined the value of the "use" parameter for types of type "EC".
WebCrypto should follow the standard produced by the JOSE group.

Compared to this argument, any other argument is in my opinion extremely weak. 
If you don't accept this argument then I don't think we would ever be able to
reach an agreement.

If you would prefer that the bug be filed against the JWK import of ECDH keys
(there is no jwk import for DH so it would not apply there yet), I am willing
to make that change.  I don't see that it changes any of the base arguments
what the title is.  The text of the initial bug says that this needs to be done
as well.

I am not sure what the purpose of Appendix A.2 is.  It appears to me to make a
statement on what the meaning of the JWK "use" value are in terms of the
WebCrypto "usage" parameter.  However, I note that this is non-normative so the
fact that it does not include the deriveBits and deriveKey values can be
ignored.  I guess that means that I would not care if this gets fixed as long
as the algorithm specific methods get fixed.

I agree that, in the event that allowing a jwk import for any of the KDF
algorithms is permitted, then the question of what enc means.  However, in this
case I would not have any specific argument that can be made.  I would say that
WebCrypto could make any statement that it desired as the JOSE documents are
silent in this instance.

I find the argument you make about the fact that WebCrypto does not tag a use
at export time to be weak.  I would never expect that WebCrypto would ever
define a use parameter on export.  It should only use the key_ops parameter as
this has much better security properties.  I could extend your argument to be -
since we never export a jwk with a use parameter, we should never import one
which has the parameter set.  Is that your intent?

I don't expect that the WebCrypto group would ever define RSA-KEM
(http://tools.ietf.org/html/rfc5990 and ASN-X9.44) as one of its algorithms,
but it is not immediately clear if the correct set of usages for this algorithm
is encrypt/decrypt or deriveBits/deriveKeys (returning both the encrypted
secret and the derived bits/key).   This means that there is a possibility
(however remote) that a use of enc is the wrong value for an RSA key as well as
an EC key.  

The main reason for using KEM rather than OAEP is that the security proofs are
so much better with KEM.  There are real tight proofs for KEM.  As an aside, it
is also a demonstration for Mark as to why one does not want to put an upper
limit on the amount of entropy that can be given to a KDF algorithm.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 15 January 2015 00:29:30 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 January 2015 00:29:31 UTC