[Apologies for the delay in responding, it has been a busy month...] Amir,
> On Aug 2, 2023, at 12:49 PM, Amir Omidi <[email protected]> > wrote: > > 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. I'm hoping that this same mechanism can be used in the enterprise where you might see "host.internal.example.com" FQDNs being used/generated - think Windows Server or similar DNS/domain/certificate management. Having a common discovery mechanism and certificate management protocol will go a long ways towards making support ubiquitous and networks more secure... > 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. This got added a while back because of concerns that implementors might not aim high enough. I could simply reference RFC 9325 but it doesn't really focus on certificate generation and some of its guidance is already out-of-date, e.g., 2048-bit RSA and ECDSA P-256 are not considered "secure enough" by many... > 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. Agreed, although we need to be careful about how much storage is needed for this on CPE. > 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? Possibly. We need to be careful about creating a "revocation storm", however, since a new device will announce its intention to use a particular name which might cause a collision forcing the device to rename. This isn't usually a problem for printers since they default to a prefix+MAC name ("hp123456789abc.local") but other kinds of IoT might not be so well behaved... > 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. I think the user experience would be up to the OS vendor, but I'd expect some sort of "trust this Wi-Fi network" UI like already exists on Windows. > 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. Client == device in this context, but I'm happy to clarify if you have some suggestions. > 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. My thought was to simply set an upper limit that offers reasonable security and overhead - happy to lower the upper limit but too much churn could be a burden for CPE. I would expect that the limit would be configured by the network administrator with a default from the manufacturer... ________________________ Michael Sweet _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
