Sorry to chime in late as well… I support adoption of this draft. I have read the thread and to me it seems like there is a mechanism being proposed that solved a concrete problem in a simple manner. Some of the discussion can happen after the draft is adopted. Best, Kristina
On Wed, Jun 26, 2024 at 7:49 AM Joseph Salowey <j...@salowey.net> wrote: > Sorry to chime in late here. I'm in favor of adopting this draft. While I > realize that X.509 isn't for everyone, there is an established community of > users out there that overlaps with OAUTH users. I think there are needs to > both separate the distribution of the keys from the establishment of trust > in those keys and in the auditability of the process of distribution. I > think this draft establishes a deployable mechanism based on existing > technology. X.509 is a good starting point and additional mechanisms can > be added as needed. > > Cheers, > > Joe > > On Tue, Jun 25, 2024 at 3:12 PM Watson Ladd <watsonbl...@gmail.com> wrote: > >> On Tue, Jun 25, 2024 at 2:56 PM Michael Jones >> <michael_b_jo...@hotmail.com> wrote: >> > >> > The other critique I voiced of the approach is that the >> application-level X.509 certificate can be used to secure the HOST part of >> the issuer, but not the entire issuer, since in general, the issuer will >> contain a PATH. Yes, the service hosting the issuers controls all the >> paths, as Richard replied earlier, but it’s not the service who is the >> attacker that this enables. The attackers that not securing the PATH >> enables are the tenants themselves. >> > >> > >> > >> > An attacker could host a tenant at the service and get an X.509 >> certificate securing the HOST part of its issuer. However, because a >> legitimate tenant at another path shares the same HOST, the attacker can >> copy its X.509 certificate chain and utilize a substitution attack to make >> unauthorized statements about the victim tenant – statements that were not >> made by the hosting service. >> > >> > >> > >> > This attack was not addressed, and I believe is intrinsic to the >> decision not to protect the entire issuer value. >> > >> > >> > >> > I believe that adopting this draft would result in this attack >> occurring in practice. >> >> To be clear, drafts get modified by the WG after adoption so adoption >> is not the same thing as WGLC. >> >> However, I'm not sure I understand your attack scenario. If we have a >> "tenant" distinguished by a path, there is already a security issue >> with giving it the X509 certificate. It could then imitate any other >> tenant on that server already. That's why we use reverse proxies and >> put the certificate only on the proxying machines. >> >> Sincerely, >> Watson >> >> >> >> -- >> Astra mortemque praestare gradatim >> >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-le...@ietf.org >> > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
