Should did-core restrict the use of JWK?

[OR13]

There was some debate on the did core registries about whether JWK is safe to allow in did documents, without this spec making some restrictions:

• Add Support for publicKeyJwk did-extensions#20

This thread has some similar arguments:

https://github.com/transmute-industries/lds-jws2020/issues/4

Probably a special call is needed to address this....

[OR13]

Noting that existing verification methods, are currently not defined in did core, at all.... w3c/did-extensions#21

So this will indeed be difficult to do :)

[Edit: this is not longer the case !]

[OR13]

I'd argue this ticket is not possible to address, and is outside of the scope of this WG... DID Method Implementers may choose to use jwks and NONE of the existing verificationMethods defined in the current spec, and rely on all the the machinery that is defined in JOSE and OIDC / OAuth2.0... the only thing preventing interop via jwks would be its inclusion as a verification method in the did core registries, and even if it never gets added there... DID methods could still implement support for it and have interop.

Because how a DID Method treats publicKeyJwk is defined in the DID Method software, we cannot mandate that the software ignore / or enforce properties defined in the DID Core data model...

There is no way to reflect the RFC compliant data model for a JWK in JSON-LD other than using @json, although it is possible to do this more accurately in JSON Schema.

From the charter:

https://www.w3.org/2019/09/did-wg-charter.html

Defining specific authentication, signing, or cryptography mechanisms. Scope is limited to defining extension points for these mechanisms. (See "Scope".)

I consider altering the expected behavior of JWKs to be defining a specific cryptographic mechanism for expressing keys, and their relationship to signing / encryption (limiting JWK functionality defines through exclusion a novel cryptographic representation).

From the in scope section:

Define extension points enabling authentication, signing and cryptography mechanisms, but not defining specific authentication, signing, or cryptography mechanisms. (See "Out of Scope".)

extending JWK to work with DIDs seems fine to me (by adding them to a did document).... disabling expected functionality defined by IETF for JWKs, is not an extension, it is a restriction, one which alters what can be expressed as a JWK... this means we would be defining a new cryptographic standard for "DID Document JWKs", which are like "JWKs" but limited by the DID Core working group.

Further, we had multiple calls where we agreed that JWK was a valid representation for all possible key types in the did document... Are we asserting now that we did not understand the defintion of a JWK on those calls? when we say JWK, are we sure we are talking about the RFC? or were some people imagining that JWK mean't "JWK but with some restrictions I have not yet shared with the group"...

On those key representation calls, and in general... when I hear "JWK" I think we are talking about:

https://tools.ietf.org/html/rfc7517

When I hear "verificationMethod" I think of this language from the did core spec:

A public key is just one type of verification method. A DID document expresses the relationship between the DID subject and a verification method using a verification relationship. Examples of verification relationships include: authentication, capabilityInvocation, capabilityDelegation, keyAgreement, and assertionMethod. A DID controller MUST be explicit about the verification relationship between the DID subject and the verification method. Verification methods that are not associated with a particular verification relationship MUST NOT be used for that verification relationship. See Section § 7.4 Authentication for a more detailed example of a verification relationship.

I am unable to find definitions for:

1. assertionMethod (occurs once in the document, no defintion)
2. capabilityInvocation (occurs twice, no defintion)
3. capabilityDelegation (occurs once, no defintion)
4. keyAgreement (occurs once, no defintion)

authentication and publicKey are the only verificationMethods currently defined in did core.

All of the current verificationMethods rely on:

"sec": "https://w3id.org/security#",

For their vocabulary definitions in JSON-LD, (and since these are not defined anywhere else in did core, this is the only place i could look for definitions).

https://w3id.org/security#assertionMethod
https://w3id.org/security#capabilityInvocation
https://w3id.org/security#capabilityDelegation
https://w3id.org/security#keyAgreement

^ none of these definitions exist.

How can we as a working group understand the relationship between something that is defined in an IETF RFC, and things which have 1 or 2 references in did core, and 0 definitions in a web page that was last updated in 2016.

If the main objection to defining properties further, is that we cannot continue to define properties until

https://w3id.org/security is updated... I completely agree, and have stated so on the did core registries.

