[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 <c...@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 _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
