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

[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