Hi David and Vladimir,
We discussed this in the WG session in Vancouver. The aim here is
certainly not to just take the certificate on the web server and re-use
it. Rather, we are re-using the underlying PKI. As I said in YVR and in
my response to Mike just now, we should have separation between web server
certificates and PIKA-signing certificates. My view is that a prefix is
sufficient ("_pika.example.com"). We could discuss things like EKUs, but
those will be harder to deploy.
In any case, there are solutions here, so I would propose we adopt the
document and then discuss which solution is best.
--Richard
On Tue, Sep 17, 2024 at 6:29 PM David Waite <david=
40alkaline-solutions....@dmarc.ietf.org> wrote:
>
>
> On Sep 17, 2024, at 1:58 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.
>
> I agree with Vladimir unfortunately.
>
> A certificate is a bundle of restrictions, but the two most critical are
> on subject name and purpose. This reuses a certificate meant to secure
> network traffic with a particular DNS name to one securing arbitrary
> application messages from a particular origin.
>
> This would not only break a lot of organizational security policies (and
> potentially conflict with how they deploy their network infrastructure),
> but ignores CA policy that is baked into the TLS certificate.
>
> -DW
> _______________________________________________
> 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
