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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 27 June 2022 18:13 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 AECAFC15AAF9 for <uta@ietfa.amsl.com>; Mon, 27 Jun 2022 11:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 W4O4Gp7UsbEj for <uta@ietfa.amsl.com>; Mon, 27 Jun 2022 11:13:01 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 DDF3CC157B3A for <uta@ietf.org>; Mon, 27 Jun 2022 11:13:01 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id BC5B01001C1; Mon, 27 Jun 2022 14:12:58 -0400 (EDT)
Date: Mon, 27 Jun 2022 14:12:58 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org
Message-ID: <YrnzKrWGvlwWsEZl@straasha.imrryr.org>
Reply-To: uta@ietf.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> <F3CB3696-F3D1-48DE-9A90-2620B2CB8DBA@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F3CB3696-F3D1-48DE-9A90-2620B2CB8DBA@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/offAW43eRWEKDrGyJmUDQTI2UDw>
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: Mon, 27 Jun 2022 18:13:02 -0000

On Mon, Jun 27, 2022 at 05:15:09PM +0000, Salz, Rich wrote:

> Does a DANE certificate have the same "name" as a non-DANE
> certificate?

Yes, the name is a DNS name, and for DANE certificate usages PKIX-TA(0),
PKIX-EE(1) and DANE-TA(2) the same logic applies to the EE certificate
as in PKIX with WebPKI trust anchors.

> If the subjectAltNAME for a DANE-based certificate is the same as for
> non-DANE, then yes the rules should apply. If not, no.

Modulo cases (e.g. SMTP) where with DANE-EE(3) the presented identifiers
in the peer certificate may be entirely ignored.

> Note that "validating the chain" is *not* part of 6125 nor 6125bis.
> Quoting from the Applicability section: This document addresses only
> name forms in the leaf "end entity" server certificate.   It does not
> address the name forms in the chain of certificates used to validate a
> cetrificate, let alone creating or checking the validity of such a
> chain.  In order to ensure proper authentication, applications need to
> verify the entire certification path as per {{PKIX}}.
>
> Perhaps the last few words could or should be
> 	Such as per {{PKIX}} or {{DANE}}.

Sure, but I don't know that this needs to be stated explicitly,
applications that elect DANE are well aware that they're in part or in
whole deviating from PKIX.  But if there's a concern that this text in
essence "forbids" DANE, the text could simply delete "as Per {{PKIX}}".
There may other certificate chain verification modes in the future.

-- 
    Viktor.