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

[Carl Wallace <[e-mail]>]

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 <[e-mail]> on behalf of Michael Sweet <msweet=[e-mail]>
Date: Wednesday, August 2, 2023 at 11:08 AM
To: IOTOPS Working Group <[e-mail]>, <[e-mail]>, PWG IPP Workgroup <[e-mail]>
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: [e-mail]

Subject: New Version Notification for draft-sweet-iot-acme-04.txt

Date: August 2, 2023 at 12:01:54 PM EDT

To: "Michael Sweet" <[e-mail]>

 


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 [e-mail] https://www.ietf.org/mailman/listinfo/acme