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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 27 June 2022 22:14 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 043C1C15AE2E for <uta@ietfa.amsl.com>; Mon, 27 Jun 2022 15:14:01 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] 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 RcNLe4wYVCJS for <uta@ietfa.amsl.com>; Mon, 27 Jun 2022 15:13:58 -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 ACFF4C15AE2A for <uta@ietf.org>; Mon, 27 Jun 2022 15:13:58 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id A9EC71003C6; Mon, 27 Jun 2022 18:13:56 -0400 (EDT)
Date: Mon, 27 Jun 2022 18:13:56 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org
Message-ID: <YrorpEyiXIWDinNz@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> <ae5b3a02-bcc3-2106-a39a-b67aae55d85c@stpeter.im> <ac41a613-f802-0138-1e1b-326d2baa6574@stpeter.im> <BE6D8552-2723-4B64-9909-22C0BC32AC75@gmail.com> <8cf3b08d-478c-4cc5-be19-46cc1cc90271@stpeter.im> <YroARsHlIeR97z52@straasha.imrryr.org> <45cf71a8-c890-695a-5469-a7d545143571@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <45cf71a8-c890-695a-5469-a7d545143571@stpeter.im>
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/Jt8cGjtYQQkH50wTsB-RcUJOGWk>
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 22:14:01 -0000

On Mon, Jun 27, 2022 at 02:43:43PM -0600, Peter Saint-Andre wrote:

> On 6/27/22 1:08 PM, Viktor Dukhovni wrote:
> > On Mon, Jun 27, 2022 at 12:52:00PM -0600, Peter Saint-Andre wrote:
> > 
> >>> Yep, we can punt the definition but then we need to address all the special cases.
> >>
> >> I would prefer to bring back the reference to RFC 1034.
> > 
> > A DNS FQDN is sequence of dot-separated labels each of whose wire forms
> > is at most 63 octets, and where the total wire length including the
> > final zero length byte (terminating empty root label) is at most 255
> > bytes.  Due to potential characters that need escaping, the presentation
> > form of such a name can contain labels whose length exceeds 63 bytes,
> > and whole name can exceed 255 bytes.
> > 
> > It is not clear to me that DNS names in certificates are a priori
> > constrained by the host requirements RFC which constrains hostnames to
> > LDH label forms, although perhaps the scope of RFC6125bis is exclusively
> > for certificates that identify end-entities that meet the host
> > requirements RFC.
> 
> I'm not necessarily saying that - I'm saying only that Jeff and I tried 
> to find a canonical definition of "fully-qualified domain name" and the 
> best we could do was RFC 1034. Alternative proposals are welcome.

There are only two possible answers:

  - All DNS names are valid, so long as they have a wire form that
    meets the requirements of RFC 1034.

  - Only names that comply with section 2.1 of the Host Requirements RFC:

        https://datatracker.ietf.org/doc/html/rfc1123#page-13

    are valid.  These are LDH forms, whose labels therefore require no
    special processing in presentation form, and so the limits are at
    most 63 octets per label, and at most 254 bytes total (allowing for
    an extra byte for the final 0 length wire-form label).

    In LDH form the hyphens must not be the first or last character of
    any label.  Names starting with "xx--" for various values of "xx"
    are special reserved forms with (IIRC) "xn" being the only presently
    defined prefix, but I don't think that it is appropriate for the
    present document to delve into this level of detail.

    The host requirements RFC further recomments staying under 63 bytes,
    and though this is somewhat dated, it is nevertheless prudent if
    possible.

-- 
    Viktor.