confusion about AAGUID role

[LW1]

Hi team,
I need a clarification about the AAGUID role.
For my understanding the AAGUID should hint the RP which authenticator was used to create the response, and act accordingly (e.g.: accept responses from specific authenticators only).
My question is: What prevent other authenticators using the same AAGUID as mine?

[My1]

in most cases that's where attestation helps, and it is useful to check it at least if present.

once checked, it is easier to look up stuff by AAGUID then to do deep readings of the certificate data.

additionally some authenticators cannot be attested by design like synced passkeys with google or devices without a mechanism to protect its attestation keys against its legitimate user, these do only do some basic self attestation where the AAGUID is more an informational thing only and sure as you mentioned can be faked, but is still useful to keep track to inform a user which device a credential has or if there is a known vulnerability or some other issue to inform them.

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/00f06861-093c-48ae-9e97-a83f85a130afn%40fidoalliance.org.

[LW1]

So how the attestation works?
I understand that it's an object signed by the manufacturer key.
But how the RP can validate it's really the manufacturer signature and not some random signature?
In other words: Where  the manufacturer certificate is advertised?

[Arshad Noor]

Attestation works as follows. Every Authenticator that chooses to
provide an attestation during FIDO registration:

* Has an attestation certificate [chain] with the private key of the
attestation certificate embedded in the Authenticator;

* If the manufacturer chooses to publish metadata statements in the FIDO
Alliance's MDS, it publishes the attestation certificates' chains' Root
CA certificates along with other metadata about the Authenticator (see
WebAuthn spec and FIDO Alliance MDS specs for details);

* If the manufacturer chooses NOT to publish metadata statements in the
MDS, it may choose to place a self-signed attestation certificate - at
least 1 per every 100K Authenticators - with the attestation
certificate's private key in the Authenticator. This self-signed
attestation certificate cannot deliver any other public validation from
the manufacturer because the certificate is "SELF SIGNED" without a
hierarchy. However, the manufacturer can choose to make the self-signed
attestation certificate[s] - without the private key[s] - available to
its customers out-of-band in whatever manner the customer deems
acceptable to their security policy;

* If the manufacturer chooses to embed an attestation certificate (with
its private key) from a chain with its own self-signed Root CA, it may
choose to embed appropriate PKIX extensions in all certificates in the
chain and publish the Root CA certificate and CRLs at a site of its own
choosing. RPs' FIDO servers - or their applications [if the FIDO
server/library cannot handle it] - SHOULD perform PKIX validation to
verify the chain, and allow the RP to decide whether to trust the
self-signed Root CA certificate - how it does this is upto the
implementer of the FIDO server/library;

* During the registration process, the attestation certificate's private
key signs a data structure and supplies its attestation certificate
(without the private key) with the signed data as a result of the FIDO
credential's creation process. FIDO Certified servers/libraries MUST
verify the signature on the signed object before following the RP's
stated policy for accepting the registration.

To learn more about digital certificates, this is the best introduction
I have repeatedly referenced to anyone over a quarter century - pity
that MDN does not maintain it currently:

https://web.archive.org/web/20040803053001/http://developer.netscape.com/docs/manuals/security/pkin/index.html

Arshad

> a83f85a130afn%40fidoalliance.org <https://groups.google.com/a/
> fidoalliance.org/d/msgid/fido-dev/00f06861-093c-48ae-9e97-
> a83f85a130afn%40fidoalliance.org?
> utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to fido-dev+u...@fidoalliance.org <mailto:fido-
> dev+uns...@fidoalliance.org>.

> To view this discussion visit https://groups.google.com/a/

> fidoalliance.org/d/msgid/fido-dev/12733567-
> dae7-4fa9-9f0f-807ce73ca3fcn%40fidoalliance.org <https://
> groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/12733567-
> dae7-4fa9-9f0f-807ce73ca3fcn%40fidoalliance.org?
> utm_medium=email&utm_source=footer>.