- From: <bugzilla@jessica.w3.org>
- Date: Thu, 15 Jan 2015 00:29:29 +0000
- To: public-webcrypto@w3.org
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