Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

"David B. Nelson" <d.b.nelson@comcast.net> Sat, 18 January 2020 14:15 UTC

Return-Path: <d.b.nelson@comcast.net>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB10120013 for <emu@ietfa.amsl.com>; Sat, 18 Jan 2020 06:15:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5gY4Xnf-wLI for <emu@ietfa.amsl.com>; Sat, 18 Jan 2020 06:15:03 -0800 (PST)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BCA120020 for <emu@ietf.org>; Sat, 18 Jan 2020 06:15:03 -0800 (PST)
Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id soN7ispvOqc4dsosQiyhRD; Sat, 18 Jan 2020 14:15:02 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1579356902; bh=B16BW/KtBo4gbjmFiT2o0upefNfQfyrsuCfrLrkAOyw=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=H3XEtJKxTEq4EohH2jSqQsGuVq7clnRxgBNqMSgLpQx7JwQSXZQ0GDro/vzGwIH+9 uQJioiPFmnI+v9/qnG+O+nxjV18o55/KuWx228w9QY/tzpEj2sq/8/ZVLg3zFaTeoE VlZPDDONNdxi7IgWVfM1Py82ebNIeSkSbxrK6jHsBM4o6+opAONpp3hiSFAcz9uL6S hzhz8gCRpqOARJ/uIPJ/fovPxPh9YFX+qVImPP0d7sjnN3zrJn3tJGlC6mYl1vfWa4 4jTkDl0ZwFYVAqyGZe0XePUfbFjqTuODLCtbw6xjebLgEmc9+WEKFSvsObOHaIL7Kg BHV4wsxvwkHyA==
Received: from [IPv6:2601:187:4000:6316:2175:831:bb6d:d76c] ([IPv6:2601:187:4000:6316:2175:831:bb6d:d76c]) by resomta-ch2-16v.sys.comcast.net with ESMTPSA id sosOix6kV3TL0sosPic2W8; Sat, 18 Jan 2020 14:15:02 +0000
X-Xfinity-VMeta: sc=-100.00;st=legit
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "David B. Nelson" <d.b.nelson@comcast.net>
In-Reply-To: <CAErg=HH8LjqMR37Ek1uK12uCDj4N89Ot=Fm_PLOBdeXsv3sdpw@mail.gmail.com>
Date: Sat, 18 Jan 2020 09:15:00 -0500
Cc: Alan DeKok <aland@deployingradius.com>, EMU WG <emu@ietf.org>, "spasm@ietf.org" <spasm@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B9DF061-36C5-426B-8403-91972B40A05E@comcast.net>
References: <B2989B0E-8B6B-4B7A-B871-AF520310B3FC@deployingradius.com> <CAErg=HG06ZpiRUYogiVwoJPsZDsjzAVvO0B4=K=PE7aAHe44rA@mail.gmail.com> <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <CAErg=HFPCYKgUEXHaOC0sQECYaVmt0TZXe-uDrKzFiNSAcdckg@mail.gmail.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <CAErg=HFYQpfqTE9==TzGo795ZiuNBGVMqWuXS6GJ2DV0nGxPzA@mail.gmail.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <CB67C090-4D6A-4586-AD7C-99A29EF5D92D@deployingradius.com> <CAOgPGoDADPY125Bf7mbPCpEVkwVF=YmbG9wAN0S-WyCWg27BCw@mail.gmail.com> <20200116040715.GC80030@kduck.mit.edu> <CAErg=HHwLOw9sL2=nGca5MuuyiV2Zghrp6prR7SqLJAvfCLmjA@mail.gmail.com> <B3A03277-C176-4E63-ADB3-70133E2ABA46@deployingradius.com> <MN2PR11MB3901D1B17802F2DACCC8966CDB300@MN2PR11MB3901.namprd11.prod.outlook.com> <CAErg=HE0XDbhuibtky5VhvZYUnQxDitLSEuf4uzXnuByNQN+4Q@mail.gmail.com> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <CAErg=HH8LjqMR37Ek1uK12uCDj4N89Ot=Fm_PLOBdeXsv3sdpw@mail.gmail.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/3P_FquVZ1uGjie9CLqR2evKYRFc>
Subject: Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jan 2020 14:15:06 -0000

On Jan 18, 2020, at 8:55 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> 
> No. The root store operators make the rules. Standards that align with their needs are the standards they use and apply.
> 
> Nothing you say or do has any impact without implementor, and if you go against the grain of where implementors are going or already at, they are useless standards that will be ignored.
> 
> It would similarly be a mistake to think “Ah, but I control an SMTP server, I am thus an implementor and empowered”. You are indeed an implementor... for your root store. And if existing contracts and requirements prevent a CA from serving your needs from the same hierarchy they are serving other root store needs, which they increasingly will, then again, there’s no real power unless you define your own root store.
> 
> When a vendor, be it Apple or Microsoft or Mozilla or Google, says a CA in their root store needs to do something, they need to do it. If you don’t like that, which the email clearly demonstrates, there isn’t a heckler’s veto via the IETF: you instead need to create your own root store to do the things you want or like. Attempting to change those policies via the IETF, without understanding why they exist, just leads to IETF standards being ignored because they are not useful nor aligned with the needs of consumers.
> 
> Put differently: This is as explicitly an area of policy, not technology. As tempting as it may seem to focus on individual problems and say “Ah, but those could be addressed by technology and more standards,” without appreciating the broader and big picture, which is inherently policy, the work on the technology is doomed.

I don’t “have a dog in this fight”, being retired for several years now.  However, I’ve been following this thread out of interest.  I’ve long held that the problems with deployment and interoperability of PKI are in the business domain, not the technical domain.  It’s interesting, and perhaps a bit disappointing, to see that it still the case.  And now, back to your regular programming…

Regards,

Dave Nelson