Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

Peter Saint-Andre <stpeter@stpeter.im> Tue, 28 June 2022 16:45 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815C6C14F736 for <uta@ietfa.amsl.com>; Tue, 28 Jun 2022 09:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.985
X-Spam-Level:
X-Spam-Status: No, score=-3.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.876, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=o4wL0Mm2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sooK/w+p
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7nE3LDc0Snv for <uta@ietfa.amsl.com>; Tue, 28 Jun 2022 09:45:08 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F635C14F749 for <uta@ietf.org>; Tue, 28 Jun 2022 09:45:07 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 9734D3200976; Tue, 28 Jun 2022 12:45:06 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 28 Jun 2022 12:45:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1656434706; x= 1656521106; bh=gEEam1K4HntDGaSe5MZfirHzeRB7QF4ffW2ry/poBcs=; b=o 4wL0Mm2BUdWd4/y3v4k0XlZZsw9Bs7Jx13o0p4K4U4bsDDDbJY9l9MLwlND6xxdp lb2OCtb4rgrxfbcdTBoEqaxk4675H8oS/NnvO9Vnjo4MShw8JRdjCuIpXsv1DkVE FqsxIxOCj9BvIDGZDEfgzZelO3AttQ1y88cGLaj1QBmecp3oIUvlq5fSnd/ejiuA k1sigOlCbrdfaREdo2bnuryYEesea40TFbEZ8x6uEJwS6Vw0UjsFL/2CZ1OZUgp4 I/GlHts+CTMCKfX91+YKzDQ7RkkS0fGFVTfjb26gqcOzsohRb74PiIbvtVRNtI1T FzoxXGD1mKpRzB+fDDSgA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1656434706; x=1656521106; bh=g EEam1K4HntDGaSe5MZfirHzeRB7QF4ffW2ry/poBcs=; b=sooK/w+pgSUfkKuIJ 85vlN3KpVFkhvmOQQQQkuz9Yj1TGZkfxQXo//NGDQ5Crr9Y76Q6wPGSZJU402HsO dxk9gGWnjrE69AFjLpgdlwL5Fyd5dUAWIggRf/g+tI8Hp452RzmUluz+zKIDyswd IZgskStzaKJ7pgvnJC1jpaWOXpDrdMT7rYH7OAWGw6neeP1f2a8x2h/N4LXBcx9h jw8B0CHeeQ7voswKMIbjC81PtEA9Ki+QfQhcJYxhdJbXcp/5dS2K11gMBy3qo2PF uz+VduvccGaOpwFg9uLvbeGnF6dV+Lg2CGOcY0Ky2W+gMnV5AAlqBNzgN5KUYdgs feA7g==
X-ME-Sender: <xms:ETC7Yvl8P6TFmYMCso22-95i_s1DdGbQYlCoU0W1Z4CVEDhg2BzNcQ> <xme:ETC7Yi0I0mR6ujRke0CaZ_u8-joffWONuZB6a3IAx8a7m0wsgJ8oM6DehNJrlV1iw wD6-ntx1tEsjjJfOQ>
X-ME-Received: <xmr:ETC7YlpBoic_ypWr7wqFJNzRtIdkTH_KoOpYQtW0gAqKFBOdeSPpCRgI0VEW>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudegjedguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfhffvfhfujggtgfesth ekredttdefjeenucfhrhhomheprfgvthgvrhcuufgrihhnthdqtehnughrvgcuoehsthhp vghtvghrsehsthhpvghtvghrrdhimheqnecuggftrfgrthhtvghrnhepleeufeekkeeftd fhvdehhfelgfekudekveevffelffegveefleetuedtvdehvdelnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtphgvthgvrhesshhtphgvth gvrhdrihhm
X-ME-Proxy: <xmx:ETC7YnkbqDYKATJLLEsiTzidvSMw5SveGWNH3rLwE-JHn0gq47K31g> <xmx:ETC7Yt0sEswnCE6YP2C_1tiSCmtb62rcpreEK5b9FjuFs-liO-qemA> <xmx:ETC7YmtErroGXOMvSdpNuqm3oi4bNZW5MENfmIFVvO78nnO6XevLKQ> <xmx:EjC7Yu-8j6-jkUDkkUwHAHfjhyGYWRqMr3IsjrZQgf36SsCgLSq5MA>
Feedback-ID: i24394279:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 28 Jun 2022 12:45:05 -0400 (EDT)
Message-ID: <4e89b9f3-dc73-ca8d-8517-a569b676136c@stpeter.im>
Date: Tue, 28 Jun 2022 10:45:04 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
From: Peter Saint-Andre <stpeter@stpeter.im>
To: uta@ietf.org, Viktor Dukhovni <ietf-dane@dukhovni.org>
References: <002e01d87e9c$78a002e0$69e008a0$@smyslov.net> <032e01d8878f$c2e8f630$48bae290$@smyslov.net> <A7E6035E-7BCF-4BB3-BB87-D261ED98532D@gmail.com> <YrdXuGgMKMM+gKJn@straasha.imrryr.org> <DF17FC56-87DB-4002-B84F-A81B3AE99F83@gmail.com> <Yrdzc0bkQGMRXVGM@straasha.imrryr.org> <fb09d07d-57c3-aba3-f367-dc25a348a4cd@stpeter.im> <Yrou2Rx71cRq+5jT@straasha.imrryr.org> <d1b5f7f8-6f4f-9860-b284-89544ad036d9@stpeter.im>
In-Reply-To: <d1b5f7f8-6f4f-9860-b284-89544ad036d9@stpeter.im>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/QO2f3JyxmfP6iLGdgLQoIqWY9IU>
Subject: Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jun 2022 16:45:12 -0000

On 6/27/22 4:33 PM, Peter Saint-Andre wrote:
> On 6/27/22 4:27 PM, Viktor Dukhovni wrote:
>> On Mon, Jun 27, 2022 at 02:37:22PM -0600, Peter Saint-Andre wrote:
>>
>>>> It does for the majority of the certificate usages, but in practice
>>>> today DANE is primarily used with SMTP, and predominantly with
>>>> DANE-EE(3) TLSA records, in which case identity questions are settleda
>>>> at the DNS layer, and the presented identifiers in the certificate are
>>>> irrelevant.
>>>
>>> Even in this case, doesn't the certificate include a service identifier?
>>
>> Actually, no.  A handful of DANE SMTP server operators configure
>> certificates that have empty Subject and Issuer DNs and no Subject
>> Alternative names.  The certificate is (kind-of) self-signed and
>> essentially holds just the public key and its self-signature.
> 
> Excellent. Thanks for the clarification. Thus in the case of DANE-EE 
> certs it truly is the case that, as you said in a previous message, the 
> equivalent of the presented identifier is derived purely from DNS.
> 
> Peter

Given these considerations, I propose that we add something like the 
following text to the section on what's in scope for this document 
(copied from the markdown source, thus the curly braces):

###

With regard to PKIX certificates, the primary usage is in the
context of the public key infrastructure described in {{5280}}.
In addition, technologies such as DNS-Based Authentication
of Named Entities (DANE) {{RFC6698}} sometimes use certificates based
on PKIX (more precisely, certificates structured via {{X.509}} or
specific encodings thereof such as {{X.690}}), at least in certain
modes.  Alternatively, a TLS peer could issue delegated credentials
that are based on a CA-issued certificate, as in {{TLS-SUBCERTS}}.
In both of these cases, a TLS client could learn of a service identity
through its inclusion in the relevant certificate.  The rules specified
here are intended to apply whenever service identities are included in
X.509 certificates or credentials that are derived from such certificates.

###

Let me know what you think.

Peter