Re: Secp256k1 key types standardizations

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>