X25519KeyAgreementKey2019 and X25519KeyAgreementKey2020
OR13 opened this issue · comments
X25519KeyAgreementKey2019 is not defined very well, but referenced by various community members as if it can be used reliably.
X25519KeyAgreementKey2020 remain not defined at all.
We think the language could be improved... probably by some folks working on EDVs and DIDComm.
See #109 (comment)
To be honest X25519KeyAgreementKey2019 is only useful to define an Ed25519 converted key as VM (VerificationMethods in a DID) type. We should not rely on key dependance, ie currently if we have an authentication VM with type Ed25519, here's the corresponding X25519 converted key for encryption. We should rather have an authentication VM and another KeyAgreement VM that's totally independent of the key in the authentication, the VM type could be JsonWebKey2020 to support any JWK EC or OKP key type, not only X25519. This way authentication and encryption keys can be independent.
The issue with X25519KeyAgreementKey2019 VM type is it alludes to a converted key of another key stored in an authentication VM (in the DID world). Using a more generic VM type, ie JsonWebKey2020, adds flexibility to support multiple key types and avoids key dependability.
X25519KeyAgreementKey2019 should not "allude to key derivation"... we use this type for keys generated directly from randomness.
for example, compare:
not key derivation, but key conversion. i mentioned alludes to a converted key of another key
derivation and conversion are 2 different things (but i guess in the Ed25519 -> X25519, it's the same thing since scalar mult() is also key derivation)
by the way, i like how your keys examples above set the type as "type": "JsonWebKey2020",, i'm 100% ok with this.
The question I've always wondered is why X25519KeyAgreement prefix in particular? what about EC P-256, P-384 or P-521 types or the Bitcoin curve key (ES-256k1)? don't they deserve their own types as well? Personally, I prefer JsonWebKey2020 because it's more generic and supports any key type, even BBS keys.
We support X25519KeyAgreementKey2019 because it was there since the start, not sure what benefit X25519KeyAgreementKey2020 adds.
@Baha-sk see this thread:
https://github.com/w3c-ccg/lds-jws2020/issues/4
TLDR:
Linked Data Suites define a "verificationMethod.type" and a "proof.type"... some folks want to see this:
P256KeyAgreementKey2021,P256VerificationKey2021,P256Signature2021
Other folks want to see this:
JsonWebKey2020,JsonWebSignature2020
If you change the type you break the information representation, and the signature...
It depends on how you plan to handle the "latest recommendations"....
Do you want CurveName.CurveUse.Date for all curves?
Or...
StandardSuites.Date
What happens if only 1 curve in standard suites 2020 is broken next year?
@Baha-sk,
The question I've always wondered is why X25519KeyAgreement prefix in particular? what about EC P-256, P-384 or P-521 types or the Bitcoin curve key (ES-256k1)? don't they deserve their own types as well? Personally, I prefer JsonWebKey2020 because it's more generic and supports any key type, even BBS keys.
The reason for this is that it is an attempt to help avoid too much cryptographic agility which leads to foot guns and vulnerabilities.
However, we've been working on a future compromise for this where the vocabulary terms needn't change by using a constant type of something like "RecommendedVerificationKey" but adding a broken out property of "version" or "year" (TBD) that is used to express the current recommended version/year. This version/year would be an indirection that maps to at most two different acceptable algorithms (as opposed to allowing the direct expression of any algorithm from a registry as JOSE does). Combining this with multibase-multicodec encoded key material could provide the checks needed to meet the safety goals.
In short, this sort of approach could be a good compromise that helps achieve the goals of safer, limited cryptoagility whilst reducing vocab and library churn when upgrades are eventually needed.
We should not rely on key dependance, ie currently if we have an authentication VM with type Ed25519, here's the corresponding X25519 converted key for encryption. We should rather have an authentication VM and another KeyAgreement VM that's totally independent of the key in the authentication...
If the concern is over a potential vulnerability with using the same key for Ed25519 and X25519, this is now required reading for anyone working in this space: https://eprint.iacr.org/2021/509
if we don't want to take the JOSE path (to limit the keys we ought to support), then key types should be specific to the key itself, not its purpose or use.
Not so good examples: P256KeyAgreementKey2021, P256VerificationKey2021, P256Signature2021
I see 2 issues with these examples:
-
what's the difference between signature and verification? of course the private key is used for signing and public key for verification, but this is unnecessary because the key content will tell if it's a private or public key, if we want to distinguish private from public keys, then add the word in the type (eg:
P256PublicKey2021), but since we shouldn't be exchanging private keys, key names should be assumed to be public keys, egP256Key2021. But Jose does a good job in defining any keys, public or private. -
the key purpose is another issue, is it necessary to convey it in the type? I think this is unnecessary because you will have this info in the DID's VerificationMethod types (Authentication, Authorization, KeyAgreement, etc).
Better examples, imo: P256Key2021, P384Key2021, P521Key2021, ED25519Key2021, X25519Key2021, BLSKey2021, etc.