Malformed root certificate for IDMelon software authenticator

[Matthew Miller]

Hello fido-dev,

I've been informed of an attestation root certificate for AAGUID 820d89ed-d65a-409e-85cb-f73f0578f82a ("Vancosys iOS Authenticator") that fails a certificate revocation check because the root certificate's Authority Key Identifier is missing its keyIdentifier field.

Here's the certificate pulled from MDS:

-----BEGIN CERTIFICATE-----

MIIB/zCCAaSgAwIBAgIUPbddlpEdAdN+fm8JFanUXurNZy8wCgYIKoZIzj0EAwI
wQTEkMCIGA1UECgwbVmFuY29zeXMgRGF0YSBTZWN1cml0eSBJbmMuMRkwFwYDVQ
QDDBBWYW5jb3N5cyBSb290IENBMCAXDTIwMTEwNDA2NDQxN1oYDzIwNzAxMDIzM
DY0NDE3WjBBMSQwIgYDVQQKDBtWYW5jb3N5cyBEYXRhIFNlY3VyaXR5IEluYy4x
GTAXBgNVBAMMEFZhbmNvc3lzIFJvb3QgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQM
BBwNCAARqViASimcpJwCb531/VekYHfNuRkIPeFkQq7FNyWkFiWPjKk1GDSAxJr
uB4GB3qdyTnRhpWF3Lvm4hzbBtZfy3o3gwdjBmBgNVHSMEXzBdoUWkQzBBMSQwI
gYDVQQKDBtWYW5jb3N5cyBEYXRhIFNlY3VyaXR5IEluYy4xGTAXBgNVBAMMEFZh
bmNvc3lzIFJvb3QgQ0GCFD23XZaRHQHTfn5vCRWp1F7qzWcvMAwGA1UdEwQFMAM
BAf8wCgYIKoZIzj0EAwIDSQAwRgIhAOGjcwJUT7A/ER+5pACEPrOg79wbE/h8YM
YUgymrXR6GAiEA7N6U3EWeQweMOmTOqavtWCdYCsMJcop9p13l9QbohDo=
-----END CERTIFICATE-----

This is used to by the IDMelon Authenticator app:

https://www.idmelon.com/idmelon-authenticator-details/

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.

Can someone at the FIDO Alliance please confirm this, and consider contacting the vendor to update their software authenticator's metadata?

Thank you,

-Matthew Miller

[Matthew Miller]

(Apologies to the IDmelon devs for my mis-capitalizing the name twice 🤦‍♂️)

[Arshad Noor]

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.

[Adam Langley]

On Sunday, December 11, 2022 at 9:02:36 AM UTC-8 maste...@gmail.com wrote:

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.

The keyIdentifier field is optional in the ASN.1 itself, so it comes down to the text, which I think is ambiguous. The "one exception" seems like it applies here: it's a self-signed CA certificate. But the exception applies to the rule that the keyIdentifier field must be included, but then concludes with "the authority key identifier MAY be omitted". But does that mean that the whole extension may be omitted, or the keyIdentifier of the extension? I think there's a fair argument to say that this certificate is ok on those grounds.

 

(That RFC is actually obsoleted by 5280, but the text in question hasn't changed in the newer RFC, so that doesn't help.)

I think there's a stronger case in the next section, in fact. https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.2 says that all certificates with CA=true must have a subject key identifier extension, and this one doesn't.

However, the certificate is clearly self-issued and so I'm not sure that revocation checking should fail because of that.

Cheers

AGL

[My1]

The cert is selfsigned tho. and the text specifically says:

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.

authority key is only needed when there's an upper certificate, but when the cert is signed by itself and there is no way up the chain, where an authority key identifier would be needed.

the sub-certs obviously do need it tho.

Regards
My1

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.

[Matthew Miller]

Thanks for the insights Adam (and thank you for pointing out that RFC 5280 had replaced RFC 3280, whoops...) The way I was reading things, a certificate marked cA:true...

1. MUST specify a keyIdentifier in its Authority Key Identifier extension "...in all certificates generated by conforming CAs to facilitate certification path construction" (Section 4.2.1.1)

2. Or, if self-signed, MAY omit the Authority Key Identifier extension, but specify a keyIdentifier in a Subject Key Identifier that should be equal to the one in Authority Key Identifier

But this certificate does neither. And Section 4.2.1.2 also compels a CA to include a Subject Key Identifier when cA:true but here too the certificate appears to be bad.

> However, the certificate is clearly self-issued and so I'm not sure that revocation checking should fail because of that.

So what might I, as a library maintainer, do here? I thought MDS was intended to be a stronger mode of operation, but it seems the path forward is to entertain such edge cases and simply skip the revocation check if a certificate lacks a keyIdentifier. It sounds wrong to do this, though - couldn't a bad actor simply fail to include a keyIdentifier value anywhere and bypass such a check? Maybe the implications aren't that bad?

[Matthew Miller]

But there needs to be a public key ID set SOMEWHERE to check for root certificate revocation. In the case of a self-signed root cert, I can see why Authority Key Identifier could be omitted. But it still seems to me that Subject Key Identifier is required (especially because of cA:true in the certificate) and could be used instead to reference a keyIdentifier if it was present.

On Dec 11, 2022, at 9:49 AM, My1 <teamhyd...@gmail.com> wrote:



[My1]

okay subject key wasnt part of the parts I read when I replied, but sure if that is missing that kinda six.

but what identifies the key? the hash? couldnt that just be calculated when processing stuff with the cert? I mean the public key IS in the certificate, isnt it?

[Hassan Seifi]

Hi Matthew,

From IDmelon, I will be responsible for this if any change is required. The identifiers are supposed to be derived from the public key, and not sure if they bring any new value for the revocation check. 

Can you please tell me what this revocation process is? I do agree that this should be part of the MDS check otherwise it may break things for end users.

Thanks, Hassan

--

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.

--

Thanks, Hassan

[David Turner]

FYI, the certificates have been updated. 

Get Outlook for iOS

---

From: fido...@fidoalliance.org <fido...@fidoalliance.org> on behalf of Hassan Seifi <seif...@gmail.com>
Sent: Sunday, December 11, 2022 2:02:46 PM
To: Matthew Miller <maste...@gmail.com>
Cc: FIDO Dev (fido-dev) <fido...@fidoalliance.org>; a...@google.com <a...@google.com>
Subject: Re: [FIDO-DEV] Re: Malformed root certificate for IDMelon software authenticator

 

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAE8gTaGt87Fa57216GzySshj%2BUWEM7Q%2BAza%2B02CeMf290dq_6A%40mail.gmail.com.

[Hassan Seifi]

Thank you David for taking care of this.