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

This seems very interesting! I would love a good mechanism for local
certificates, even just in basic development. A couple of points of
feedback:

1) Name constraints on the root:
https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html#name-root-ca-certificate

I'd recommend specifying that the root should be generated with name
constraints for `.local` and whatever IP space that's being used. More name
constraints can be used if the root is also going to do things like local
smime.

2) Restricting key types, etc:
https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html#name-root-ca-certificate

I'm not sure if it makes sense to create this restriction here. Especially
with PQ coming up, it might be a good idea to recommend a few specific
curves/methods, but not require that those are the only ones to be used.

3) Handling Revocation:
https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html#name-revocation-and-reissuance-r

It might be useful to specify if OCSP/CRLs/Some other mechanism will be
used here.

4) Revoking old mDNS names:
https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html#name-mdns-domain-name-collisions

For a device to revoke all of the old mDNS names, I think since the name
has changed, it must use the ACME account revocation method. I think it
might be useful to define that the account key should be stored on the
client device so it can do this operation. Alternatively, a device coming
onto the network can check to see if there are any certificates with its
mDNS name that it doesn't know about, and revoke those?

5) Client device trust on first use:
https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html#name-client-device-configuration

I'm not sure how I feel about a client (say, my laptop) just trusting a
root that's on the network with no input from me. Maybe some language on
that if the client is an interactive client, it should somehow inform the
user? And a client MUST reject a certificate that doesn't utilize name
constraints as mentioned in #1.

6) nit: Key protection:
https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html#section-4.10

Language here somewhat implies that it's okay for a client's key to somehow
end up on the server. I don't believe that's the intention. Some clarifying
language here may help.

7) Validity of certificates:
https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html#name-iot-device-certificates

I would recommend significantly reducing the validity of these
certificates. In a local-only situation, a validity period of more than,
say 14 days does not seem worth it here.

If you could justify bringing that number to ~7 days, then you can probably
ignore the complexity of revocation as well due to the caching of OCSP/CRLs.

Thank you!

On Wed, Aug 2, 2023 at 12:09 PM Michael Sweet <msweet=
40msweet.org@dmarc.ietf.org> wrote:

> 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: *internet-drafts@ietf.org
> *Subject: **New Version Notification for draft-sweet-iot-acme-04.txt*
> *Date: *August 2, 2023 at 12:01:54 PM EDT
> *To: *"Michael Sweet" <msweet@msweet.org>
>
>
> 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
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>