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? 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. 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? 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. From: Acme <[email protected]> on behalf of Michael Sweet <[email protected]> Date: Wednesday, August 2, 2023 at 11:08 AM To: IOTOPS Working Group <[email protected]>, <[email protected]>, PWG IPP Workgroup <[email protected]> Subject: [Acme] Fwd: New Version Notification for draft-sweet-iot-acme-04.txt All, This version addresses the feedback I've received since IETF-116, namely: - Using the ACME server's root certificate as the network identifier - Highlighting where/how this fits with secure network connection - Clarifying the trust model - Adding security considerations WRT key material As always, feedback and questions are appreciated! Begin forwarded message: From: [email protected] Subject: New Version Notification for draft-sweet-iot-acme-04.txt Date: August 2, 2023 at 12:01:54 PM EDT To: "Michael Sweet" <[email protected]> A new version of I-D, draft-sweet-iot-acme-04.txt has been successfully submitted by Michael Sweet and posted to the IETF repository. Name: draft-sweet-iot-acme Revision: 04 Title: ACME-Based Provisioning of IoT Devices Document date: 2023-08-02 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.txt Status: https://datatracker.ietf.org/doc/draft-sweet-iot-acme/ Html: https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html Htmlized: https://datatracker.ietf.org/doc/html/draft-sweet-iot-acme Diff: https://author-tools.ietf.org/iddiff?url2=draft-sweet-iot-acme-04 Abstract: This document extends the Automatic Certificate Management Environment (ACME) [RFC8555] to provision X.509 certificates for local Internet of Things (IoT) devices that are accepted by existing web browsers and other software running on End User client devices. The IETF Secretariat ________________________ Michael Sweet _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
