Platform vendors can and do change things (including formats) at any time. Any verification procedures should be described in a reference identified in the registry (ideally with some words about sources for trust anchors).
The approach in the concise-ta-stores spec is similar to how TAs are handled in the FIDO metadata syntax spec. In the FIDO spec, TAs can be looked up by an authenticator ID. In the proposed spec, it's a more open environment definition because there is not as narrow a target as in the FIDO case, but it can be used to a similar end targeting vendor/product. In a CA I supported that has verified key attestations during certificate enrollment since 2018, we had a separate TA store per supported attestation type, with the stores manually updated as needed. The proposal manages a set of TA stores in an array, so different TA store elements in the array could address different attestation types, for example. There's nothing in the proposal re: distribution mechanism, frequency, etc. On 7/21/22, 6:55 PM, "Brandon Weeks" <[email protected]> wrote: Unfortunately each attestation format has a different method of verifying the trust relationship of the attestation certificates. - Android Key Attestation: Android publishes the root certificates that all valid attestation certificates chain up to. - https://developer.android.com/training/articles/security-key-attestation#root_certificate - Apple Managed Device Attestation: follows a similar pattern of Android, the attestation certificates chain up to a well-known root. - Chrome OS: there is only a web API for verifying challenges, there is no way to do offline verification. - https://developers.google.com/chrome/verified-access/developer-guide#how_to_verify_user_and_device - TPM: an enterprise would manually curate a collection of trusted Endorsement Key certificate roots or use Microsoft's curated collection. - https://go.microsoft.com/fwlink/?linkid=2097925 Since platform vendors define the verification procedures and can change the procedure or the trusted roots at any time, I'm not sure the best place to either specify or informatively reference the verification procedures. On Wed, Jul 20, 2022 at 4:07 PM Carl Wallace <[email protected]> wrote: > > 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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
