Re: Secp256k1 key types standardizations

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>
>