W3C home > Mailing lists > Public > public-credentials@w3.org > January 2022

Re: Commissioning support in keytool-cli for did:key/secp keys?

From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Thu, 13 Jan 2022 13:57:34 -0800
Message-ID: <CACrqygD0RG7KnQytZWq5EVoySep96=WBoVMxzjwe6eZTfX6Ksw@mail.gmail.com>
To: Brent Shambaugh <brent.shambaugh@gmail.com>
Cc: Credentials Community Group <public-credentials@w3.org>
On Thu, Jan 13, 2022 at 1:25 PM Brent Shambaugh <brent.shambaugh@gmail.com>
wrote:

> FWIW, I have the NIST curves in this PR:
> https://github.com/ceramicnetwork/js-ceramic/pull/1884 . I booked ETH
> Denver this year: Feb 11- 20th, so I will be focusing on that for the time
> being. If you are talking about what I think you are talking about, maybe I
> can help.
>

Thanks Brent.

Your NIST curve code might be useful later, but right now we leverage the
solidly reviewed secp256k1 C library used by Bitcoin as we don't have the
resources to review cryptographic code / side channels / etc. nearly to the
level they do.

Our project is actually much simpler — just convert the public key already
internally generated by the app  to the multibase format that did:key uses,
then encode that in whatever human-readable URI format it needs, and then
create unit tests and compatibility tests to make sure they are the same as
the reference keys in the did:key method spec.

The lead developer @WolfMcNally of keytool-cli could probably whip this out
fairly quickly, but he is not as familiar with did:key and did:web
compatibility issues, and is working on a different code base right now. I
thought this might be an easy starting project for a journeyman developer
in the DID ecosystem, I have some funding available, and I'd like to
confirm how easy it is for others to contribute to our keytool code base
(for instance, it currently doesn't support 25519 or ristretto keys or
signatures, but I'd like it to someday).

-- Christopher Allen

P.S. Here are the key derivations currently supported by keytool-cli:

[image: image.png]

image.png
(image/png attachment: image.png)

Received on Thursday, 13 January 2022 21:58:29 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 13 January 2022 21:58:31 UTC