This is not the way I used PKI for user proofing. For convenience we added the Subject Alternative Name (SAN) which I guess is what you mean by a TLS certificate. This cert key was added to the TPM and used to sign JSON messages from the client to the server.
Please don't mix the attributes of the PKI for the actual purpose of the key and cert. Peace ..tom jones On Tue, Sep 17, 2024 at 1:01 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. > > 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 -- 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
