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

[Vladimir Dzhuvinov <[e-mail]>]

I frankly don't see how the central premise of PIKA - the reliance on a 
TLS web domain certificate - can be made to work in practice.


Reasons: Infrastructure in the real world, mixing of concerns, conflict 
with CA policies and CAB Forum requirements, NIST etc guidance 
compliance issues.


The argument - JWKs are already published at an HTTPS URL - so let's 
take the private key from the web reverse proxy (assuming there is no 
HSM) and start signing JWTs at some application with it - how I would be 
able to make this argument at some company X.

When we look at how infrastructure is setup and administered - even if 
we here in the OAuth WG decide to say "using the private TLS key for 
other purposes is entirely okay" - there are significant practical 
issues with this. It's not just a matter of being theoretically able to 
cross from the app layer into the TLS layer. These two layers are 
typically managed by different departments in orgs, and there are good 
reasons to isolate them. I can't imagine being able to go to the admins 
and say, make me a copy of the private key so I can sign JWTs with it, 
or let me install this service on your infra to sign my JWTs.

Let's also think about the potential legal and compliance issues.

CAs that issue certs that prove web domain control have policies. These 
policies are linked to the EKU values in the certs. Using the cert to 
sign stuff other than that expressly identified in the CA policy and the 
extKeyUsage fields can be seen as breaking those policies.

https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf

> 3.6 Installation and Use of Your Certificate
> The purpose of Your Certificate is to authenticate and encrypt 
> Internet communications.

I'd also suggest to go and check whether the CA / Browser Forum, in its 
"Baseline Requirements for the Issuance and
Management of Publicly‐Trusted TLS Server Certificates" does not 
stipulate an overarching policy for CAs that generally prohibits issue 
of TLS certs with additional EKU values.

Orgs that seek compliance with NIST and similar guidance are likely to 
see issue with this approach too. Documents like NIST Special 
Publication 800-57 / Recommendation for Key Management.

I'm not in favour of adopting this spec as it is in the WG. Let's 
consider the practical situation apart from what seems technically possible.

I made a diff between drafts 01 & 02 and noticed that in 02 the policy 
issues of using CA TLS certs for PIKA were probably recognised to some 
degree, in the "5.2. Signing Key Compromise" section.

https://author-tools.ietf.org/iddiff?url1=draft-barnes-oauth-pika-00&url2=draft-barnes-oauth-pika-01&difftype=--html

Apart from the "5.2. Signing Key Compromise" section, draft 02 that is 
now proposed for adoption is identical to the original 01 that wasn't 
adopted in June. It's okay to explain the intent to resubmit without 
changes, just as it's okay to disagree on a particular adoption. I get 
it that the topic of PIKA feels contentious.


Vladimir Dzhuvinov

On 03/09/2024 13:47, Rifaat Shekh-Yusef wrote:
> 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 [e-mail]