W3C home > Mailing lists > Public > public-credentials@w3.org > March 2017

Re: PR for playground

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 25 Mar 2017 18:41:54 -0400
To: Credentials Community Group <public-credentials@w3.org>
Cc: Tony Arcieri <bascule@gmail.com>, Christopher Allen <ChristopherA@blockstream.com>
Message-ID: <a8ca3af8-54ed-5e38-0f0e-02ee3e56b209@digitalbazaar.com>
BCC: public-webpayments-ig

Hey Kim, Tony, apologies for the W3C mailing list maze, but the
Verifiable Claims discussion is happening in the Credentials CG now:

https://www.w3.org/community/credentials/

The ECDSA Signatures discussion should probably happen in the W3C
Digital Verification Community Group... but that group hasn't really
spun up yet:

https://w3c-dvcg.github.io/

On 03/24/2017 06:11 PM, Tony Arcieri wrote:
> I'm sorry if this is a sidebar in this issue

Don't be... we really appreciate the feedback you provided. :)

> but is there a particular reason why you're using Koblitz signatures
>  and, perhaps more concerning, why you're using ECDSA?

You said it in your email... Bitcoin compatibility. That community
wanted a signature suite that was compatible with Bitcoin in general.

Also, DISCLAIMER: All of the technologies we're talking about are
experimental and are expected to blow you foot off if you put them into
production without understanding the consequences of the design
decisions you've made.

> The CFRG has selected Ed25519 (RFC 8032) as the next-generation high
> security curve. If performance is the concern, more modern
> alternatives like FourQ will exceed e.g. secp256k1's performance.

If there is a desire to create an Ed25519 Signature Suite for Linked
Data signatures, we'd be happy to help someone create it. I imagine that
in time, that will exist as well.

> The only reason to choose secp256k1 (I assume?) today is
> compatibility with Bitcoin.

Yes, that's why the signature suite uses it.

> But that's less concerning than this: New protocols should NOT be
> using ECDSA. ECDSA has repeatedly failed in practice, has many
> failure modes modern signature schemes are not vulnerable to, and
> now that the Schnorr patents have expired is completely obsolete.

What would you suggest we switch to that would simultaneously keep
compatibility with the Bitcoin community while utilizing more modern
signature schemes? This is new work, so we have a very good opportunity
to change things at this point.

Also, we've been interested in deploying Schnorr signatures for a while
but lack the expertise to pick the right parameters for the Signature
Suite... would you know enough about Schnorr to help us put together a
Schnorr Signature Suite? (we can implement, we just need someone (you?)
to check our math).

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Rebalancing How the Web is Built
http://manu.sporny.org/2016/rebalancing/
Received on Saturday, 25 March 2017 22:42:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:35 UTC