Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
Ryan Sleevi <ryan-ietf@sleevi.com> Sat, 18 January 2020 15:14 UTC
Return-Path: <ryan.sleevi@gmail.com>
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 94238120013; Sat, 18 Jan 2020 07:14:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 jpgCeFFtphgM; Sat, 18 Jan 2020 07:14:55 -0800 (PST)
Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07AEC120019; Sat, 18 Jan 2020 07:14:55 -0800 (PST)
Received: by mail-ed1-f53.google.com with SMTP id m8so25172414edi.13; Sat, 18 Jan 2020 07:14:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e4fTcdOAXwB9Tce3qS3zmGZC/QQgWRTLSPy/InbfQXA=; b=KSOM+QTq3RbLP7QgJlEvfkLzFs9GVFmfxLdtzY/6hCuF3rBnrkc5YfFxfIkO3+Cmlq gUK+TUmvd/+rZtqdzEQRfntoDhDLRaokZrpHIL0vzWp4UqL9uwT45PQJIgNdD41swxLc 7xxrqtJ+vPn2Ky9vROsR0yuvuRi8L3ou+9p12d5wlNiEZBQy1LejcH1aaiY87Efkk2Ps PR4eEVYKzksAFDYugOoSqVk3TkZamwjGjdQNiZyj3DqG4l58l30zZgyHom3yjpc7Ok9F pIgRLocn6DDyZZf44Y/FOozOgjujLIanMs2aLMEezaYUYq1J06v66jUTgYQLWzBKExPH AtJQ==
X-Gm-Message-State: APjAAAX7lU/wJKQuSdteFTp1K7hHZlY1C1/WMF1tBJUf3GtGDg8jAfkv 3lM5Zn+IOMPb4rKP/+ITlaFEmdVP
X-Google-Smtp-Source: APXvYqxuBWOzi6ntdKoEzRDFEHRou2qQbRISQK9mK2SwJpuPWyAGKf9I9doxxT5lvwju4JLi+Z2GZg==
X-Received: by 2002:a17:907:11cc:: with SMTP id va12mr12637224ejb.164.1579360493281; Sat, 18 Jan 2020 07:14:53 -0800 (PST)
Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com. [209.85.221.52]) by smtp.gmail.com with ESMTPSA id s16sm1155039edy.51.2020.01.18.07.14.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Jan 2020 07:14:52 -0800 (PST)
Received: by mail-wr1-f52.google.com with SMTP id q6so25283471wro.9; Sat, 18 Jan 2020 07:14:52 -0800 (PST)
X-Received: by 2002:adf:ff8a:: with SMTP id j10mr8756630wrr.312.1579360492336; Sat, 18 Jan 2020 07:14:52 -0800 (PST)
MIME-Version: 1.0
References: <B2989B0E-8B6B-4B7A-B871-AF520310B3FC@deployingradius.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> <3f964440-37d4-a08e-3d86-10ea712e99ca@cs.tcd.ie>
In-Reply-To: <3f964440-37d4-a08e-3d86-10ea712e99ca@cs.tcd.ie>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Sat, 18 Jan 2020 10:14:41 -0500
X-Gmail-Original-Message-ID: <CAErg=HH15iqUnJxQPCSadx04r33DvLYwiaC7C2Cv4cX0tKvpyQ@mail.gmail.com>
Message-ID: <CAErg=HH15iqUnJxQPCSadx04r33DvLYwiaC7C2Cv4cX0tKvpyQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Alan DeKok <aland@deployingradius.com>, Benjamin Kaduk <kaduk@mit.edu>, EMU WG <emu@ietf.org>, Joseph Salowey <joe@salowey.net>, Michael Richardson <mcr+ietf@sandelman.ca>, "Owen Friel (ofriel)" <ofriel@cisco.com>, Ryan Sleevi <ryan-ietf@sleevi.com>, "spasm@ietf.org" <spasm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001e3cbb059c6b85ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/H-5bQBO6dVbuPF6CD_N1syJxdZ4>
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 15:14:57 -0000
On Sat, Jan 18, 2020 at 9:22 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > Hiya, > > On 18/01/2020 13:55, Ryan Sleevi 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. > > I have to say that comes across as fairly arrogant. I guess > that's by the by, but it makes me happy that I don't need > to play in the CAB forum space:-) [I'm sure it wasn't meant > to be arrogant, and it has been a long thread which can > lead to irritability, but that's how it struck me.] It certainly was not meant that way. It is the essence of “rough consensus and running code”. Standards that describe idealized states, that don’t reflect reality, are standards that aren’t valuable. Similarly, when we talk standards that do things like deprecate insecure crypto or older protocol versions, we know there isn’t an IETF Enforcement Bureau that makes sure all of the “-diediedie” drafts are observed and implemented In a timely fashion. That’s what makes jokes like RFC 6919 so endearing and funny, because we know that it better reflects our unfortunate realities than 2119. I've no real axe to grind here (definitely not wrt EAP), > but, as a private key holder I do use web PKI CAs for > email servers as well as for web servers. Turning that > off would disimprove security for the Internet without > (IMO) any real justification as to it producing a real > improvement in the web PKI. (I do control the domains.) > I don't buy that mentions of diginotar or equivalent > misissuance problems are really relevant myself. They are relevant in that they require they all be treated the same, for legal, policy, and other non-technical reasons, even when it’s understandably undesirable. I don’t disagree that there’s ample need for robust TLS issuance, and I agree that there’s ample ill-definition about what “WWW authentication” means and contains. Some CPSes are more explicit, some less, about what they allow. Supposedly, every time you’re getting a cert, you’re carefully reviewing all of these agreements as part of your selection of which CA to use ;) That, and I've always considered CP/CPS as legal window > dressing, initially for the benefit of CAs but judging > from the above, now apparently mostly for the benefit of > web PKI root store maintainers (aka browsers). I mean, this is why RFC 3647 exists. It exists for CAs to shift liability to Relying Parties (“We told you we do this stupid thing, right here”), and for Root Stores to shift liability to CAs (“You told us you would do this, right here”). CAs like to use it to further try to defend against any risk of distrust (“We told you we would do a stupid thing, and you trusted us anyway, so you can’t distrust us for doing a stupid thing”) There are CPSes that don’t include problematic clauses regarding EKUs, for sure, or which explicitly state how it’s interpreted in their PKI. That particular example is not meant to be a “universal example” of something forbidden, but to highlight how even if one relying party would like to ignore the CPS, when there are multiple constituencies, that doesn’t work. The only way you sort through those is to make sure the only two parties are you and the CA - aka defining a root store.
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Owen Friel (ofriel)
- [Emu] EAP/EMU recommendations for client cert val… Owen Friel (ofriel)
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] EAP/EMU recommendations for client cert… Michael Richardson
- Re: [Emu] EAP/EMU recommendations for client cert… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Eliot Lear (elear)
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Eliot Lear (elear)
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Michael Richardson
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Joseph Salowey
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Benjamin Kaduk
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Eliot Lear (elear)
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Mohit Sethi M
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Michael Richardson
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Michael Richardson
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Owen Friel (ofriel)
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… David B. Nelson
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Stephen Farrell
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Stephen Farrell
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Salz, Rich
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Russ Housley
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Peter Bowen
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… David B. Nelson
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Michael Richardson
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… David B. Nelson
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Alan DeKok
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Ryan Sleevi
- Re: [Emu] [lamps] EAP/EMU recommendations for cli… Phillip Hallam-Baker