Since this working group cannot update w3id.org, we have a blocking external dependency, that no one in this WG can fix... On the last did core registries call, people objected to even discussing w3id.org and JSON-LD fixes on the call... So I'm worried we won't be able to make any progress on this issue at all.

I propose the following solutions to this problem:

1. We define in repos that this WG can control, all terminology, and ONLY link to external vocabularies when definitions exist.

2. We get consensus as a WG on what "JWK" means... I propose that it is defined in an RFC, and that any substantive change to what is defined in that RFC would make whatever results "DID JWK" or "Restricted JWK" or ... not a JWK.

[OR13]

@msporny I suggest we add the label "security" / "critical-blocker" to this, and @burnburn @brentzundel we probably need some time on a call to discuss this issue.

[selfissued]

I agree that resolving this should be a priority and warrants a special call.

[kdenhartog]

It looks like JWKs are in the registry after PR 20 was merged. However, if I understood the thread correctly, we still have concerns. Is that correct @OR13 ?

[OR13]

@kdenhartog @msporny requested we discuss the implications of supporting the full JWK RFC: https://tools.ietf.org/html/rfc7517

Based on the comments in the PR, it seems that there are 2 positions which need to be debated:

1. JWK is not safe to include without restriction by did core, because of undefined interactions with did core verificationMethods.
2. JWK is safe to use without restriction, and DID Methods can rely on the JWK defintion provided by the RFC.

I will update the title of the ticket for clarity.

[msporny]

These are things that we should consider restricting in JWK in order to narrow the security attack surface for DID Methods that chose to use JWK. I expect that a number of these suggestions will be controversial (and thus, not all of them will stick):

• Prohibit the use of RSA keys, as there are better Elliptic Curve approaches that can be used today that are vetted and accepted by most large governments, the security research community, etc. For example, Ed25519, Secp256r1, etc.
• Prohibit the use of RSA-based algorithms - e.g., consider RS1, RSA1_5, RSAES-PKCS1-v1_5, RSA-OAEP, RSAES OAEP, RSA-OAEP-256
• Prohibit the use of CTR-based and CBC-based algorithms - A128CBC-HS256, A192CBC-HS384, A256CBC-HS512
• Mandate the use and alignment of use and key_ops with proofPurpose in the DID Core spec, preventing a mismatch between proofPurpose and use and key_ops.
• Prohibit the expression of the d parameter (EC/RSA/OKP Private Key/Exponent).
• Prohibit the expression of SHA-1 fingerprints via the use of the x5t parameter.

That's just off of the top of my head, there may be others, but not limiting JWK at all will result in a much larger security attack surface and thus a far weaker DID Core specification.

[selfissued]

Rather than trying to rule out uses of specific algorithms and features, it would probably be more productive to define which specific algorithms are RECOMMENDED and REQUIRED. The nature of active registries is that things will be added over time. If you're saying "don't do X, Y, and Z" and then "P, D, and Q" get added, the presumption will be that use of anything added is fair game.

[msporny]

Rather than trying to rule out uses of specific algorithms and features, it would probably be more productive to define which specific algorithms are RECOMMENDED and REQUIRED. The nature of active registries is that things will be added over time. If you're saying "don't do X, Y, and Z" and then "P, D, and Q" get added, the presumption will be that use of anything added is fair game.

I almost completely agree with you that it would be a better approach. I'll note that RSA is still Recommended/Recommended+ -- and this community might not be aligned with that viewpoint. I don't know of any DID Method that uses RSA... that said, given verification methods, it's going to be difficult to eliminate RSA due to deployed infrastructure.

[msporny]

We need to have a special topic call on this to discuss JsonWebKey2020 and whether or not we should restrict JWKs expressed in DID Documents.

[msporny]

We can discuss this on the same special topic call as #170.

[baha-ai]

Is this topic still alive?

I'm currently hitting a wall where we need to use ECDH-ES / ECDH-1PU kw with JWE(encryption side using any EC key) while maintaining the normal verification methods using say Ed25519VerificationKey2018.

There is no way in the spec that shows this verification vs encryption keys separation.

I noticed KeyAgreement is being used for a similar purpose, but it only specifies X25519KeyAgreementKey2019 which can be seen as an Ed25519 key conversion mechanism.

