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

[Tom Jones <[e-mail]>]

I really do not understand most of Mike's objections.
If key reuse were such a problem then TLS keys should be used for nothing
but TLS. He didn't complain about that.
The original use of PKI was application level protection. TLS came later.
I am no fan of X.509. It is ubiquitous right now.
Peace ..tom jones


On Mon, Sep 16, 2024 at 12:56 PM Michael Jones <[e-mail]>
wrote:

> I regret to have to report that the issues that I believe resulted in the
> first call for adoption failing, despite being discussed on-list and at
> IETF 120, have not been addressed in the specification
> <https://www.ietf.org/archive/id/draft-barnes-oauth-pika-01.html>.  I did
> have a productive conversation with Richard in Vancouver, which resulting
> in him mentioning some of the problems in his presentation
> <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>.
> Here are the problems that have not been addressed since the first call for
> adoption:
>
>
>
>    1. *Application-level use of PKI trust chains.*  As I wrote in my
>    response to the first call for adoption
>    <https://mailarchive.ietf.org/arch/msg/oauth/rPPI9E8fwN1NiMM1TkaQUfFYEDI/>,
>    “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.”  This problem is acknowledged in Issue 1 of Slide 7 of Richard’s
>    presentation
>    <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>.
>    As I also wrote
>    <https://mailarchive.ietf.org/arch/msg/oauth/zvIsbxHTFC4YXozOgOfQutR6GN8/>,
>    “application-level X.509 … is an anachronism that OAuth and JOSE have
>    moved away from”.
>    2. *Reuse of keys intended for one purpose for a different purpose.*
>    PIKA uses WebPKI keys for signing things that are not Web resources.  Key
>    reuse is not a good security practice.  This problem is acknowledged in
>    Issue 2 of Slide 7 of Richard’s presentation
>    <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>
>    .
>    3. *Authorities with paths not secured.*  In OAuth, authorities such
>    as issuers can have a path component in their URL.  But the spec says “The
>    contents of this field *MUST* represent a certificate chain that
>    authenticates the domain name in the iss field” – meaning that the path
>    component of the issuer is not secured.
>    4. *Odd hybrid of JWKs and X.509.*  The spec uses both JSON Web Keys
>    and X.509 certificates in the trust evaluation, which is an odd intermixing
>    of technologies with overlapping purposes.  Architecturally, it would be
>    cleaner to go all in on one or the other.  This is evident in Slide 5 of Richard’s
>    presentation
>    <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>
>    .
>    5. *Upgrade path not defined.*  As Slide 7 of Richard’s presentation
>    <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>
>    says, “Need to make sure that systems using PIKA have a clear
>    upgrade/interop path to alternatives to application-level certificates
>    (e.g., OpenID Federation)”.  This is a point that I know John Bradley made
>    to Richard in person in Vancouver.  This problem is not addressed in the
>    specification.
>
>
>
> I’m also personally uncomfortable with the *direction of travel* embraced
> by this specification.  For over a decade, we’ve been consciously working
> to move OAuth away from X.509 and towards JOSE and this specification goes
> in the opposite direction.
>
>
>
> As documented above, these problems were discussed and acknowledged.
> Therefore, it’s disappointing to me that the updated draft didn’t address
> these previously identified issues.
>
>
>
> Therefore, I believe this specification should not be adopted, as the
> problems that caused it to not be previously adopted have not been
> addressed.
>
>
>
>                                                                 Sincerely,
>
>                                                                 -- Mike
>
>
>
> *From:* Rifaat Shekh-Yusef <[e-mail]>
> *Sent:* Tuesday, September 3, 2024 3:47 AM
> *To:* oauth <[e-mail]>
> *Subject:* [OAUTH-WG] Call for adoption - PIKA
>
>
>
> All,
>
> As per the discussion in Vancouver, this is a 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 *Sep 17th*.
>
> Regards,
>  Rifaat & Hannes
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>