- From: Ryan Sleevi <sleevi@google.com>
- Date: Wed, 27 Aug 2014 20:04:38 -0700
- To: Mark Watson <watsonm@netflix.com>
- Cc: GALINDO Virginie <Virginie.Galindo@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <CACvaWvaSJ+3BRe91og=irL3UUkJVZ+gfQNNC-NHd9+xvFaAygw@mail.gmail.com>
On Tue, Aug 26, 2014 at 7:51 AM, Mark Watson <watsonm@netflix.com> wrote: > > > > On Mon, Aug 25, 2014 at 6:01 PM, Ryan Sleevi <sleevi@google.com> wrote: > >> >> >> >> On Mon, Aug 25, 2014 at 5:49 PM, Mark Watson <watsonm@netflix.com> wrote: >> >>> >>> >>> >>> On Mon, Aug 25, 2014 at 5:31 PM, Ryan Sleevi <sleevi@google.com> wrote: >>> >>>> >>>> On Mon, Aug 25, 2014 at 5:25 PM, Mark Watson <watsonm@netflix.com> >>>> wrote: >>>> >>>>> All, >>>>> >>>>> Based on the lack of response to my questions below, I propose we >>>>> close this issue as a "non-issue". As far as I can tell the specification >>>>> contains all the extensibility that we need in the form of the ability to >>>>> add additional algorithms. >>>>> >>>> >>>> And what of SHA-3? >>>> >>> >>> The various SHA flavors in the specification are already distinct >>> algorithms. I don't see any problem adding more with the algorithm >>> extensibility mechanism. >>> >> >> Apologies for not being clearer. >> >> How does SHA-3 work with RSA? With ECDSA? With HKDF? With Concat? With >> PBDKF2? >> >> I realize that your answer may very well be "I don't know", because no >> such thing exists as SHA-3 yet (beyond Keccak with some undefined set of >> parameters and uses). >> >> The point being that we don't know HOW interoperability will work in this >> case. >> > > Hmm, the specification looks quite clear to me on this. For example, the > RSA-SSA procedures say things like "Perform the signature generation > operation defined in Section 8.2 of [RFC3447] with the key represented by > the [[handle]] internal slot of key as the signer's private key and the > contents of message as M and using the hash function specified in the hash > attribute of the [[algorithm]] internal slot of key as the Hash option for > the EMSA-PKCS1-v1_5 encoding method." > > So, supposing we had a WebCrypto algorithm specification for SHA-3, the > phrase "hash function specified in the hash attribute of the [[algorithm]] > internal slot of key" would be well-defined and the question becomes one of > whether RFC3447, Section 8.2, is clear on how this hash function should be > used within the EMSA-PKCS1-v1_5 encoding method. Answering this question is > clearly out of scope of WebCrypto. RSA-OAEP, RSA-PSS, HMAC, CONCAT, HKDF > and PBKDF2 are similar. > Apologies for not being clearer, as I hoped the issue would have been apparent. Consider both the importKey and exportKey methods of RSA-SSA - https://dvcs.w3.org/hg/webcrypto-api/raw-file/ee10c81e1141/spec/Overview.html#rsassa-pkcs1-operations These are certainly IN SCOPE of WebCrypto Or consider that these hash algorithms may not be valid with Concat, HKDF, or PBKDF2, whereas the current spec implies they are. > > In the case of ECDSA we have "If hashAlgorithm does not describe a > registered algorithm that supports the digest operation, then return an > error named NotSupportedError." and then "Let M be the result of performing > the digest operation specified by hashAlgorithm using message." > , so we are explicitly invoking the hash from our own procedures. This > also seems clear. > Same issue. > > None of our procedures are specific to the current set of registered hash > algorithms. Our referenced specifications may have restrictions, but if new > specifications are written, it would seem likely that we would want to > define new WebCrypto algorithms which reference those new specifications. > See above, they are. > > Now, we do potentially have a compliance or capability-discovery question > as to which hash algorithms must be supported with with algorithms in the > case that the referenced base specifications do not nail this down. And/or > how sites can discover UA capabilities. But these are separate issue from > extensibility - they exists within the specification as written without > talking about extensions. > > >> >> >>> >>> >>>> >>>> >>>>> >>>>> In particular, noone is arguing for extensibility of key formats (and >>>>> some arguments against have been made). Good reasons have also been >>>>> presented as to why additional Elliptic Curves should be added as new >>>>> algorithms. >>>>> >>>> >>>> And what of our existing-named EC curves? How do they or do they not >>>> fit in? >>>> >>> >>> I don't see we necessarily need any change to the specification, but I >>> it would make sense to rename the existing algorithms to "EC-NIST" or >>> similar. But that is a separate issue. >>> >> >> I think it's inextricably linked with how we treat extensibility. >> > > Of course. I made a proposal to address extensibility (new algorithms) > and renaming the existing EC ones is a likely consequence of that proposal. > How does that not answer your question ? > How we handle NIST-like curves (NUMS) affects how we handle ACTUAL NIST / SECG curves. The current curve names come not from NIST or SECG, but from JOSE, which chose a naming scheme somewhat particularly. Does this imply we have EC-NIST, EC-SECG, EC-NUMS, and variants of each for ECDSA & ECDH, even though they all fit within the same encoding space (in terms of SPKI, PKCS#8, and JOSE) and the same operational space (in terms of referenced specifications?) This is very much tied together. > > >> >> >>> >>> >>>> And what of the other SEGC curves? How do they or do they not fit in? >>>> >>> >>> New curves can be added as new algorithms, either in the main >>> specification or in extension documents as we decide. >>> >> >> And with respect to SECG, and with how both ECDSA and ECDH are currently >> specified, this is internally inconsistent. This is an issue that we have >> to solve, and that we have not solved. >> > > Can you explain the "internal inconsistency", assuming we renamed the > existing EC algorithms ? > I've tried restating the issue above. > > >> >> >>> >>> >>>> And what of normalization, which you've raised concerns with the >>>> HashAlgorithm interface? For example, what are the implications for CONCAT >>>> or HKDF? >>>> >>> >>> I made a proposal to solve the problem I raised in the appropriate bug. >>> - I'll refresh that. >>> >>> >>>> >>>> My biggest concern is holistic consistency here. In order to achieve >>>> that, we first need consensus on curves, and then we can (and MUST) >>>> evaluate whether the spec is internally consistent with those decisions and >>>> provides clear guidance for those that wish to extend. >>>> >>> >>> Sure. A good way to obtain consensus is to have concrete proposals and >>> see if anyone objects. >>> >> >> I don't really see a "Ignore them", which seems to be the answer, to be a >> concrete proposal. >> > > Please explain more clearly where you see a problem. Is it just that the > existing EC algorithms purport to support "Elliptic Curve" cryptography and > it would be "inconsistent" to find that they only supported a small subset > of that space (NIST curves) ? Renaming and a tweak to the description would > address that. What other consistency problem am I "ignoring" ? > > >> >>> >>> Regarding curves, we need consensus on how new curves should be added to >>> the specification, but we do not need consensus on which curves and whether >>> they should be in the main specification or separate extension documents, >>> which are the more controversial points. >>> >> >> And consensus for new curves directly relates to how we handle existing >> curves and usages. >> >> Both Curve25519 (which is in wide use, but does not fit ECDSA/ECDH, and >> to which Richard objects to because it's not been blessed by the CFRG) and >> NUMS (which is in no practical use or review, but which easily fits within >> the SECG space and thus ECDSA/ECDH) demonstrate that this remains an open >> issue as to how we handle OTHER curves, such as the Koblitz curves. >> > > Do you feel, for some reason, that all new curves should be added in the > same way ? For example, suppose there was consensus to add both NUMS and > Curve25519, do you feel they should both follow the same approach > (extension of existing EC vs new algorithms) ? Why ? > > It would seem perfectly reasonable to qualify the existing EC algorithms > to be "Elliptic Curve Cryptography based on curves defined in twisted > Edwards form" and add a new algorithm for Curve25519, given the "special" > way in which it is apparently defined. > > ...Mark > I think we need a clear proposal for how to deal with our existing (three) NIST curves, the NUMS curves, and a way that is consistent with curves we've had others ask for (the SECG koblitz curves, as used by Bitcoin) or related (such as Brainpool). Of course, it seems that the zeitgeist of at least Harry and Brian, and perhaps I'm misreading, is that we MUST NOT add these curves unless/until the CFRG blesses them, even though they are defined curves in real use and real applications. I can't help but feel that this push towards CFRG-advice is the same revisiting of the AES discussions and whether or not the API defines an API as a concept, or if it's meant to be an opinionated (read: secure vs insecure) discussion. Waiting for CFRG inherently seems the latter. > > >> >> >>> >>> More guidance on how to extend the specification would be good - I'm >>> happy to draft something, though we already have the details of the main >>> "supported algorithms" mechanism. >>> >>> ...Mark >>> >>> >>> >>>> >>>> >>>>> >>>>> ...Mark >>>>> >>>>> >>>>> On Tue, Aug 19, 2014 at 11:44 AM, Mark Watson <watsonm@netflix.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 19, 2014 at 11:00 AM, Ryan Sleevi <sleevi@google.com> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> On Aug 19, 2014 10:51 AM, "Mark Watson" <watsonm@netflix.com> wrote: >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On Tue, Aug 19, 2014 at 10:47 AM, Ryan Sleevi <sleevi@google.com> >>>>>>> wrote: >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> On Tue, Aug 19, 2014 at 10:30 AM, Mark Watson < >>>>>>> watsonm@netflix.com> wrote: >>>>>>> >>> >>>>>>> >>> All, >>>>>>> >>> >>>>>>> >>> I would like to make a concrete proposal for two additional >>>>>>> extensibility points to be added to our specification. First, please note >>>>>>> that we already have the ability to add new algorithms without >>>>>>> monkey-patching, so no change to the specification is require for that. The >>>>>>> two additions I propose are: >>>>>>> >>> >>>>>>> >>> (1) Allow for the addition of new key formats >>>>>>> >> >>>>>>> >> >>>>>>> >> I do not support this. Unlike algorithms, key formats are >>>>>>> integral parts of the API (in as much as all formats must be supported). >>>>>>> Because of this, I would rather see it embodied in the API itself, because >>>>>>> it's not really a separable part. >>>>>>> >> >>>>>>> >>> >>>>>>> >>> (2) Allow for the addition of new curves to ECDSA and ECDH, for >>>>>>> the case where those curves are described in such a way that they are >>>>>>> drop-in replacements for the NIST curves >>>>>>> >> >>>>>>> >> >>>>>>> >> I think Trevor makes solid arguments as to why we should NOT do >>>>>>> (2), and have come around to agreeing. >>>>>>> > >>>>>>> > >>>>>>> > Were Trevor's arguments specific to Curve25519 ? I thought the >>>>>>> NUMS curves could easily added to the existing ECDSA / ECDH algorithms ? >>>>>>> >>>>>>> No, he was in fact suggesting the existing EC methods should be >>>>>>> renamed to indicate they are NIST/FIPS specific, and the curve names are >>>>>>> derived from those specs. >>>>>>> >>>>>>> We've seen the same tension from those wanting support for >>>>>>> secp256k1, that our naming of P256 (inherited from JOSE) is at odds with >>>>>>> ECDSA as a 'generic' mechanism. >>>>>>> >>>>>> Ok. So I am personally fine with requiring new algorithms for new >>>>>> curves, and possibly renaming our existing ECDSA/ECDH to be NIST-specific. >>>>>> >>>>>>> > >>>>>>> > Are there any other extensibility points you think we need, or are >>>>>>> we essentially done with the existing ability to add new algorithms ? >>>>>>> >>>>>>> The above are still outstanding. >>>>>>> >>>>>> In what sense ? That we don't yet have consensus ? >>>>>> >>>>>> >>>>>>> There is an overall issue of ensuring we have things be extensible >>>>>>> where they should be - or consistent overall. >>>>>>> >>>>>> So, in the interest of actually making progress, what - specifically >>>>>> - do you think we need to look at ? I've looked through the specification >>>>>> and I don't see a need for any other extensibility points. >>>>>> >>>>>> ...Mark >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> > >>>>>>> > ...Mark >>>>>>> > >>>>>>> > >>>>>>> >> >>>>>>> >> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> [Curves that are not drop-in replacements for the NIST ones >>>>>>> would need to be added as new algorithms. I'm aware that the phrase >>>>>>> "drop-in replacement" begs a clearer definition]. >>>>>>> >>> >>>>>>> >>> In my opinion these two extensibility points, together with the >>>>>>> ability to add new Algorithms, are sufficient. I could be convinced that >>>>>>> (1) is not necessary. >>>>>>> >>> >>>>>>> >>> What do others think ? >>>>>>> >>> >>>>>>> >>> ...Mark >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> On Wed, Aug 6, 2014 at 3:18 AM, GALINDO Virginie < >>>>>>> Virginie.Galindo@gemalto.com> wrote: >>>>>>> >>>> >>>>>>> >>>> Dear all, >>>>>>> >>>> >>>>>>> >>>> We have to find a mechanism for extending our Web Crypto API >>>>>>> specification, in order to integrate in the future some new algorithms, or >>>>>>> algorithm flavors. This corresponds to the bug 25618 >>>>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618 . >>>>>>> >>>> >>>>>>> >>>> Here are ideas and requirements that were mentioned during the >>>>>>> conference calls and the bugzilla discussions. Those statements are high >>>>>>> level, and are here to try to identify requirements and principles on this >>>>>>> extension mechanism. Note that this discussion is not only about adding new >>>>>>> curves, but should also be applicable to next generation of algorithm. So >>>>>>> lets try to be generic, in a first step. >>>>>>> >>>> >>>>>>> >>>> 1 Extension can be used to add new algorithm (or new flavor of >>>>>>> algorithm) to the Web Crypto API >>>>>>> >>>> 2 Extension is a separate document from the main specification, >>>>>>> which must contain complete description of the new (flavor of) algorithm >>>>>>> (reference, registration, dictionary, operations, and if is it part of >>>>>>> 'recommended algorithms' or not) >>>>>>> >>>> 3 Extension existence requires to have hook in the main Web >>>>>>> Crypto API spec to declare new key format (please add any other impact) >>>>>>> >>>> 4 Extension can be in a form of a wiki, or a Note or a >>>>>>> Recommendation (please state your preferred scenario) >>>>>>> >>>> 5 The integration of new (flavor of) algorithm requires to go >>>>>>> though W3C IP call for exclusion or not (in that case only the >>>>>>> Recommendation scenario would work) >>>>>>> >>>> 6 The new (flavor of) algorithm will requires identifier and >>>>>>> short name that need to be registered (in IETF or W3C) >>>>>>> >>>> >>>>>>> >>>> This is a strawman proposal expecting your challenge, criticism >>>>>>> and alternatives... >>>>>>> >>>> Go ! >>>>>>> >>>> >>>>>>> >>>> Regards, >>>>>>> >>>> Virginie >>>>>>> >>>> ________________________________ >>>>>>> >>>> This message and any attachments are intended solely for the >>>>>>> addressees and may contain confidential information. Any unauthorized use >>>>>>> or disclosure, either whole or partial, is prohibited. >>>>>>> >>>> E-mails are susceptible to alteration. Our company shall not be >>>>>>> liable for the message if altered, changed or falsified. If you are not the >>>>>>> intended recipient of this message, please delete it and notify the sender. >>>>>>> >>>> Although all reasonable efforts have been made to keep this >>>>>>> transmission free from viruses, the sender will not be liable for damages >>>>>>> caused by a transmitted virus. >>>>>>> >>>> >>>>>>> >>> >>>>>>> >> >>>>>>> > >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
Received on Thursday, 28 August 2014 03:05:08 UTC