On Tue, Sep 17, 2024 at 1:02 PM Vladimir Dzhuvinov <vladi...@connect2id.com> wrote: > > 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.
Like it or not the Web PKI is the only system to prove domain control via cryptographic means that exists. You can of course get another cert for use for only this purpose: signing with the web servers cert is not required in the current draft. > > 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. We've resolved this issue with Delegated Credentials, there's no reason to think we can't do the same here. It really isn't a problem. > > 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. Mozilla's CA policy specifically envisions the potential use of a root certificate to sign intermediates that don't have the ServerAuth EKU but could have a different one for this. > > 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 -- Astra mortemque praestare gradatim _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
