Re: [Last-Call] Opsdir last call review of draft-hodges-webauthn-registries-05

Benjamin Kaduk <kaduk@mit.edu> Sun, 03 May 2020 22:02 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90B93A1211; Sun, 3 May 2020 15:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 JjG3H5Osebeo; Sun, 3 May 2020 15:02:27 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3063A10EB; Sun, 3 May 2020 15:02:27 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 043M2KAJ027183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 3 May 2020 18:02:24 -0400
Date: Sun, 03 May 2020 15:02:20 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Sarah Banks <sbanks@encrypted.net>
Cc: ops-dir@ietf.org, last-call@ietf.org, draft-hodges-webauthn-registries.all@ietf.org
Message-ID: <20200503220220.GD27494@kduck.mit.edu>
References: <158809569895.24036.8131068505152887145@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <158809569895.24036.8131068505152887145@ietfa.amsl.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/uwA5-5tmd3ywRs7vg2Wt7XAvxAY>
Subject: Re: [Last-Call] Opsdir last call review of draft-hodges-webauthn-registries-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 May 2020 22:02:29 -0000

Hi Sarah,

On Tue, Apr 28, 2020 at 10:41:39AM -0700, Sarah Banks via Datatracker wrote:
> Reviewer: Sarah Banks
> Review result: Has Issues
> 
> Hello,
>      I too share the concerns the GENART reviewer does. In addition, a few
>      things:
> 
> 1. As a personal nit, I'm slightly annoyed as a reader that the draft defines
> the registries, but another doc has the default values. Just ann FYI, and I
> realize this is a style choice.

I think it's important to note that the initial registry contents are to
list a non-IETF organization as the change controller.  To me, it seems
more appropriate to have that organization produce a document to effectuate
the registrations they desire, rather than having the IETF publish a
document that tries to allocate things on their behalf.

> 2. In section 2.1, it states: "Each attestation
> statement format identifier added to this registry MUST be unique amongst the
> set of registered attestation statement format identifiers.", and that they are
> case sensitive. Did you really intend to allow a conceptual overload where a
> string of "string" and "STRING" would be allowed?

Yes.  See also the note about "may not match [...] in a case-insensitive
manner unless the DEs determine that there is a compelling reason to allow
an exception".

> 3. In a few spots it's
> written (see 2.2.2 for example): " As noted in Section 2.2.1, WebAuthn
> extension identifiers are registered using the Specification Required policy,
> implying review  and approval by a designated expert.". Implied doesn't seem to
> be normative. Given the follow on text here, did you explictly NOT want to make
> this a normative requirement?

It is normative, though -- we use the RFC 8126 policy of "Specification
Required", which by definition includes expert review.  Do you have an
alternate phrasing than "implying" to use for this situation?

Thanks for the review,

Ben