[Request] Support JWK & JWS representation and secp256r1 & secp256k1 encryption

[Aconitin]

Description

Add support for JWK & JWS representations as well as secp256r1 & secp256k1 encryption and verification.

Motivation

We parse DID Documents and VCs byte-wise in hardware. In order for our hardware to be compatible with identity.rs, we need to be able to represent keys as JWK/JWS instead of JCS, and to encrypt/verify using secp256r1 & secp256k1.

Note that all of this is of course supported by the W3C DID/VC Standards.

Requirements

Encoding types

• JWK (JSON Web Key) for keys. In e.g. DID Documents, this representation would look like this instead of e.g. this.
• JWS (JSON Web Signature) for signatures (within e.g. proof fields), e.g. this

Encryption types

• secp256r1 aka P-256
• secp256k1

Are you planning to do it yourself in a pull request?

No, as of now.

[cycraig]

It is unlikely that we will be able to add full JWK and/or secp256* support for encrypting, signing or verifying any time SoonTM, especially since those features would need to be integrated into and exposed by Stronghold too.

We will, however, look into allowing arbitrary verification method types and public key material (including JWK) in DID Documents. No timeframes are promised though.

Would you require the top-level signature/proof on published DID Documents to use those methods too, as opposed to Ed25519+JCS?

[Aconitin]

Would you require the top-level signature/proof on published DID Documents to use those methods too, as opposed to Ed25519+JCS?

Yes.

since those features would need to be integrated into and exposed by Stronghold too

Why would Stronghold need to support this as well?

[cycraig]

Why would Stronghold need to support this as well?

For secure key management and operations, Stronghold has to expose the cryptographic operations required for us to call via the Account when used as the backing key storage.

It probably won't affect you if you're using specialised hardware and not going through Stronghold or the Account, but we are unlikely to add half-baked features that are not fully supported by default in a secure manner. Particularly if we have to rush them, as that may lead to inconsistencies hindering interoperability with other libraries or insecurities at worst.

Would you require the top-level signature/proof on published DID Documents to use those methods too, as opposed to Ed25519+JCS?

Yes.

I speak for myself but I would be opposed to changing the protocol to support both Ed25519 and secp256*/JWS for the DID Document itself, since that affects the DID tag identifier (which is derived from the public key).

Supporting them in verification methods for encrypting/signing/verifying external data is far simpler as it would not require changing the DID method specification.

[Aconitin]

features that are not fully supported by default in a secure manner

That makes sense, thank you 👍

[eike-hass]

I speak for myself but I would be opposed to changing the protocol to support both Ed25519 and secp256*/JWS for the DID Document itself, since that affects the DID tag identifier (which is derived from the public key).

Supporting them in verification methods for encrypting/signing/verifying external data is far simpler as it would not require changing the DID method specification.

I agree, changing the top-level proof would change the DID method quite significantly, while also making backwards- and forwards-compatibility difficult.

[eike-hass]

General cryptographic agility is now tracked in #1037.