I strongly support this draft and would have immediate uses for PIKA if standardized.
As someone who builds OIDC relying party software I am not worried about the X.509 certificate requirement, nor do I consider dependence on X.509s or the Web PKI to be an onerous requirement. I already have to deal with parsing and creating X.509 certificates in my relying party software. Given that JWK Set URI's use the Web PKI to authenticate the JWKs they serve via HTTPS, it only seems natural we would use that very same system, the Web PKI, to authenticate JWKs directly. Thanks, Ethan On Tue, Jun 25, 2024 at 8:46 PM Kristina Yasuda <yasudakrist...@gmail.com> wrote: > > 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 _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
