Hi Tom, This draft is not about user proofing. It's about authenticating the issuer of a JWT.
--Richard On Tue, Sep 17, 2024 at 7:57 PM Tom Jones <thomasclinganjo...@gmail.com> wrote: > 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
