Re: Secp256k1 key types standardizations

Just to make our lives a little more complicated, a EC public or private
key’s signature can be either ECDSA (based on El Gamal) or Schnorr. Both
keys are the same, the signatures are different. So if you are referring to
a signature, you need to say which form.

— Christopher Allen

On Thu, Mar 29, 2018 at 10:20 PM, Kim Hamilton Duffy <
kim@learningmachine.com> wrote:

> I’ll open an issue on this.
>
> On Thu, Mar 29, 2018 at 9:25 AM Pelle Braendgaard <
> pelle.braendgaard@consensys.net> wrote:
>
>> 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
>> <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
>