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