Hi Mike,
Richard already made my comment for me that the current TLS validation
doesn't use the path. I want to focus on this comment of yours:
"it’s odd to *require* an X.509 certificate to secure them" (emphasis mine).

The point of this document is to provide a *choice*. You can continue to do
the thing relying parties do now by online validating with TLS, *OR* you
can validate offline using a certificate (because that makes sense in
several use cases, including the two mentioned in the draft).
Thanks,
-rohan

On Mon, Jun 10, 2024 at 12:14 PM Michael Jones <michael_b_jo...@hotmail.com>
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 <rifaat.s.i...@gmail.com>
> *Sent:* Monday, June 10, 2024 4:47 AM
> *To:* oauth <oauth@ietf.org>
> *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 -- 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

Reply via email to