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= [email protected]> 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: *[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
