I’m confused about what is desired with 
draft-yusef-acme-3rd-party-device-attestation, but I think it may be quite 
different from what draft-ietf-acme-authority-token offers. Here’s my guess:

draft-ietf-acme-authority-token is designed to issue certs for namespaces other 
than domain names, eg for phone numbers. The CA trusts another authority to 
vouch for that namespace.

draft-yusef-acme-3rd-party-device-attestation is designed to issue certs for a 
domain name (as per normal Acme). The cert will be for a specific device whose 
serial number (eg MAC address) the domain-owner knows. The device manufacturer 
can vouch for device keys associated with that serial number.
Curiously, the protocol flow in draft-yusef-acme-3rd-party-device-attestation 
doesn’t seem to involve the device at all – only the domain-owner (client), 
manufacturer, and CA. But surely the device needs to provide the CSR?

It sounds like the client (domain-owner) should be able to confirm the correct 
device is involved (by talking to the device and manufacturer) before sending a 
normal ACME request. That way the ACME CA doesn’t need to know anything about 
the device attestation.

--
James Manger
+61 4 1754 1870
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to