Re: Secp256k1 key types standardizations

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

kim@learningmachine.com | kimhd@mit.edu
425-652-0150 | LearningMachine.com