search

oauth-wg / oauth-sd-jwt-vc

draft-terbu-sd-jwt-vc
Creative Commons Zero v1.0 Universal
20 stars 12 forks source link

Issuer-signed JWT Verification Key Validation - Separation of signature and identity verification/validation? #253

Open alenhorvat opened 2 months ago

alenhorvat commented 2 months ago

There seem to be several mechanisms for issuer key validation (section 3.5).

Two mechanisms define fetching of keys (issuer metadata, DID), and one can be embedded or referenced (x509).

Would it make sense to enable signature validation at all times and

Public key - identity binding can be verified

kid could be misused to express the validation mechanism or one could define an additional header claim where identity verification mechanism is specified:

peacekeeper commented 2 months ago

I think this makes sense only in the case of embedded X509 certificate.

Otherwise, I think the "validation mechanism" (e.g. resolving the DID or downloading the keys from a web server) would always have to be executed anyway. There would be no extra value in having an embedded signing key, since an attacker that can replace the signature can also replace the signing key. And there would be a risk that implementers create security holes by considering the "validation mechanism" as something optional...

Or am I missing anything?

alenhorvat commented 2 months ago

Excellent point @peacekeeper!

There are always 2 processes

  1. Verifying the signature: By embedding a key, the signature can be always verified. This does not exclude an option to resolve the key.
  2. Verifying the signer's identity: each method defines it's own process: x509 embedded or referenced (referenced x509 is almost never used); .well-known -> resolve the URL, DID -> resolve the DID (URL)

In many environments (high-loads, low connectivity, ...) we cannot rely on ". resolving the DID or downloading the keys from a web server would always have to be executed anyway". Furthermore, if the resource is not available, again, signature validation fails. Hence, these mechanisms (well-known, DIDs) should also define how identity information could be embedded in the signature (like x509, OIDFed, advanced signatures are already doing) - but this is out of scope of this specification and discussion.

peacekeeper commented 2 months ago

Thanks @alenhorvat

By embedding a key, the signature can be always verified.

Yes, but what's the value of knowing that a payload has been signed by "someone", if you don't know who that key belongs to?

define how identity information could be embedded in the signature

Yes that sounds useful!

alenhorvat commented 2 months ago

Yes, but what's the value of knowing that a payload has been signed by "someone", if you don't know who that key belongs to?

Goal is a bit broader - to clearly split and define the two processes, and show that x509 verification or .well-known/DIDs are all process of verifying the identity/identifier of the signer (link between a public key and an identifier).

awoie commented 1 month ago

We discussed this topic with the other editor's. Our opinion is that including the jwk in the header would be quite dangerous since it would encourage implementations to always use the jwk and skip all the other validation checks.

@alenhorvat Is there a specific use case you have in mind that would be blocked by this?

alenhorvat commented 1 month ago

Challenges

Implementers MUST understand how to verify the identity, independently of the signature validation. This also forces the standard to clearly define the two verification streams.

alenhorvat commented 1 month ago

Related question: What prevents a malicious issuer to define an issuer identifier: happy-issuer.com/issuers/google.com?

How can the Verifier/RP know whether issuer is truly Google or not?

awoie commented 1 month ago

Challenges

  • RP needs to resolve a key to verify a signature - issues for offline cases
  • if RP needs to verify a high number of VCs issued by different issuers, results with additional effort to resolve the keys
  • managing and resolving historical keys/key rotation -- you can have several key rotation in the lifecycle of a credential.

Implementers MUST understand how to verify the identity, independently of the signature validation. This also forces the standard to clearly define the two verification streams.

I think one way to address this is as follows and you have alluded to the same thing in your previous post:

This way, a verifier can cache the trusted root cert and use the contained end-entity cert in the x5c to validate the X.509 chain and verify the signature.

For simplicity I didn't mention intermediate certs but they can be included in the x5c header as well.

This behaviour is enforced by X.509 itself (RFC5280) which requires certificate chain validation. If implementations don't have a trust point, the x5c would not be trusted and therefore rejected.

It seems you want to define the same thing for jwk? Why is using X.509 not an option in this case?

If you want to use DIDs and/or issuer metadata, wouldn't it be possible to support the use cases you just mentioned by simply caching DID resolution or the issuer metadata URL?

alenhorvat commented 1 month ago

IMO x5c/x5u+x5t are enough, but this document puts x509, jwk+URL, and DID on the same level. It might work for some DID methods and it might work if JWK "trust model" is clearly defined; e.g., see the example above where a malicious actor lists an issuer as one of their clients. It can be translated to an x509 model, where RP must define which "Root JWKs" it trusts (e.g., service providers that offer VC issuance as a service and URL contains 2 identifiers, of the provider (e.g., mattr) and the actual issuer (e.g., university of wonderland))

awoie commented 1 month ago

Related question: What prevents a malicious issuer to define an issuer identifier: happy-issuer.com/issuers/google.com?

How can the Verifier/RP know whether issuer is truly Google or not?

Nothing, but I believe this issue is solved by the trust framework and the provided trust points, isn't it? There are various mechanisms and based on my prior observations of different trust frameworks, there can be a lot of differences.

In your specific example which I think has to be corrected (since an attacker would need to use Google's domain in the issuer identifier and not happy-issuer.com, to pretend to be Google), I believe the trust point is Internet PKI and if you don't trust the Internet PKI, it probably makes no sense to rely on issuer well-known alone or at all.

You can combine this with X.509 (or even DIDs if required).

alenhorvat commented 1 month ago

In your specific example which I think has to be corrected (since an attacker would need to use Google's domain in the issuer identifier and not happy-issuer.com, to pretend to be Google)

wouldn't the "iss" value be: happy-issuer.com/issuers/google.com? I don't need to know google's domain to do that. I only need my domain.

x509 -> originates from own framework and defines the rules; no problems here DID method (if defined well), can achieve same as x509 jwk -> you are defining a trust model for this in section 5 (https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-05.html#name-jwt-vc-issuer-metadata)

awoie commented 1 month ago

In your specific example which I think has to be corrected (since an attacker would need to use Google's domain in the issuer identifier and not happy-issuer.com, to pretend to be Google)

wouldn't the "iss" value be: happy-issuer.com/issuers/google.com? I don't need to know google's domain to do that. I only need my domain.

Perhaps we are talking past each other but I thought you were concerned about impersonating Google in your example. I was saying that there is no reason for a verifier to think that the identity of happy-issuer.com/issuers/google.com is Google if it doesn't use one of Google's domains, right?

alenhorvat commented 1 month ago

What is google's identifier if they are using service hosted by the happy issuer? happy user is managing signing keys of google and it assigned google an identifier in their multi-tenant system as happy-issuer.com/issuers/google.com

(in the case of using jwk + URL in the iss; when using x509 and (some) DID methods it's clear and it's irrelevant if the service is self-managed or is managed by a 3rd party)