I would love to see other types of key agreements where peers can use different keys for verification and encryption (other than the correlated Ed25519 to X25519 key conversion). For instance a peer may use a key of type Ed25519VerificationKey2018 for verification but for key agreement prefers to use something like Ecdh-esP384KWAesGcmP256Key (or Ecdh-esP384KWAgreementKey2020 to be consistent with the other key types in the spec). No new syntax is needed, the new Key Agreement can simply be represented as a JsonWebKey2020.

There's currently no way to implement a new key agreement type unless I invent a new one on my own which breaks interoperability. Currently I need the following types:
Ecdh-esP256KWAgreementKey2020
Ecdh-esP384KWAgreementKey2020
Ecdh-esP521KWAgreement2Key020
Ecdh-1puP256KWAgreementKey2020
Ecdh-1puP384KWAgreementKey2020
Ecdh-1puP521KWAgreementKey2020

where ECDH-1PU is defined here and the KW process comes from NIST.800-56A (Section 5.8.2.1)

Eventually, I'm looking to add the following ones once the above are integrated in our framework:
Ecdh-esX25519KWAgreementKey2020
Ecdh-1puX25519KWAgreementKey2020

I strongly believe in key separation of purpose (or aimed use), e.g: there should be no correlation/conversion between them like the case of Ed25519VerificationKey2018 and X25519KeyAgreementKey2019. By adding different key agreement types, then verification methods become independent from key agreement ones.

My apologies for interjecting into this issue, but I thought since the discussion here was about JWKs, this comment seems somewhat related. I can create a new issue if it makes sense.

[kdenhartog]

This is the exact problem I was trying to resolve by creating JsonWebKey2020. See this comment for reference: https://github.com/w3c-ccg/lds-jws2020/issues/11#issuecomment-642308779

In sum total, I don't think the restriction around KeyAgreement or VerificationKey suites get us what we want and by deciding to use JsonWebKey2020 and setting good recommendations (e.g. MUST NOT use prohibited algs in the JOSE registries) around how JWKs should be used, we'll be setting ourselves up for a good balance between allowing things that people need for the variety of restrictions encountered while also managing to get a high degree of interoperability.

[baha-ai]

This is the exact problem I was trying to resolve by creating JsonWebKey2020. See this comment for reference: w3c-ccg/lds-jws2020#11 (comment)

In sum total, I don't think the restriction around KeyAgreement or VerificationKey suites get us what we want and by deciding to use JsonWebKey2020 and setting good recommendations (e.g. MUST NOT use prohibited algs in the JOSE registries) around how JWKs should be used, we'll be setting ourselves up for a good balance between allowing things that people need for the variety of restrictions encountered while also managing to get a high degree of interoperability.

The thread you linked is closely related to my comment @kdenhartog. I do agree with the last paragraph of your referenced comment, we're saying the same thing: to not share/correlate signing and encryption keys.

I'm open to using JsonWebKey2020 for the ECDH key wrapping algorithms. The reason why I find ...AgreementKey2020 useful is the separation of the key purpose in the DID document. It's more a question of where to locate encryption keys (hint: keyAgreement for packing) vs the document's root PublicKey used as a verification key. I don't want to mix it with the authentication method to not confuse the reader/developer further. This key agreement should portray a 1:1 link between a verification key and a packing (encryption) key without any correlation or conversion between the two.

[baha-ai]

@kdenhartog to emphasize my point about key formats for these new keys. I too want these new key agreement types to be JsonWebKey2020, supporting the did:key format is not useful for EC keys.

JSON marshalled JWKs are standard, we can probably base64URL encode the marshalled value.

[OR13]

@Baha-sk FYI, did:key can support any multicodec supported key representation... https://github.com/transmute-industries/did-key.js

Trying to understand your last comment.... are you saying you think that a verificationMethod.type should be bound 1:1 to a https://w3c.github.io/did-core/#verification-relationships ?

Thats not the case today Ed25519VerificationKey2018 is present in multiple relationships....

@kdenhartog and I are proposing that the same be possible with JsonWebKey2020.... you can put it in publicKey, authentication or keyAgreement...

