- From: Mark Watson <watsonm@netflix.com>
- Date: Fri, 7 Feb 2014 17:57:36 -0800
- To: Ryan Sleevi <sleevi@google.com>
- Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <-4939766020437023821@unknownmsgid>
Sent from my iPhone On Feb 7, 2014, at 5:11 PM, Ryan Sleevi <sleevi@google.com> wrote: On Fri, Feb 7, 2014 at 4:52 PM, Mark Watson <watsonm@netflix.com> wrote: > All, > > I have made some proposals for the algorithm procedures for several of our > algorithms in the Editor's Draft: RSA-ES, RSA-SSA, RSA-PSS, RSA-OAEP and > ECDH. There are some open issues noted in the specification proposals. > > During this process I have also tried to improve the linkage between the > method specifications and the algorithm procedures. The method > specifications now explicitly say how method parameters are mapped to the > input variables for the algorithm procedures. > > Some notable points which came up: > - I assumed that when generating a key pair the public key would always > have extractable = true > I believe this has come up now twice on calls and definitely during the F2F, and that matches the agreement. > - Throughput the spec we often "terminate with an error" without saying > which error. I assume we will want to go through and define the errors at > some point > Only if they demonstrate some developer error that could have succeeded. In general, with crypto, errors leak state, which is why the spec has explicitly avoided introducing new errors. When it has been discussed adding errors, I've repeatedly requested that proponents attempt to list the errors and how they can allow the developer to take a different action. I'm very much opposed to introducing a ton of new errors, so we should definitely discuss any proposals on the list. I meant we should say which of the _existing_ errors is returned in each case. If there is only one existing error, I take it back. > - We will need to specify how the bits which result from various > deriveKey operations (e.g. ECDH) are turned into a key for the specified > derived key algorithm > Can you expand what you mean by this? It's treated as a raw import. If you mean having the caller specify bits, we've been over this multiple times during the F2F that we're not going to try and provide some API for callers to say "The first 128 odd bits only" or "bits 128-256". I said it needed to be specified, not that I had an opinion on what it should be. If it's a 'raw' key import that's fine, but we need to say it. And we need to make sure that a raw import can cope with size mis-matches, for example to be able to create an X-bit AES key from a Y-bit DH result where X != Y. ...Mark > > ...Mark > > Best ... Mark > > > On Fri, Feb 7, 2014 at 8:58 AM, Mark Watson <watsonm@netflix.com> wrote: > >> All, >> >> I tagged the bugs that are blocking Last Call: http://tinyurl.com/k36896o >> >> If additional bugs should block Last Call, please tag them "prelc". >> >> ...Mark >> >> >> On Thu, Feb 6, 2014 at 6:42 PM, Mark Watson <watsonm@netflix.com> wrote: >> >>> All, >>> >>> We had 15 bugs that were identified as needing to be resolved before >>> Last Call. The following is a status update since my last mail on these >>> sent before the last meeting. I've omitted those that were resolved at the >>> time of the last update. >>> >>> >>> *Bug 20611* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=20611> - >>> Specify the text encoding for JWK key format >>> >>> >>> OPEN - I propose we specify UTF-8, following the JWK specification, >>> unless anyone objects. >>> >>> >>> *Bug 22570* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22570> - >>> AES-GCM should provide distinct inputs/outputs for the tag >>> >>> >>> ASSIGNED: agreed on 1/27 that the tag will be appended to the ciphertext >>> >>> >>> *Bug 23831* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23831> - >>> add HMAC-SHA1 to the list of recommended algorithms >>> >>> >>> RESOLVED FIXED: HMAC-SHA1 added to list of recommended algorithms as >>> agreed on 1/27 >>> >>> >>> *Bug 23445* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23445> - >>> typo with BigInteger? >>> >>> >>> RESOLVED FIXED: according to 1/27 discussion >>> >>> >>> *Bug 23500* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23500> - >>> Raw AES access? >>> >>> >>> OPEN - list discussion: >>> http://lists.w3.org/Archives/Public/public-webcrypto/2014Jan/0029.html >>> >>> >>> *Bug 23729* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23729> - >>> Key usages future compatibility >>> >>> >>> RESOLVED FIXED: switch to DOMStrings according to 24415 >>> >>> >>> *Bug 23503* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23503> - >>> Should algorithms (ECC in particular) be extensible? >>> >>> >>> RESOLVED FIXED: switch to DOMStrings according to 24415 >>> >>> >>> *Bug 23495* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23495> - >>> Should an informative note mention that entropy is expected? (and an >>> error defined ?) >>> >>> >>> RESOLVED WORKSFORME. >>> >>> >>> There are in addition the following new bugs. We need to decide which of >>> these should be addressed before Last Call: >>> >>> >>> *Bug 24450 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24450>* - JWK >>> mapping should say what to do with keys that are invalid per JWK spec >>> >>> >>> OPEN >>> >>> >>> *Bug 24489 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24489>* - Correct >>> the mapping of JOSE key_ops to WebCrypto KeyUsage >>> >>> >>> RESOLVED DUPLICATE (24441) >>> >>> >>> *Bug 24457 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24457>* - AES-KW >>> can only wrap a JWK key if its serialization happens to be 8*n bytes long >>> >>> >>> OPEN - needs discussion >>> >>> >>> *Bug 24444 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24444>* - Named >>> Curve Registry (adding secp256k1) >>> >>> >>> OPEN - needs discussion >>> >>> >>> *Bug 24441 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24441> *- Typos >>> in usages to JWK mapping description >>> >>> >>> OPEN - typos fixed, waiting for JOSE to align key_ops names with >>> WebCrypto >>> >>> >>> *Bug **24410* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24410> - Define >>> operation procedures for each algorithm >>> >>> >>> OPEN >>> >>> >>> *Bug **24427* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24427> - Make >>> all method failures asynchronous >>> >>> >>> OPEN: needs discussion - one positive comment - waiting for other input >>> >>> >>> *Bug **24415* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24415> - Replace >>> enums with DOMStrings >>> >>> >>> RESOLVED FIXED >>> >>> >>> ...Mark >>> >>> >>> >> >
Received on Saturday, 8 February 2014 01:58:07 UTC