Its a losing battle, Matthew.
The majority of members of the FIDO Alliance are not keen on
enforcing PKIX standards on Attestation certificates. They believe
that this is a Authenticator differentiation factor and should be
negotiated between buyers and vendors of Authenticators. Which is
why you see variability that ranges, on the one end, from an
Android Key Attestation (where you can get an attestation from the
Android hardware) to nothing on the other end from an Apple iOS
device with Passkeys.
The only recourse you have is to get what might be available from
the Metadata Statement for the specific AAGUID and make your
decisions based on that. But, once again, an Authenticator
manufacturer publishing anything on the MDS is optional - and when
they choose to publish anything, there is no stipulation about the
Attestation certificate other than that it be an X.509v3
certificate.
Arshad Noor
StrongKey
--
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 on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/165fafd3-ed43-4a9f-8cf9-df58b44b2164n%40fidoalliance.org.
Digging into RFC 3280 some, I believe this root certificate is invalid because of this paragraph in Section 4.2.1.1:The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction. There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted. The signature on a self-signed certificate is generated with the private key associated with the certificate's subject public key. (This proves that the issuer possesses both the public and private keys.) In this case, the subject and authority key identifiers would be identical, but only the subject key identifier is needed for certification path building.The certificate marks `cA:true` internally, and so I believe this certificate is malformed because its Authority Key Identifier is missing its keyIdentifier field. This key identifier is needed to check the certificate's revocation status when verifying an attestation using a FIDO metadata statement.
There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted. The signature on a self-signed certificate is generated with the private key associated with the certificate's subject public key. (This proves that the issuer possesses both the public and private keys.) In this case, the subject and authority key identifiers would be identical, but only the subject key identifier is needed for certification path building.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/4a46e284-6670-7809-fc6f-b2eb25ed3fb2%40strongkey.com.
On Dec 11, 2022, at 9:49 AM, My1 <teamhyd...@gmail.com> wrote:
--
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 on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/4f89bee9-a990-4e5e-b5de-ad952957b13en%40fidoalliance.org.
Thank you David for taking care of this.