Distributing trust anchors to verify device attestations is one of the aims of https://datatracker.ietf.org/doc/html/draft-wallace-rats-concise-ta-stores-00. Note, there's also a LAMPS draft that borrows the WebAuthn format approach from this ACME device attestation draft but for use in extensions suitable for CMP, EST, SCEP, etc.
On 7/20/22, 6:41 PM, "RATS on behalf of Michael Richardson" <[email protected] on behalf of [email protected]> wrote: I read acme-device-attest, and I guess the key part is a new device-attest-01 method. https://www.ietf.org/archive/id/draft-bweeks-acme-device-attest-00.html#name-device-attestation-challeng tries to explain the format, and how the challenge is signed by the device. What I do not understand is any of the trust relationships between the ACME server and the manufacturer/provisionor of the Android Key Attestation/Chrome OS Verified Access/Trusted Platform Module. Why does the Enterprise trust the attestation key? -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ RATS mailing list [email protected] https://www.ietf.org/mailman/listinfo/rats _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
