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? 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. 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
