[OAUTH-WG] Re: Call for adoption - PIKA

[Richard Barnes <[e-mail]>]

Hi Mike,

The intent here is to follow exactly the same security model as current
HTTPS-based OP key discovery mechanisms, e.g., OpenID Connect Discovery.
With those mechanisms:

1. The only way the issuer is authenticated is via a certificate presented
in HTTPS.
2. The only aspect of the URL that is authenticated is the domain name.  In
multi-tenant environments, whoever owns the domain name can speak for any
tenants.

Changing the first property would make this document non-interoperable,
since it is no longer clear how the relying party is supposed to verify the
PIKA signature.  Changing the second property would require inventing some
new PKI-ish thing that can authenticate more of a URL.

Do you have some specific additional mechanism that you think needs to be
accommodated here?  If not, I would propose we follow the YAGNI principle,
be specific, and if we need to extend later, we can do a follow-on spec.
Otherwise it's just abstraction for abstraction's sake.

Cheers,
--Richard

On Mon, Jun 10, 2024 at 12:14 PM Michael Jones <[e-mail]>
wrote:

> While I’m generally supportive of the goals of this draft, I have issues
> with the mechanisms proposed.  Therefore, I believe that more working group
> discussion is needed before adoption.
>
>
>
> If I were to do something along these lines, I would not use “x5c”.  Other
> than for TLS certificates, the OAuth and JOSE specs generally steer clear
> of dependence upon X.509 certificates.  Especially for a spec focused on
> JWK Sets, it’s odd to require an X.509 certificate to secure them.
> Instead, I’d do so by validating the signature made by the issuer.
>
>
>
> Also, the spec says:
>
>    *  The JOSE Header of the PIKA MUST contain an x5c field.  The
>
>       contents of this field MUST represent a certificate chain that
>
>       authenticates the domain name in the iss field.  The domain name
>
>       MUST appear as a dNSName entry in the subjectAltName extension of
>
>       the end-entity certificate.
>
>
>
> This talks about the domain name of the issuer, but not the path within
> the issuer.  In multi-tenant systems, issuers typically include path
> components.  When the issuer is https://example.com/tenant/123, what
> would the DNSName entry be?  The spec doesn’t say.
>
>
>
> Conclusion: Not ready for adoption
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Rifaat Shekh-Yusef <[e-mail]>
> *Sent:* Monday, June 10, 2024 4:47 AM
> *To:* oauth <[e-mail]>
> *Subject:* [OAUTH-WG] Call for adoption - PIKA
>
>
>
> All,
>
> This is an official call for adoption for the *Proof of Issuer Key
> Authority (PIKA)* draft:
>
> https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/
>
>
> Please, reply *on the mailing list* and let us know if you are in favor
> or against adopting this draft as WG document, by *June 24th*.
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>