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

Re: Secp256k1 key types standardizations

From: Pelle Braendgaard <pelle.braendgaard@consensys.net>
Date: Thu, 29 Mar 2018 10:25:23 -0600
Message-ID: <CANQzS_ip471MJTaG9jpmVZJkdzJpYwJGgEExE1TV_Zm=AEsw8w@mail.gmail.com>
To: Christian Lundkvist <christian.lundkvist@consensys.net>
Cc: Mike Lodder <mike.lodder@evernym.com>, Kim Hamilton Duffy <kim@learningmachine.com>, Credentials Community Group <public-credentials@w3.org>
As long as we use the DER(?) format that most people are using we can
handle both. It's encoded in the first byte.

Pelle

On Thu, Mar 29, 2018 at 9:07 AM, Christian Lundkvist <
christian.lundkvist@consensys.net> wrote:

>
> I also agree that Secp256k1VerificationKey2018 sounds like the best fit
> here.
>
> Another rabbit hole is the format of the key. We can have it in compressed
> or uncompressed form, should this information be somewhere or should it be
> inferred from the size of the key?
>
> Cheers,
> Christian
> On Thu, Mar 29, 2018 at 10:33 AM Mike Lodder <mike.lodder@evernym.com>
> wrote:
>
>> +1
>>
>> ------------------------------
>> *From:* Pelle Braendgaard <pelle.braendgaard@consensys.net>
>> *Sent:* Thursday, March 29, 2018 7:52:31 AM
>> *To:* Kim Hamilton Duffy
>> *Cc:* Mike Lodder; Credentials Community Group
>> *Subject:* Re: Secp256k1 key types standardizations
>>
>> I agree Kim,
>>
>> So I think standardizing on "Secp256k1VerificationKey2018" would be the
>> most consistent.
>>
>> Pelle
>>
>> On Wed, Mar 28, 2018 at 9:58 PM, Kim Hamilton Duffy <
>> kim@learningmachine.com> wrote:
>>
>>> The other problem is the naming inconsistency. From the other 2 key ids
>>> in the registry, (below) and from DID hardening discussions around key
>>> "purpose". I'd expected the ids to follow a pattern, e.g.
>>> <curve-specific><purpose>Key<date>.
>>>
>>> To clarify, I thought we decided that an entry in this registry would
>>> map to a specific combination of JWK parameters to help avoid the problem
>>> of algorithmic agility. (However, I did miss many of the later DID
>>> hardening calls.)
>>>
>>> Given that the registry is brand new, I'd think we could impose this
>>> consistency before things get out of control. Or is that not possible or
>>> necessary in this case?
>>>
>>>    - Ed25519*VerificationKey2018*
>>>    - Rsa*VerificationKey2018*
>>>    - EdDsaSAPublicKeySecp256k1
>>>
>>> Either way, it's irritating to look at :)
>>>
>>> On Wed, Mar 28, 2018 at 11:59 AM Mike Lodder <mike.lodder@evernym.com>
>>> wrote:
>>>
>>>> EdDsaSAPublicKeySecp256k1 is incorrect. EdDsa is only possible with
>>>> Twisted Edward curves. This should be ECDSAPublicKeySecp256k1.
>>>>
>>>> On Wed, Mar 28, 2018 at 12:48 PM, Kim Hamilton Duffy <
>>>> kim@learningmachine.com> wrote:
>>>>
>>>>> We may have a naming issue in the current LD Cryptosuite Registry;
>>>>> note that we have a secp256k1key, but its identifier
>>>>> (EdDsaSAPublicKeySecp256k1) isn't consistent with the others in terms of
>>>>> specifying purpose.
>>>>>
>>>>> For context, here's the list of key identifiers currently in the
>>>>> registry (https://w3c-ccg.github.io/ld-cryptosuite-registry/):
>>>>>
>>>>>    - Ed25519VerificationKey2018
>>>>>    - RsaVerificationKey2018
>>>>>    - EdDsaSAPublicKeySecp256k1 <<<
>>>>>
>>>>> Example for EdDsaSAPublicKeySecp256k1 in the registry:
>>>>>
>>>>> {
>>>>>   "id": "did:example:123456789abcdefghi#keys-1",
>>>>>   "type": "EdDsaSAPublicKeySecp256k1",
>>>>>   "owner": "did:example:123456789abcdefghi",
>>>>>   "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
>>>>> }
>>>>>
>>>>> The DID spec uses the type name you mentioned
>>>>> (Secp256k1VerificationKey2018) in the same context of a publicKey
>>>>>
>>>>>  {
>>>>>     "id": "did:example:123456789abcdefghi#keys-3",
>>>>>     "type": "Secp256k1VerificationKey2018",
>>>>>     "owner": "did:example:123456789abcdefghi",
>>>>>     "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
>>>>>   }]
>>>>>
>>>>> Should we rename the identifier in the registry? Or does this have
>>>>> some purpose I'm missing
>>>>>
>>>>> On Wed, Mar 28, 2018 at 10:46 AM Pelle Braendgaard <
>>>>> pelle.braendgaard@consensys.net> wrote:
>>>>>
>>>>>> Hello guys,
>>>>>> I've lost count of all the variations of the secp256k1 key types I've
>>>>>> seen. The latest in the DID spec is:
>>>>>>
>>>>>> "Secp256k1VerificationKey2018"
>>>>>>
>>>>>> Can we stick with that for now. I know we need to register it here
>>>>>> https://w3c-ccg.github.io/ld-cryptosuite-registry/ but not quite
>>>>>> sure of the process for that.
>>>>>>
>>>>>> For authentication I would like to use the following type copying
>>>>>> from the conventions for RSA:
>>>>>>
>>>>>> "Secp256k1SignatureAuthentication2018"
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Pelle
>>>>>>
>>>>>> --
>>>>>> *Pelle Brændgaard // uPort Engineering Lead*
>>>>>> pelle.braendgaard@consensys.net
>>>>>> 49 Bogart St, Suite 22, Brooklyn NY 11206
>>>>>> <https://maps.google.com/?q=49+Bogart+St,+Suite+22,+Brooklyn+NY+11206&entry=gmail&source=g>
>>>>>> Web <https://consensys.net/> | Twitter
>>>>>> <https://twitter.com/ConsenSys> | Facebook
>>>>>> <https://www.facebook.com/consensussystems> | Linkedin
>>>>>> <https://www.linkedin.com/company/consensus-systems-consensys-> |
>>>>>> Newsletter
>>>>>> <http://consensys.us11.list-manage.com/subscribe?u=947c9b18fc27e0b00fc2ad055&id=257df01285&utm_content=buffer1ce12&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer>
>>>>>>
>>>>> --
>>>>> Kim Hamilton Duffy
>>>>> CTO & Principal Architect Learning Machine
>>>>> Co-chair W3C Credentials Community Group
>>>>> 400 Main Street Building E19-732, Cambridge, MA 02139
>>>>> <https://maps.google.com/?q=732,+Cambridge,+MA+02139&entry=gmail&source=g>
>>>>>
>>>>> kim@learningmachine.com | kimhd@mit.edu
>>>>> 425-652-0150 <(425)%20652-0150> | LearningMachine.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Mike Lodder
>>>> Senior Crypto Engineer
>>>>
>>>>
>>>> --
>>> Kim Hamilton Duffy
>>> CTO & Principal Architect Learning Machine
>>> Co-chair W3C Credentials Community Group
>>> 400 Main Street Building E19-732, Cambridge, MA 02139
>>>
>>> kim@learningmachine.com | kimhd@mit.edu
>>> 425-652-0150 <(425)%20652-0150> | LearningMachine.com
>>>
>>
>>
>>
>> --
>> *Pelle Brændgaard // uPort Engineering Lead*
>> pelle.braendgaard@consensys.net
>> 49 Bogart St, Suite 22, Brooklyn NY 11206
>> <https://maps.google.com/?q=49+Bogart+St,+Suite+22,+Brooklyn+NY+11206&entry=gmail&source=g>
>> Web <https://consensys.net/> | Twitter <https://twitter.com/ConsenSys> |
>> Facebook <https://www.facebook.com/consensussystems> | Linkedin
>> <https://www.linkedin.com/company/consensus-systems-consensys-> |
>> Newsletter
>> <http://consensys.us11.list-manage.com/subscribe?u=947c9b18fc27e0b00fc2ad055&id=257df01285&utm_content=buffer1ce12&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer>
>>
>


-- 
*Pelle Brændgaard // uPort Engineering Lead*
pelle.braendgaard@consensys.net
49 Bogart St, Suite 22, Brooklyn NY 11206
Web <https://consensys.net/> | Twitter <https://twitter.com/ConsenSys> |
Facebook <https://www.facebook.com/consensussystems> | Linkedin
<https://www.linkedin.com/company/consensus-systems-consensys-> | Newsletter
<http://consensys.us11.list-manage.com/subscribe?u=947c9b18fc27e0b00fc2ad055&id=257df01285&utm_content=buffer1ce12&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer>
Received on Thursday, 29 March 2018 16:25:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:25 UTC