Refactor: use spomky-labs/pki-framework to replace native php openssl functions for attestation statements
Target branch: 5.3.x Resolves issue #
- [ ] It is a Bug fix
- [ ] It is a New feature
- [ ] Breaks BC
- [ ] Includes Deprecations
- [x] It is an enhancement or refactor
The Problem I encountered
Environments
- php: 8.4
- web-auth/webauthn-lib: 5.2.2
I got two different results when parsing the following certificate with PHP openssl_x509_parse
-----BEGIN CERTIFICATE-----
MIICNjCCAdygAwIBAgIQMR/ELaCrEMQ6mxvzp1404jAKBggqhkjOPQQDAjBiMR4w
HAYDVQQDDBVXZWJBdXRobiB0ZXN0IHZlY3RvcnMxDDAKBgNVBAoMA1czQzElMCMG
A1UECwwcQXV0aGVudGljYXRvciBBdHRlc3RhdGlvbiBDQTELMAkGA1UEBhMCQUEw
IBcNMjQwMTAxMDAwMDAwWhgPMzAyNDAxMDEwMDAwMDBaMAAwWTATBgcqhkjOPQIB
BggqhkjOPQMBBwNCAATFTj8QkJT2DXaZt9tdg4Vp/9Hz4cnol82etABj+UAuPpk3
6TbPH81et0P/RDyXqy7c18jg5s9s/UE7irGf/6dpo4HTMIHQMAwGA1UdEwEB/wQC
MAAwDgYDVR0PAQH/BAQDAgeAMB0GA1UdDgQWBBRfVGy2lz1JgegPzcdGOFn1h5aA
5DAfBgNVHSMEGDAWgBRFr/cVsN14Z0H+6ZbrwWVHo5MbHjAQBgNVHSUECTAHBgVn
gQUIAzBeBgNVHREBAf8EVDBSpFAwTjFMMBQGBWeBBQIBDAtpZDowMDAwMDAwMDAU
BgVngQUCAwwLaWQ6MDAwMDAwMDAwHgYFZ4EFAgIMFVdlYkF1dGhuIHRlc3QgdmVj
dG9yczAKBggqhkjOPQQDAgNIADBFAiBjyaJ5e4Bm8ds03WCfGrZpVgfnqY6f+AkK
aIU8mp/JSQIhAKVYMaOfW4oqqaaIN4Kcq/Q/6ipc6khZroUcrHjmrD6X
-----END CERTIFICATE-----
array (
'extensions' =>
array (
'basicConstraints' => 'CA:FALSE',
'keyUsage' => 'Digital Signature',
'subjectKeyIdentifier' => '5F:54:6C:B6:97:3D:49:81:E8:0F:CD:C7:46:38:59:F5:87:96:80:E4',
'authorityKeyIdentifier' => '45:AF:F7:15:B0:DD:78:67:41:FE:E9:96:EB:C1:65:47:A3:93:1B:1E',
--- 'extendedKeyUsage' => '2.23.133.8.3',
--- 'subjectAltName' => 'DirName:2.23.133.2.1 = id:00000000 + 2.23.133.2.3 = id:00000000 + 2.23.133.2.2 = WebAuthn test vectors',
+++ 'extendedKeyUsage' => 'Attestation Identity Key Certificate',
+++ 'subjectAltName' => 'DirName:tcg-at-tpmManufacturer = id:00000000 + tcg-at-tpmVersion = id:00000000 + tcg-at-tpmModel = WebAuthn test vectors',
),
)
The php openssl_x509_parse was run in two different environments:
- macOS: 15.7 + openssl(3.6.0): got the
extendedKeyUsageisAttestation Identity Key Certificate - php 8.4 docker image + openssl (3.0.17): got the
extendedKeyUsageis2.23.133.8.3
This will break the check in https://github.com/web-auth/webauthn-framework/blob/cb78e7a2c93d4f7717b417790f78a55634ab4c42/src/webauthn/src/AttestationStatement/TPMAttestationStatementSupport.php#L411
What I want to do
Even though this check has been fixed in 5.3.x by https://github.com/web-auth/webauthn-framework/pull/736/commits/0f8269d96b4f7110fe606bad639a429acd2f5ea4 and https://github.com/web-auth/webauthn-framework/pull/736/commits/6512be20825c6110a70ff89bb0a2c7eb8586a942 https://github.com/web-auth/webauthn-framework/blob/4d7c777ef4ac38b20b036283f091c8d235e16a66/src/webauthn/src/AttestationStatement/TPMAttestationStatementSupport.php#L410-L414
But I think checking extendedKeyUsage equals Attestation Identity Key Certificate is not reliable, as I can not find any evidence to prove Attestation Identity Key Certificate is a standard alias for the 2.23.133.8.3, which we can do an exact match with. What I found includes:
- https://oid-base.com/get/2.23.133.8.3
- https://oidref.com/2.23.133.8.3
Since the return value of openssl_x509_parse is undetermined, I prefer to use https://github.com/Spomky-Labs/pki-framework to rewrite the logic for the certificate parsing and validation to gain the determined behaviors. This could help us handle more edge cases more easily.
Update
After my future investigation, I found that the Attestation Identity Key Certificate was introduced by https://github.com/openssl/openssl/commit/91833068158caf866175a43a26fad9f4dc480a95#diff-1339397eefc37a88aaa3e0b5dfee72e8efe654d0226bcdb427ce9c13d4dc0e23R1925 since OpenSSL 3.5.0.
Hi, @Spomky
It would be very appreciated if you take a look at this when you are free?
Hi, @Spomky
Can you help me review this PR? Please let me know if there is something wrong with my understanding or implementation. 🙇♂️
Many thanks.
Rebased on 5.2.x (see #790). Will be tagged 5.2.3