MIME-Version: 1.0
References: 
 <CADNypP80YnzxOc_NDbFqK0bv=i0Ys1s8hYHwo-PqhUPbAWs4sg@mail.gmail.com>
 <ff6a0d93-af5d-479f-9ae7-14815364a73e@connect2id.com>
 <2C5BE4BF-9834-49D4-8E14-19DE69AA97F7@alkaline-solutions.com>
In-Reply-To: <2C5BE4BF-9834-49D4-8E14-19DE69AA97F7@alkaline-solutions.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 18 Sep 2024 10:31:32 -0400
Message-ID: 
 <CAL02cgS4Rx=gN_K88RLucB7bgnxZuikfcf8GvOJOUf6dbjS9GA@mail.gmail.com>
To: David Waite <david=40alkaline-solutions.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000417f14062265aaa5"
Message-ID-Hash: TZ7BVSXRM63SL34UD6FQWTH7MSTCCXNE
CC: oauth@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_Call_for_adoption_-_PIKA?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/oauth/KustkKGtMsFjTaX-HplvQt003_Y>

--000000000000417f14062265aaa5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM David Waite <david=3D
40alkaline-solutions.com@dmarc.ietf.org> wrote:

>
>
> On Sep 17, 2024, at 1:58=E2=80=AFPM, Vladimir Dzhuvinov <vladimir@connect=
2id.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-leave@ietf.org
>

--000000000000417f14062265aaa5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi David and Vladimir,</div><div><br></div><div>We di=
scussed this in the WG session in Vancouver.=C2=A0 The aim here is certainl=
y not to just take the certificate on the web server and re-use it.=C2=A0 R=
ather, we are re-using the underlying PKI.=C2=A0 As I said in YVR and in my=
 response to Mike just now, we should have separation between web server ce=
rtificates and PIKA-signing certificates.=C2=A0 My view is that a prefix is=
 sufficient (&quot;_<a href=3D"http://pika.example.com">pika.example.com</a=
>&quot;).=C2=A0 We could discuss things like EKUs, but those will be harder=
 to deploy.<br></div><div><br></div><div>In any case, there are solutions h=
ere, so I would propose we adopt the document and then discuss which soluti=
on is best.</div><div><br></div><div>--Richard<br></div><div><br></div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On T=
ue, Sep 17, 2024 at 6:29=E2=80=AFPM David Waite &lt;david=3D<a href=3D"mail=
to:40alkaline-solutions.com@dmarc.ietf.org">40alkaline-solutions.com@dmarc.=
ietf.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div><br id=3D"m_3661257079507587621lineBreakAtBeginningOfMessage">=
<div><br><blockquote type=3D"cite"><div>On Sep 17, 2024, at 1:58=E2=80=AFPM=
, Vladimir Dzhuvinov &lt;<a href=3D"mailto:vladimir@connect2id.com" target=
=3D"_blank">vladimir@connect2id.com</a>&gt; wrote:</div><br><div>

 =20
   =20
 =20
  <div><p>I frankly don&#39;t see how the central premise of PIKA - the
      reliance on a TLS web domain certificate - can be made to work in
      practice.</p><p><br>
    </p><p>Reasons: Infrastructure in the real world, mixing of concerns,
      conflict with CA policies and CAB Forum requirements, NIST etc
      guidance compliance issues.<br></p></div></div></blockquote>I agree w=
ith Vladimir unfortunately.</div><div><br></div><div>A certificate is a bun=
dle of restrictions, but the two most critical are on subject name and purp=
ose. This reuses a certificate meant to secure network traffic with a parti=
cular DNS name to one securing arbitrary application messages from a partic=
ular origin.</div><div><br></div><div>This would not only break a lot of or=
ganizational security policies (and potentially conflict with how they depl=
oy their network infrastructure), but ignores CA policy that is baked into =
the TLS certificate.</div><div><br></div><div>-DW</div></div>______________=
_________________________________<br>
OAuth mailing list -- <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">o=
auth@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:oauth-leave@ietf.org" tar=
get=3D"_blank">oauth-leave@ietf.org</a><br>
</blockquote></div>

--000000000000417f14062265aaa5--