Speaking for my self / my company.... I am really opposed to JSON-LD naming conventions degrading the usability of JOSE... thats why we created that suite in the first place.... to make JOSE work with DIDs... and JOSE keys are called JSON Web Keys.... not verification and key agreement keys.... we already encode purpose in the relationship, we don't need to repeat it in the key name... and if you want to... go ahead and create a new ld crypto suite.... its up the the suite author to name the verificationMethod type and proof type... I created that suite, and chose JsonWebKey2020 (thanks for @kdenhartog 's name change) and JsonWebSignature2020.... since ld suites generally have no guidance on encryption, I closed that loop explicitly with this table:

https://github.com/w3c-ccg/lds-jws2020#supported-jose-algorithms

BTW... the same issue also exists for GPG suites... https://github.com/transmute-industries/lds-gpg2020

Because both GPG and JOSE have their own concept of 1 key representations for multiple key types... and its insanity to expect people familiar with these technologies to create a new ld suite for each key type.... just to give an idea of what that would look like:

• JsonWebKeyP256VerificationKey2020
• JsonWebKeyP384VerificationKey2020
• JsonWebKeyEd25519VerificationKey2020
• JsonWebKeyX25519VerificationKey2020
• JsonWebKeySecp256k1VerificationKey2020
• GpgP256VerificationKey2020
• GpgP384VerificationKey2020
• GpgEd25519VerificationKey2020
• GpgX25519VerificationKey2020
• GpgSecp256k1VerificationKey2020

... now repeat for ...KeyAgreement2020.... nobody is going to do this.

Or....

• JsonWebKey2020 (with table restrictions for 2020)
• GpgVerificationKey2020 (no table of restrictions currently, and obviously support for encryption for key types)

I'd say GpgVerificationKey2020 should really be OpenPgpKey2020 with a similar table.

[msporny]

I'd say GpgVerificationKey2020 should really be OpenPgpKey2020 with a similar table.

I think this is the last point of contention. We went to great lengths with Linked Data Security to be very clear about what a key should be used for. While many developers that work with crypto on a regular basis don't really think about how weird the term "public key" and "private key" is... it's really weird... and really terrible. Both words are terrible because they don't map to what their real world equivalents do (the analogy breaks down in horrible ways). The PKI industry's first major sin was using the wrong analogy... digital signatures don't work like physical keys. They work more like royal seals and decoder rings.

