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.