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