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

[Richard Barnes <[e-mail]>]

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 <[e-mail]>
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 <
> [e-mail]> 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>