Re: [Iotops] [Acme] New Version Notification for draft-sweet-iot-acme-04.txt

Michael Sweet <msweet@msweet.org> Wed, 17 January 2024 13:30 UTC

Return-Path: <msweet@msweet.org>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4294C151061; Wed, 17 Jan 2024 05:30:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=msweet.org
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 sD8tdJrxo_lE; Wed, 17 Jan 2024 05:30:20 -0800 (PST)
Received: from mail.msweet.org (mail.msweet.org [173.255.209.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB2DC151064; Wed, 17 Jan 2024 05:30:20 -0800 (PST)
Received: from smtpclient.apple (cbl-66-186-76-47.vianet.ca [66.186.76.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.msweet.org (Postfix) with ESMTPSA id BFA0D80445; Wed, 17 Jan 2024 13:30:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.msweet.org BFA0D80445
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=msweet.org; s=default; t=1705498220; bh=UQIHjLJ6Odv9sdaoCdkaHDoYkqXp7vOigzzhbq27Uzw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Lc/DrwLcTonwEd8BspgSJ9k2CdsJBxdytpQIVn4SfVvUdL+K92GXsBZxW9zVbXBme kyC14JOu90m8xPwNMgwmEq6tyokrjGoNAXEUowI2NaiuKZgoAcBFRKiSizFq3n3nGz cHsvdBJxDNyZpPgZ1mCjSv66eMM5o4xhc1GTtchk=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.11\))
From: Michael Sweet <msweet@msweet.org>
In-Reply-To: <DA50710F-C755-458A-94E5-08C71BFB09BA@redhoundsoftware.com>
Date: Wed, 17 Jan 2024 08:30:07 -0500
Cc: IOTOPS Working Group <iotops@ietf.org>, Mailing List <acme@ietf.org>, PWG IPP Workgroup <ipp@pwg.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B17F5DF-E17F-460D-B06B-8F59784E3199@msweet.org>
References: <169099211414.11957.13218136675686326535@ietfa.amsl.com> <C33D08FE-DB2A-4319-9FCD-45B6C2379D55@msweet.org> <DA50710F-C755-458A-94E5-08C71BFB09BA@redhoundsoftware.com>
To: Carl Wallace <carl@redhoundsoftware.com>
X-Mailer: Apple Mail (2.3774.400.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/-RUdr36SvhJu51P6SYalpq2PCJg>
Subject: Re: [Iotops] [Acme] New Version Notification for draft-sweet-iot-acme-04.txt
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jan 2024 13:30:24 -0000

[Apologies for the LONG delay in responding, for some reason this got marked as read and I'm just now seeing it as I do some "spring cleaning"...]

Carl,


> On Aug 30, 2023, at 10:02 AM, Carl Wallace <carl@redhoundsoftware.com> wrote:
> 
> Here are a few comments and questions:
>  Section 3.2.1 says root certificates "MUST contain subjectAltName extensions for ".local" and the local domain name(s), and MAY contain subjectAltName extensions for the current IP address(es) of the server." Section 3.3 says "Client Devices MUST NOT use ".local" host names or IP addresses to validate the CA certificate since those values are not unique." These statements appear to be in conflict. Re: 3.2.1, should there be a similar section for an intermediate CA or is the root expected to issue all certificates?

OK, so after reading this I'm also confused about what I meant... :)

The 3.2.1 requirements basically ensure that the root certificate lists all of the local names.  The 3.3 requirements should be to validate the root certificate based on the expected hostname/IP address provided by the network infrastructure (DHCP option or DNS-SD service) for that network interface.

I'll work on making this more explicit, but the idea is to tie the CA certificate from the local ACME server to the network interface.

>  The MUST in section 4.5 seems like it should be split into a SHOULD for revocation and a MUST for re-issuance. The current text has a MUST for revocation or re-issuance.

I guess revocation could be a SHOULD here - the key is to provide a way to sweep away all prior trust decisions and force a new set of certificates to be generated.

>  Section 4.7 requires revocation of all certificates with an old name when its name changes. Is it necessarily the case that the appropriate local ACME server will be available to revoke the certificates? What should be done if it’s not?

Assuming there is a local ACME server, it will be available.  But certainly in the roaming use case, a device might be renamed on network B and not be able to tell network A's ACME server that its name has changed...  Need to think about how to best handle this but I'm also not sure how common roaming will be for IoT devices - it isn't common to move a printer or video camera between networks and in the case where you have enterprise infrastructure the same ACME server will likely be used across network segments/access points.

>  In Section 4.9 what does "Client Devices MUST separately track and validate the root X.509 certificate for each local ACME Server" mean? Does this mean relative to TOFU, checking self-signed signature and SAN, or something else? The draft intimates there is a separate trust anchor store per network. If this is intended, it may be worth stating.

It is a clumsy way of saying the Client needs to only use a root certificate to validate certificates on that network interface.  I'll work on the wording here but that's what I'm trying to get across...

________________________
Michael Sweet