Re: [PROPOSED WORK ITEM] ECDSA Secp384r1 Cryptosuite v2019

Manu,

It's likely that secp384r proposal you are making is redundant to both:

https://w3id.org/security/suites/multikey-2021
https://w3id.org/security/suites/jws-2020

Both of which support P-384 / ES384.

As does did:key, https://did.key.transmute.industries/generate/secp384r1

I would suggest that `publicKeyMultibase` be addressed comprehensively,
since the registry it relies on supports P256, P521, RSA and other formats.
(see the pull request at the bottom).

From a standards perspective, it is true that not every cryptographic
primitive needs to be supported, but a standard that can only represent a
subset will always lose out to a standard that can represent the full set.

If we are not going to be using JWK, multibase will need to do better than
JWK, which means representing everything that JWK can represent, and then
some (to justify the switching cost to lazy developers like myself).

This would include bls12381, post quantum, and most importantly private
keys, etc... all things that multibase and jwk will both implement in
time...

Given the hardware support for EdDSA remains poor, I think it's great that
folks are looking at the NIST curves and considering how important they are
for interop.

My experience over the last few years has led me to be extremely
suspicious of new key representations, due to the need to convert between
key types, and increasing costs for NxM interop across each library in each
supported key type.

In short I think we should aim for parity with JWK if we think
publicKeyMultibase is better than JWK, and if we don't we should stop using
it.

I understand the desire to have a JSON-LD encoding of key and signatures
that does not rely on JWK and JWS... but in my experience I don't think the
cost is worth it, certainly not if you only end with a fraction of the
supported cipher suites JOSE has, and a community draft that does not
define the private key representations.

To be clear, I am not opposed to new cipher suites, or key
representations... I am opposed to doing them as one offs, that are not (in
my opinion) strong enough to survive or win a fight for the top position
representing cryptography in JSON.

There is currently no registered way to represent a `privateKeyMultibase`,
only public keys... see https://github.com/multiformats/multicodec/pull/190

Here is a P384 private key

[
  {
    "id":
"did:key:z82LkxE8ckNoFEaDr1KFa5sUEAGEVz3yH6JvwPpAJaxWSBD3JTZYtUGEGm739yjwPWBwkZF#z82LkxE8ckNoFEaDr1KFa5sUEAGEVz3yH6JvwPpAJaxWSBD3JTZYtUGEGm739yjwPWBwkZF",
    "type": "P384Key2021",
    "controller":
"did:key:z82LkxE8ckNoFEaDr1KFa5sUEAGEVz3yH6JvwPpAJaxWSBD3JTZYtUGEGm739yjwPWBwkZF",
    "publicKeyBase58":
"XVLBjgWKwUKHENLj17vg9Zrse4iNzF1981cGisLAxWP26bkpWighouseDipEP8vHjF",
    "privateKeyBase58":
"4wjY1w4VvGCKQECjgdN8SV6JA2Qkias7M3CSALCvjJH5uVfMrL83yPY3DVyproSYNS"
  }
]

Until I can see one for multibase proposals, I strongly object to
standardizing public key only representations.

Since private keys are the root of control in public key cryptosystems,
representations that intentionally opt not to describe them are creating a
severe injustice between the users of the public key and the software
maintainers who know the "secret /undocumented"  private key presentation,
or build libraries that manage it.... this is not something I can support
as a firm believer in the individual's ability to understand and use
private keys to protect their rights.

The only thing worse than calling a private key 'd' is not defining it at
all, and expecting folks to understand and protect it.

I am a big fan of multi codec based keys, especially as they relate to DID
Key (this is why we built multikey-2021, so we could represent any JWK as a
did key).

I am not a fan of ccg specs that don't define private keys and that go out
of their way to ignore other key representations such as P-256 / ES384
(arguably more supported and widely used).

Regards,

OS



ᐧ

On Sun, Jan 23, 2022 at 2:17 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> Hi all,
>
> Proposing a new work item so we can fold it into the new VCWG 2.0 work (to
> complete the proposals we have for Ed25519, secp256k1, and BBS+).
>
> https://digitalbazaar.github.io/di-ecdsa-secp384r1-2019/
>
> This specification describes the ECDSA Secp384r1 cryptosuite created in
> 2019
> for the Data Integrity specification. Just like the exiting CCS work items
> for
> the Ed25519 Cryptosuite, the Secp256k1 Cryptosuite, and the BBS+
> Cryptosuite,
> this cryptosuite extends the Data Integrity specification to support
> cryptography supported by many large organizations throughout the world.
>
> > 1. Explain what you are trying to do using no jargon or acronyms.
>
> This specification adds support for a type of digital signature that is
> used
> heavily by large organizations throughout the world. It was our hope that
> we
> would not have to support this digital signature suite due to it's
> controversial nature:
>
>
> https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters
>
> ... but given the slow pace of the hardware security module industry,
> along with the slow pace at which national institutes that standardize
> cryptography are moving, and given the hostility of a vocal minority of W3C
> Member companies towards the scope of the Verifiable Credentials work,
> publishing this work item and folding it into the VCWG 2.0 work protects
> that
> work from any W3C Member that might insist that work on this technology is
> out
> of scope (and thus hobbling the VCWG group's ability to be responsive to
> cryptographic needs in the industry).
>
> > 2. How is it done today, and what are the limits of the current practice?
>
> The current focus of Elliptic Curve digital signatures in the VC ecosystem
> seems to be around something called the "Twisted Edwards Curve", or
> Ed25519.
> That cryptography uses provably secure techniques. Unfortunately, that
> technology has just been approved by the National Institute of Standards in
> draft form and it might take years for it to be supported in the commercial
> hardware security modules that many governments and large organizations
> depend
> on. It was our hope that the industry was going to make more progress by
> this
> point, but it's not moving fast enough. We plan to standardize a few
> cryptosuites in the upcoming VCWG 2.0 work. In order to mitigate the risk
> that
> Ed25519 won't be available in commercial hardware security modules by the
> time
> that some vendors need to deploy into production settings with large
> organizations and governments, we are suggesting that ECDSA Secp384r1
> should
> be an option for Issuers that desire its functionality.
>
> > 3. What is new in your approach and why do you think it will be
> > successful?
>
> There is nothing new in the approach, in fact, the cryptography used here
> is
> fairly old (almost 20+ years at this point). If it is successful, it will
> be
> because of the broad market adoption that the technology already has.
>
> > 4. How are you involving participants from multiple skill sets and
> global
> > locations in this work item? (Skill sets: technical,  design, product,
> > marketing, anthropological, and UX. Global locations:  the Americas,
> APAC,
> >  Europe, Middle East.)
>
> Due to the nature of the work item (cryptographic security), it is
> difficult
> to include non-technical participants. We will be involving the CCG and
> VCWG,
> which do include non-technical participants throughout the world, but
> again,
> their ability to influence the technical direction will be quite limited.
>
> > 5. What actions are you taking to make this work item accessible to a
> > non-technical audience?
>
> Overall, none, as non-technical audiences need not be exposed to this
> level of
> detail.
>
> We will happily try and explain what we're doing on the CCG mailing list if
> non-technical members have questions about the technology.
>
> Chairs, I'd like a few minutes to propose this work item to the CCG and
> seek a
> co-editor for the specification.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>