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 CertificateThe 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=--htmlApart 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 --oauth@ietf.org To unsubscribe send an email tooauth-le...@ietf.org
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
