Rationale for inclusion of kid in recommended revocation id generation scheme about health-cards HOT 5 CLOSED

Thanks - given that the only jurisdiction I'm aware of in Canada with more than one active signing key is Saskatchewan, and that the secret_key varies by jurisdiction, I don't know that this is a huge concern.

One other comment WRT wording - I was initially confused by the term "base64url encoding" which I would ordinarily have interpreted to mean e.g.

base64:XR2ExUT53mCW65XHKv5FJg==

I would instead consider amending the spec to refer to this as "URL and filename safe base64 encoding".

from health-cards.

The idea is to act as a domain separator and generate a different revocation identifier rid for SHCs issued under a different key. We're trying to minimize the information disclosed by CRLs, and not using such a separator could result in the same rid being used in multiple CRLs (if a revoked user obtained SHCs from different keys, e.g., updated cards over time); information which could help identify listed users. These values are meant to be opaque and meaningless to verifiers, the spec recommendation minimizes information leakage.

I'm curious to learn more about the complications you are facing? You'd basically want to calculate and remember a rid once per user, and copy it into a CRL if needed? Different issuers will have different capabilities and requirements, so the rid calculation is essentially an implementation choice.

from health-cards.

In Canada many jurisdictions are using a federally-provided signing API, which provides endpoints returning an SVG or PDF with a common look and feel.

As such at the moment the system responsible for managing credential generation is not aware of the signing key used to sign a credential, and we would have to publish all rids associated with a user to every active signing key regardless.

I'm still trying to come to grips with the "shared rid" security implications - I would have expected virtually all revocations to be time-delimited, in which case timestamp would also be a giveaway (or at least I'm not aware of any situation where an individual can be "perma-banned").

from health-cards.

The rid calculation spec is up to the issuer; you have to balance your deployment (which are very specific in your case) and privacy requirements. Not using a kid in the calculation doesn't affect interop and the ability to validate issued SHCs, so you are free to proceed this way. Using a random secret key (seed) prevents preimage calculation, even without the kid (which like a salt, increases the attacker's work to reverse the calculation).

from health-cards.

I would instead consider amending the spec to refer to this as "URL and filename safe base64 encoding".

We use the term base64url encoded many times throughout the spec, but we should explicitely link to the standard. I also noticed the <kid> in the recommended rid calculation doesn't show up in the HTML version of the spec. I'll create a PR to fix that.

from health-cards.