[Lake] Robert Wilton's No Objection on charter-ietf-lake-01-00: (with COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Thu, 27 April 2023 09:39 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: lake@ietf.org
Delivered-To: lake@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABD6C14CE5D; Thu, 27 Apr 2023 02:39:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: lake-chairs@ietf.org, lake@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 10.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <168258839103.30175.13100558816904159677@ietfa.amsl.com>
Date: Thu, 27 Apr 2023 02:39:51 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/M9z3qsKA4-1Dps0i4EkcraaII4M>
Subject: [Lake] Robert Wilton's No Objection on charter-ietf-lake-01-00: (with COMMENT)
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Apr 2023 09:39:51 -0000

Robert Wilton has entered the following ballot position for
charter-ietf-lake-01-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-lake/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with the others that the intro to the WG is quite long.

I also found this paragraph hard to parse:

Within each protocol message, EDHOC provides External Authorization Data (EAD)
fields. These fields may be used by external security applications to reduce
the number of messages and round trips, or to simplify processing. The working
group will specify the following uses of EAD fields to augment the EDHOC key
exchange: 3rd party-assisted authorization of EDHOC peers.
Draft-selander-lake-authz is a candidate starting point for this work. Remote
attestation of EDHOC peers, for instance using the available work from the RATS
working group. Status verification of EDHOC peer authentication credentials
transported during an EDHOC key exchange (e.g. OCSP stapling).

Stylistically, this might be clearer as something like this (if this is what is intended):

Within each protocol message, EDHOC provides External Authorization Data (EAD)
fields. These fields may be used by external security applications to reduce
the number of messages and round trips, or to simplify processing. The working
group will specify the following uses of EAD fields to augment the EDHOC key
exchange:

  - 3rd party-assisted authorization of EDHOC peers.  Draft-selander-lake-authz
    is a candidate starting point for this work.

  - Remote attestation of EDHOC peers, for instance using the available work
    from the RATS working group.

  - Status verification of EDHOC peer authentication credentials transported
    during an EDHOC key exchange (e.g. OCSP stapling).