I think it sounds rather problematic to allow ambiguous situations where
you have an identifier and multiple possible ways of resolving it,
without a clear indication which one should be used.
In my opinion, this information can't be in the credential or in a
verifier config, it needs to be fully self-contained in the identifier
itself.
I know DIDs are a controversial topic in this group right now, but the
construct of "DID methods" is designed for exactly that. Here's the
definition from the W3C DID Core spec:
"DID method = A definition of how a specific DID method scheme is
implemented. A DID method is defined by a DID method specification,
which specifies the precise operations by which DIDs and DID documents
are created, resolved, updated, and deactivated."
So e.g. if you have an "iss" with a value like "did:web:danubetech.com",
then there is only one way of resolving it to its public keys and other
metadata.
Markus
On 12/13/24 2:17 AM, Watson Ladd wrote:
On Wed, Dec 11, 2024 at 2:56 PM Brian Campbell
<bcampb...@pingidentity.com> wrote:
Thanks Watson,
I'm trying to synthesize this in my own thinking. So please tell me if I'm off
base. Effectively one manifestation of this is as a problem is a verifier,
which only uses an https issuer value to find issuer metadata and key(s), that
is checking a credential from an issuer who has embedded a certificate in an
x5c header. Then at some point the issuer loses control of the domain for
whatever reason and it's registered by a malicious actor who posts their own
keys there and proceeds to forge credentials that would be acceptable to such a
verifier.
Does that track with what you're driving at?
Yeah that would be an example. But it could also be the verifier
supporting both, and getting a credential made by the attacker without
the x5c entry, so it has to fall back to issuer metadata.
There's likely a number of ways to tighten this up, one being some kind of
explicit indicator of the intended resolution mechanism(s) in the credential
itself. I think a couple of people mentioned that during the call. I'm not sure
I'm convinced of that yet but maybe. Seems like it might just be pushing some
pieces around. But maybe. As you say, it does suggest that something more needs
to be said about what the root(s) of trust look like.
It can't be in the credential. The attacker generates the credential
that they use in the attack. The existing ones aren't really relevant.
Has to be in the verifier config, attached to the issuers that are
accepted.
I mentioned OpenID Connect (maybe someone else did too) but it was to say that
it has an https URL issuer style key resolution mechanism but that it's the
only mechanism there so doesn't encounter the same challenges we seem to be
facing here.
On Mon, Dec 9, 2024 at 1:01 PM Watson Ladd <watsonbl...@gmail.com> wrote:
As I remarked in the chatter on the meeting today, and at the mike
there's a bunch of complexity with issuers and resolution. Some of
this is practical issues of how a verifier knows which resolution
method to support, but there is some security content.
Let's say the iss field has the value "example.com", and Example
Issuance Inc is issuing credentials. This can be interpreted several
different ways
- As a DNSName to check in X509
- As a HTTPS URL to find issuer metadata
- Potentially some other system that could resolve to an issuer.
Now let's say a verfier is configured to trust credentials with iss
field "example.com". Is this correct and secure? No: it depends on the
resolution algorithm and crucially how the supported ones interact
with what the issuer does to protect the namespace.
- If a DNSName it's checked in a cert. It can also be a URL and get
checked, so it's very ambiguous.
- If as an HTTPS URL, but Example Issuance Inc. only really worries
about X509 because that's what they issue with, then we could have a
problem. Think of sites with subsites with vanity URLs for the class
of issue. I seem to recall there was an ACME challenge that ran into
this long ago.
- Some other system might let anyone claim "example.com". Issuers in
this other system are protected and secure as they registered their
names and maintain them, but not ones who don't know about it.
I hope this clarifies some of the issues that I've begun to think
about. I think we need to explicitly say what the roots of trust look
like: are they just values of the iss tag, or are they that plus some
additional configuration? I know someone mentioned OpenID had a
similar struggle: perhaps more can be said in reply.
Sincerely,
Watson
--
Astra mortemque praestare gradatim
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited. If you have
received this communication in error, please notify the sender immediately by
e-mail and delete the message and any file attachments from your computer.
Thank you.
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
