w3c / vc-jose-cose

Verifiable Credentials Working Group — VC JSON Web Tokens specification
https://w3c.github.io/vc-jose-cose/
Other
31 stars 13 forks source link

how is `kid` to be `useful to distinguish the specific key used`? #117

Closed TallTed closed 1 year ago

TallTed commented 1 year ago

_Originally posted by @TallTed in https://github.com/w3c/vc-jwt/pull/111#discussion_r1244392502_

line 377 says (and another line says the same) --

If <code>kid</code> is also present, it is expected to be useful to distinguish the specific key used.

-- in response to which I ask --

how is kid to be useful to distinguish the specific key used? This cries out for an example, or a fair amount of additional prose.

OR13 commented 1 year ago

https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.4

   The "kid" (key ID) Header Parameter is a hint indicating which key
   was used to secure the JWS.  This parameter allows originators to
   explicitly signal a change of key to recipients.  The structure of
   the "kid" value is unspecified.  Its value MUST be a case-sensitive
   string.  Use of this Header Parameter is OPTIONAL.

   When used with a JWK, the "kid" value is used to match a JWK "kid"
   parameter value.

@TallTed how would you like this issue to be addressed?

TallTed commented 1 year ago

The best way I can see would be to reference the RFC section you quoted here. It doesn't provide much guidance on how kid can be used, but at least it makes clear that the lack of guidance is not our doing.

OR13 commented 1 year ago

In general, specs like ours are supposed to resolve this... similar to how data integrity proofs do today... and oidc does today...

TallTed commented 1 year ago

In general, specs like ours are supposed to resolve this... similar to how data integrity proofs do today... and oidc does today...

OK, so, who's going to provide the guidance about kid that's now missing from both our spec and the JWS RFC, which guidance is what I was asking for, and which is what I hoped to find in the RFC to which you pointed me, without saying "this RFC doesn't help" (which begs the question of why you pointed me there at all)?

OR13 commented 1 year ago

We are going to provide the guidance regarding our profile of JWT spec, just like how OIDF provided guidance regarding their profile of the JWT spec.

The guidance could be the same, or we can add additional instructions to support DIDs, as data integrity proof did with their retrieve verification material section.

TallTed commented 1 year ago

Which "we" is "going to provide the guidance regarding our profile of JWT spec"?

I guess you must mean the VC WG, of which some subset of participants must have the relevant knowledge required to provide this guidance... But which of us make up that subset?

vdods commented 1 year ago

I'd like to strongly recommend requiring the "kid" field when in the context of DIDs. In particular, when you sign using a public key attached to your DID, you should set the "kid" field to the DID fragment URL that specifies the specific key you used to sign. The "kid" field should include query params if appropriate (e.g. the hl param for content integrity protection, etc).

There is no reason not to require this, since you know what key you used when you signed, and in the case where the "kid" field is not set, verifying the signature involves trying every key listed by the DID for the appropriate key purpose. This is sloppy, inefficient, and makes detecting bugs in implementations harder.

Digital signature verification is more costly than signing. In a legitimate case where a DID has say 5 public keys for the relevant key purpose (say they have 5 devices each of whose pub keys are listed in the DID document), if the verifier had to try each of those 5 keys every time, the verification portion of your performance is 5x worse. At worst, a bad actor could create a DID having thousands of public keys in an attempt to DoS the service, and the system would need additional measures to prevent this.

Relevant links:

, and at worst could lead to a DoS attack where a DID intentionally lists many keys. Signature verification is more computationally costly than signing.

Sakurann commented 1 year ago

(btw this issue is being referenced in the spec three times :D)

iherman commented 1 year ago

The issue was discussed in a meeting on 2023-09-14

View the transcript #### 6.14. how is `kid` to be `useful to distinguish the specific key used`? (issue vc-jose-cose#117) _See github issue [vc-jose-cose#117](https://github.com/w3c/vc-jose-cose/issues/117)._ **Michael Jones:** has PR. � gets closed after the PR is merged. **Paul Dietrich:** this issue asks to define that it is more than a hint. � so the PR is not enough. **Kristina Yasuda:** . > *Brent Zundel:* when writing the PR I realized there was an additional ask, so I tried to express that a kid isn't just a hint, but a hint for a hint, checking that wasn't enough? **Paul Dietrich:** yes.
OR13 commented 1 year ago

This issue can't be closed until https://github.com/w3c/vc-jose-cose/pull/153#issuecomment-1723406924 is addressed.

OR13 commented 1 year ago

I took a stab at this, see #163 please help us close this.

selfissued commented 1 year ago

Closing this, since addressed by the PR.