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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 25 June 2022 18:45 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 A40A3C157B32 for <uta@ietfa.amsl.com>; Sat, 25 Jun 2022 11:45:18 -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_ZEN_BLOCKED_OPENDNS=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 drqj0ZTqRxZh for <uta@ietfa.amsl.com>; Sat, 25 Jun 2022 11:45:14 -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 10AD0C14792E for <uta@ietf.org>; Sat, 25 Jun 2022 11:45:13 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 4AEBBFEFDF; Sat, 25 Jun 2022 14:45:12 -0400 (EDT)
Date: Sat, 25 Jun 2022 14:45:12 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org
Message-ID: <YrdXuGgMKMM+gKJn@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <A7E6035E-7BCF-4BB3-BB87-D261ED98532D@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/8gta_qgLc_ccE2AgY8P5vvCoTwk>
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: Sat, 25 Jun 2022 18:45:18 -0000

On Fri, Jun 24, 2022 at 07:04:28PM +0300, Yaron Sheffer wrote:

> * Similarly, it is not clear to me whether certs obtained through DANE
> are in or out of scope.

I may be able to help, but I am struggling to understand the question in
sufficient detail.  Can you be more specific about:

    - What do you mean by "certs obtained through DANE" (typically the
      certs are obtained from the TLS server certificate message, and
      matching type Full(0) certificates in the TLSA record are very
      rare)?  Even then, these are semantically not much different from
      those sent in the server certificate message, other than being
      asserted or required trust anchors.

    - Did you perhaps mean *validation* of certificates (received in the
      usual way) via DANE TLSA records?  That is, are DANE-based
      expected to adhere to all the normative text in the draft?

      The main thing that's different about DANE is that in some
      application protocols Unknown Key Share issues are not believed to
      be a concern.  And in these cases EE TLSA records that specify
      only the certificate or public key hash validate a presented
      certificate with a matching public key regardless of lack of
      matching presented identifiers or inception / expiration dates.

      Validation via DANE trust-anchors is the same as validation via
      local WebPKI trust anchors, except that in the case DANE-TA(2) the
      trust-anchor certificate must appear in the server certificate
      chain when the TLSA record provides just a hash of its SPKI (or
      even just the SPKI, which I expect some implementations might not
      support, though this is supported in OpenSSL).

    - Either way, what is it that might then be in or out of scope?

-- 
    Viktor.