- From: Harry Halpin <hhalpin@w3.org>
- Date: Thu, 28 Aug 2014 14:20:27 +0200
- To: Ryan Sleevi <sleevi@google.com>, Mark Watson <watsonm@netflix.com>
- CC: GALINDO Virginie <Virginie.Galindo@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/28/2014 05:04 AM, Ryan Sleevi wrote: > 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). +1 > > 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. No, we should support generically curves in general. The issue that Brian brought up, and I support, is not MUST NOT add these curves. It's that *if* CFRG does recommend non-NIST curves, we MUST add them eventually. The spec should be as generic as possible to allow extensions of different curve types. > > 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. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJT/x6LAAoJEPgwUoSfMzqcpXcQAK88UZHUzZ8+2d+jfD5Q21LL g1dXEtTT+KCbx2pDmXhXONwzdzQyVqQ68Ogh4nbzR+M4PotvAsE1fJacdM4Dbmdr MPIjOb4G8463WecUeIWUYPDWIAyROW8wBYRpqCuEYb0LmE0TvRZphEhdqo+KBFkP R8e6KMXteKf+0BjqYFmvKCF+J6AhF2/7muZRzrJHwYb5qyXi7x7hmu0apzPpapG5 JxZutAeZuuVLjgYVW/sVUoKLETX5gcLwPu2JtQRu3VEtzJuhHY/QOpRc1tOTq/zM fkwp0s3VCOLDZfMjo2RKIS5tBx50a9ur394+xvZLaJx7wRygx+EQO7zozgXliVWt bRbqlahhCH6VcZbYIRfzSymjeGZZEH/YawyZakEOzmaIauDKQUjZtK2L0bvR3glu mdEidsxujtXIiRDjFDLMsBur4gHIlnYWce6AvDQbdyOy6b/KmtDt5t3ZtxwgIcEN sLR0qQ9phChO4TX60fUJIt2q2bt5OaV7NjsqO0SGd/JZuagxeYOGUxiCM/FrOQBf J40Cz0QAYpL/HStaS3Qc5XWFtLRPydmYmQ38NIXy7PZuPXfZ8V78RexAn0XFUJUW Pa+dj/f6J1xignBCPLR2S07haR2uNYts0DbUdGkz3kM408qSnjmtbnj6J7oi9ULw 8oGeyeC5gopOONKZ0Y31 =puLO -----END PGP SIGNATURE-----
Received on Thursday, 28 August 2014 12:20:36 UTC