I have had multiple conversations with developers that thought that a "private key" is something you keep on your Apple Keychain, but it's totally fine to publish it to the Internet, because "I can take my private physical keys out of my pocket and jingle them at someone and that's totally fine... they can't get into my house until I give them my keys." Apple keeps my Keychain keys safe, so I can take anything from that chain and publish it and I'll still be safe (except, you won't be). There is also a misguided notion that a "public key" is used to do signatures, when it's really meant to mainly do verification of a digital signature.

So, we have tried very hard to type keys that are used publicly with something that people with no knowledge of crypto can understand... like "VerificationKey"... but even that is bad, because it has nothing to do with how you use a physical key. Cryptographers have traditionally been really terrible at picking good names... d, x, dp, dq, ed25519... what is wrong with our industry!? These violate even the "name your variables with useful names" tenet that most of us follow in our code.

So, this goes back to the problem with JsonWebKey2020 -- it's not clear what that key is used for, and that's a problem, because someone is going to stuff a private key in there and publish it and there is no reason we should enable someone to do that. In a more ideal world, we would at least change the name to JwkVerificationKey2020 and not allow the expression of private keys using that data structure.

"But, I want to be able to express private keys!?" I hear some poor developer lament. The answer to that is "Great, figure out how to do that in your application"... because the second we give some misguided soul the ability to do that using a standard term, that someone will shove it into JsonWebKey2020 and compromise their organization because they didn't know any better. The expression of private keys is exactly where we do not want interoperability. Let everyone do it in a different way to ensure that it's far more difficult to accidentally publish a private key in a standard way. Yes, I understand there are legitimate use cases where you want to exfiltrate keys... good, you should figure out how to do that yourself, that's an exception, not a general operation that we should support with a standard.

In a more ideal world, we would be using something like StrongSignatureVerifier2020 and MilitarySignatureVerifier2020 to refer to the cryptographic mechanism used to verify digital signatures... no use of the term "public/private" and no use of the term "key". There would also be no global standard for expressing private keys at the application layer, because we don't need to hand the industry that foot gun.

So, all that to say, can we please at least name JsonWebKey2020 something like JwkVerificationKey2020. Ideally, making the use of that to express a private key throw errors in some way?

[baha-ai]

@Baha-sk FYI, did:key can support any multicodec supported key representation... https://github.com/transmute-industries/did-key.js

Trying to understand your last comment.... are you saying you think that a verificationMethod.type should be bound 1:1 to a https://w3c.github.io/did-core/#verification-relationships ?

Thats not the case today Ed25519VerificationKey2018 is present in multiple relationships....

That's not what I meant @OR13 . It is ok to have multiple relationships for keys in a DID doc, I'm saying we need to separate the encryption key from being 'converted' from the verification key as is the case today (Ed25519 -> X25519). The closest I can think of adding this separation is to have a 1:1 link between verification key and an KeyAgreement entry (representing an encryption key that's unrelated to the verification key) to state that this DID doc can be verified for verKey A and can be packed (encrypted) by keyAgreement B. Keys A and B can be totally different, say A can be Ed25519 key and B can be P-384 EC key.

I closed that loop explicitly with this table:

https://github.com/w3c-ccg/lds-jws2020#supported-jose-algorithms

I like this table, it's definitely useful. Although as we try to introduce Anoncrypt vs Authcrypt packing of messages, there was a need to enhance the key wrapping algorithms by using a sender authentication mechanism like the Unified Process Model described by NIST. This means the introduction of new algorithms defined as "ECDH-1PU+A256KW" as shown in the table of this ietf draft: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03#section-2

I do agree with you though, using the key type and curve name can deduct the key wrapping algorithm, but now we need to differentiate between ECDH-ES (anoncrypt) vs ECDH-1PU (authcrypt) mode.

BTW... the same issue also exists for GPG suites... https://github.com/transmute-industries/lds-gpg2020

Because both GPG and JOSE have their own concept of 1 key representations for multiple key types... and its insanity to expect people familiar with these technologies to create a new ld suite for each key type.... just to give an idea of what that would look like:

• JsonWebKeyP256VerificationKey2020
• JsonWebKeyP384VerificationKey2020
• JsonWebKeyEd25519VerificationKey2020
• JsonWebKeyX25519VerificationKey2020
• JsonWebKeySecp256k1VerificationKey2020
• GpgP256VerificationKey2020
• GpgP384VerificationKey2020
• GpgEd25519VerificationKey2020
• GpgX25519VerificationKey2020
• GpgSecp256k1VerificationKey2020

... now repeat for ...KeyAgreement2020.... nobody is going to do this.

Or....

• JsonWebKey2020 (with table restrictions for 2020)
• GpgVerificationKey2020 (no table of restrictions currently, and obviously support for encryption for key types)

I'd say GpgVerificationKey2020 should really be OpenPgpKey2020 with a similar table.

the only available key agreement value right now is: X25519KeyAgreementKey2019
I need a way to tell the framework what kind of key to create other than X25519 and I need to tell it the purpose of the key. Even if it's just JsonWebKey2020, there should be a way to tell weather it's for authcrypt vs anoncrypt types of keys (even though both are technically exactly the same key types). This is the main reason I proposed the key agreements types. I do agree with you though, introducing a long list of key agreement types is not the best solution. Probably adding a purpose value would help?

[baha-ai]

So, all that to say, can we please at least name JsonWebKey2020 something like JwkVerificationKey2020. Ideally, making the use of that to express a private key throw errors in some way?

To me, Verification means signature verification, this implies the key is used solely for signing/verification.
I would love to see a format that defines the key purpose or use. I'm not too worried about private keys being accidentally added, the onus is on the framework to ensure keys exchanged are not private.

[msporny]

In did core the purpose is encoded in the verification relationship.

You are thinking too narrowly about just this use case. Note that LD Security keys can be expressed /anywhere/ (note: not the same thing as /used to verify a signature/) and some of those places (like a big bucket of cryptographic keys) don't give you that contextual information. Even if that contextual information exists, it's not the case that you always have access to that information, even if a system is operating on the same graph. For example, if you only send the graph for the key into a function, you lose context, so having the type information is useful in those use cases. You can't assume that you'll always have the relationship to the key.

[dlongley]

For example, if you only send the graph for the key into a function, you lose context, so having the type information is useful in those use cases. You can't assume that you'll always have the relationship to the key.

As a point of clarification: you're not doing LD sec right if, when you go to verify a proof, you don't check to make sure that the controller of the key authorized it for the appropriate purpose.

That aside, I think we do harm to conflate "proof purposes" with "key usage". A proof purpose (and its helper twin "verification relationship") is about encoding your intent into a proof such that a verifier can ensure the proof isn't accepted for an inappropriate purpose. This is not the same thing as expressing the type of cryptographic operation or protocol that a key should be used for -- which is what "key usage" is about. This "key usage" information is what is encoded in the key type with LD keys.

[msporny]

I think we have agreement that the LD Cryptosuite will do the restriction, not the DID Core spec.... does anyone object to that?

[OR13]

on the special topic call, we agree to add language regarding not putting private key stuff in a did document, but we have also agreed that the type of publicKeyJwk is @json.

[OR13]

leave this open until language is added.

[jonnycrunch]

So I think this still needs to be discussed on a special topic call. I'm still very much confused regarding the overlap of LD signature WG and our WG and who is on point to do what. We have painted ourselves into a corner with the necessity to support JWS and yet their is conflicting solutions on how to represent this in other formats such as CBOR/COSE. as @OR13 pointed out above we agreed that the type of publickeyJwk is @json and the extensibility to CBOR/COSE representation is unclear. I think more discussion is necessary. I also appreciate @dlongley point regarding conflating "proof purpose" with "key usage" and how to represent that clearly in the DID doc.

[kdenhartog]

pointed out above we agreed that the type of publickeyJwk is @JSON and the extensibility to CBOR/COSE representation is unclear.

Wouldn't a publicKeyJwk just be treated like any other JSON object that exists in a DID Document? I'm not sure I understand the conflict that you're seeing. I'm guessing it's because I'm making assumptions that you haven't though.

[OR13]

I suppose we need to create an INFRA structure that can be used to support the concept of JWK in order to close this issue.

[iherman]

I suppose we need to create an INFRA structure that can be used to support the concept of JWK in order to close this issue.

This would also make the DID Core vocabulary specification more complete. At this point, that part is really missing.

[msporny]

I suppose we need to create an INFRA structure that can be used to support the concept of JWK in order to close this issue.

No, we do not need to do this. The data model already supports anything you would want to express in JSON (modulo numbers, which we now have a resolution to fix).

Just because we can lots new datatypes doesn't mean we should -- that's the path to madness.

-1 to a JWK data type in the abstract data model; it's unnnecessary... the JWK structure can be expressed via an INFRA map and basic strings. We already support this in the spec today.

Anyone arguing for a new datatype needs to put forward a concrete use case that they want to accomplish that is impossible to accomplish given what we have today.

[OR13]

I don't understand. @jricher @talltree @peacekeeper

If we don't provide an example of every did core property in the abstract data model, how will people convert? If we don't need a JWK data type in the ADM.... why do we need any other data types (aside from number).

Do we need a data type for "cryptographic key" that can be converted to publicKeyJwk or publicKeyBase58 ?

[iherman]

I did not read the comment of @OR13 as a new data type. At least in my interpretation what is missing is a clear map with the JWK terms that we allow for the purpose of DID Documents. That seems to be missing right now.

[msporny]

We seem to have consensus to do the following:

1. Specify that no private properties are expressed for any cryptographic key type.
2. Defer to the Linked Data Cryptosuites to further restrict keys.

We need PRs for both items above.

[OR13]

editors to define publicKeyJwk and publicKeyBase58 in did core (security vocab urls not to change), then remove definitions for verificationMethod.type and instead point to external examples.

[OR13]

Still waiting on #240 (comment)

Proposed text:

    <p class="advisment">Do not include extraneous or private information in verification methods. The class of private information related to JWKs is defined <a href="https://tools.ietf.org/html/rfc7517#section-8.1.1">here</a>.</p>

[msporny]

PR #490 addresses this and has been merged. Closing.