update did keys as compressed keys

[bshambaugh]

I was able to take a first run at compressing the keys for P-521, P-384, and P-256:

I used this code:
https://gist.github.com/bshambaugh/60d90a32fd5b3bacd8113c631ba98491

I will double check that they resolve tomorrow.

[OR13]

These look good to me, but I have been bitten by uvarint before... @troyronda any chance you can confirm these?

[dmitrizagidulin]

👍
Looks reasonable to me (though I haven't confirmed the varint part).
Also (not a blocking comment, by any means), maybe it'd be less confusing if we used full URLs (instead of just hash fragments) for IDs?

[bshambaugh]

FWIW, this was a get it done fast attempt.

I'm still fine tuning this. I need to write more tests. Thus far my did:keys (compressed) look consistent for P-256, P-384, and P521.
https://github.com/bshambaugh/did-key-creator

Thus far my did:key documents from the resolver look okay for P-256 and P-384. I want to look more at P-521. The y component does not look good. The curve seems weird [1]. Of course, more tests.
https://github.com/bshambaugh/js-ceramic/tree/new-nist/packages/key-did-resolver/src

Curiously, my code has the multibase prefix u for base64url. This may be out of scope for this pull request.
https://github.com/multiformats/multibase

[1] https://stackoverflow.com/questions/50002149/why-p-521-public-key-x-y-some-time-is-65-bytes-some-time-is-66-bytes

[OR13]

@dmitrizagidulin I accept responsibility for promoting relative refs in did documents.... and I agree they are confusing...

[troyronda]

Here is what I get from decoding those values (using https://github.com/hyperledger/aries-framework-go/blob/fce55e1/pkg/vdr/fingerprint/fingerprint.go#L79):

zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv
Code: 0x1200
Base58 key: 23youFZZdHMVdpv28DRSWP2zJbTJ8KHBeSKUX3qVqqnmp

zDnaerDaTF5BXEavCrfRZEk316dpbLsfPDZ3WJ5hRTPFU2169
Code: 0x1200
Base58 key: 23FF9c3MrW7NkEW6uNDvdSKQMJ4YFTBXNMEPytZfYeE33

z82LkvCwHNreneWpsgPEbV3gu1C6NFJEBg4srfJ5gdxEsMGRJUz2sG9FE42shbn2xkZJh54
Code: 0x1201
Base58 key: VU8rNAMsMQvJuSKkQJ9LzVijuJyHZzx4PVXems4c8Zm282EoJbhf6qiBqkuodWHEF4

z82Lm1MpAkeJcix9K8TMiLd5NMAhnwkjjCBeWHXyu3U4oT2MVJJKXkcVBgjGhnLBn2Kaau9
Code: 0x1201
Base58 key: ad1jjx1hRrEkMWSsFsXpLULAbmUq67ii1jRsBNtYEKhCwLXTo4wcjY7C2K4cuGZ859

z2J9gaYxrKVpdoG9A4gRnmpnRCcxU6agDtFVVBVdn1JedouoZN7SzcyREXXzWgt3gGiwpoHq7K68X4m32D8HgzG8wv3sY5j7
Code: 0x1202
Base58 key: 4SsRN7NAk3175KrnPVQn5XTZE49MKdFKiq4XhWdhfx3QEUb2e96A3YLonFC6B21sa4uU776QMxEnxAQP6GWko8f3aNV

z2J9gcGdb2nEyMDmzQYv2QZQcM1vXktvy1Pw4MduSWxGabLZ9XESSWLQgbuPhwnXN7zP7HpTzWqrMTzaY5zWe6hpzJ2jnw4f
Code: 0x1202
Base58 key: 6AYA5PnWHzdwRCM22E2yDvRctNQ6SmgttyLCDAFeTNnzPbaUXW5c7uk139fn2HTA4bYMJrpEmBnJq2dLCiCoB7XJRi3

[msporny]

@OR13 wrote:

@dmitrizagidulin I accept responsibility for promoting relative refs in did documents.... and I agree they are confusing...

Can we stop using relative URLs in did:key (even in examples, then) and get rid of @base?

One really nasty side-effect that this is going to have is it's going to make CBOR-LD-style compression of things that would normally be compressible DIDs impossible. It's not so much an issue for did:key (but then, why are we trying to save space there ... the entire DID Document can be generated).... but it is a big issue for any other DID Method that might want CBOR-LD-style compression of some DID URLs. All of a sudden the URL compressors in CBOR-LD can't depend on the scheme identifier and just end up treating the fragment ID, which could have been compressible... as a string (that doesn't get compressed).

[OR13]

@msporny yes, I think we can now... The main reason our did:key implementations use relative refs (where these test vectors originally came from) is that sidetree uses them, and we like being able to test conformance easily... but we've learned to hate them over time...

All of the test vectors are out of date thanks to did core context changes (not a bad thing, but requires us to fix stuff in a lot of places).

IMO,

did:key test vectors should use 100% absolute DID URLs and cover all the key types for both application/did+json and application/did+ld+json... and @base can be safely removed (because no relative refs).

[OR13]

Useful reference: https://asecuritysite.com/encryption/ecc_points2

if (type=="P-192"):
	p = 2**192-2**64-1
	a=-3
	b=2455155546008943817740293915197451784769108058161191238065

if (type=="P-224"):
	b=18958286285566608000408668544493926415504680968679321075787234672564
	p = 2**224 - 2**96 + 1 
	a=-3

if (type=="P-256"):
	p = 2**256 - 2**224 + 2**192 + 2**96 - 1 
	a=-3
	b=41058363725152142129326129780047268409114441015993725554835256314039467401291

if (type=="P-384"):
	a=-3
	b=27580193559959705877849011840389048093056905856361568521428707301988689241309860865136260764883745107765439761230575
	p = 2**384 - 2**128 - 2**96 + 2**32 - 1 

if (type=="Curve25519"):
	a=486662
	b=1
	p = 2**255 - 19 

and people wonder about those NIST curves ... look at those cute little b values.

https://safecurves.cr.yp.to/rigid.html

[OR13]

I am in the process of confirming these results, here: transmute-industries/verifiable-data#55

So far I am able to at least confirm that elliptic and the "by hand" method agree for P256 / P384

[bshambaugh]

p-521
p = 2 ** 521 – 1. [1],[2]
( a = .. , b = ... ) [2]

[1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf, D.2.5. , p 104
[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186-draft.pdf, G.1.4 , p 58 &(( a = .. , b = ... ) 4.2.1.5 , p 15

[OR13]

I tested these, and I think they are correct.