x5c data in attestation statement
yesvivek opened this issue · 9 comments
I am trying to implement Relying Party using libfido2 on linux environment. All the client interactions are done by browser using webauth JS APIs.
According to webauthn spec I understand the x5c under attStmt can be of array type. But libfido2 stores only the leaf certificate and ignores the other certificates. Is it possible to update libfido2 to provide the other certificates too? This will prevent the callers from parsing the attestation object again. Maybe expose another API to accomplish this?
When using webauth JS API, PublicKeyCredential.AuthenticatorAttestationResponse.attestationObject gives a cbor data containing attestation, format, authData. Can libfido2 expose an API to consume this cbor-data (unparsed, base64url-encoded) directly? This will make the library more easy going with webauthn JS APIs. Without this the caller has to do cbor_load on attestationObject, find attStmt, then serialize it so it can be used with libfido2.
Or, if callers should parse this attestationObject, can libfido2 take attestation statement in libcbor structure? Because caller is already parsing the attestationObject to extract the statement, why not just pass the libcbor structure to it? If you dont want to tie libfido2 to libcbor, probably taking the base64url-encoded attestationObject might be better I feel.
By taking the PublicKeyCredential.AuthenticatorAttestationResponse.attestationObject data encoded in base64url and providing an API to get the x5c array, RP doesn't have to deal with cbor at all, just like how it is with libraries in other languages like NodeJS/Python.
Hi,
According to webauthn spec I understand the x5c under attStmt can be of array type. But libfido2 stores only the leaf certificate and ignores the other certificates. Is it possible to update libfido2 to provide the other certificates too? This will prevent the callers from parsing the attestation object again. Maybe expose another API to accomplish this?
Out of curiosity, which authenticator are you using that is returning a certificate chain? Given a use case, we could certainly try to accommodate it.
When using webauth JS API, PublicKeyCredential.AuthenticatorAttestationResponse.attestationObject gives a cbor data containing attestation, format, authData. Can libfido2 expose an API to consume this cbor-data (unparsed, base64url-encoded) directly? This will make the library more easy going with webauthn JS APIs. Without this the caller has to do cbor_load on attestationObject, find attStmt, then serialize it so it can be used with libfido2.
Historically speaking, libfido2 has positioned itself slightly more towards CTAP than WebAuthn, we could possibly explore something like this nonetheless. If we do, I'd expect that we'd, for consistency reasons, want to read raw bytes rather than base64url-encoded data.
... If you dont want to tie libfido2 to libcbor, ...
Yes, we'll want to avoid libcbor types in our public API.
Thank you for your request! Pull requests are welcome.
which authenticator are you using
Got them from github, was posted on a bug that I couldn't find now, looks like a TPM attestation from Windows Hello, check below,
TPM Attestation data (base64url-encoded)
o2NmbXRjdHBtZ2F0dFN0bXSmY2FsZzn__mNzaWdZAQA1rDcWYZcqEkdVp8D_utz_Vl9B_UhwN12K17vHq-ISiW1O5lj_h9pfmlXiYS1mzpWL9WkeVtEAxXDKbyFNE045Pve5fMeYVdEt7y9atIlQ9xf539Msvpj7_oz6v63hdQu3SyMFTKIVsSxkJsPqhNIL89vtEoLDja3d5QccYApMXS66AnA5nfk-rwAECWClCGoeBHXMb26qFrjUdkhFY79q3ITlbO9OGyFlUj2_R_-Qn9wE53njvMNIycpnoYvIZmpqTxY9WZ4byUg_8AnMDrF7z5M91aJdy57ZrbAdz99QtyGc38jTTSorqmi4WBiEoY1TT2cjcAh3FM_y_P8vQkXKY3ZlcmMyLjBjeDVjglkFvTCCBbkwggOhoAMCAQICEBfzV53dzE_XkuMv8bAjnyEwDQYJKoZIhvcNAQELBQAwQjFAMD4GA1UEAxM3RVVTLUlOVEMtS0VZSUQtQjA2NkQ5Njk3RjVEM0EwN0I0MjVDMTBGNTg3Q0NFRUNGMTZGRkU1ODAeFw0yMzA2MDgwOTEyNTFaFw0yNzA2MDMxNzUxMDVaMAAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCb4lo5dcys31SZ5f5GAc99o1i6isJB1Y4KOJhxsK3uuE3ieIZAxrhsvgIJxeTd4IgJixYkUYb9sy1BfPIZn0BOQBmH_qVU7RcNtHhqEB4muyWb45QL3COTZhaJCnac720Dj7JyycW1ibY517UFXsLjYkJJ3gPUPES9Q4HqiDRuB1HvL8OKhTraJivwADv45nLrlVv7i2YtiRqPWyCR5cDx1XZP-Y6BBWo21aRkGmHJn_726quUSCfHegFrkFyK26Bveq8Z9cAaAcZDL3diGf8FaAfE7-lsybZHVfAH5Eds6kJXQipRUcZazSV3J5WmToylfnsXwWGuFHW5a3oBP6a9AgMBAAGjggHrMIIB5zAOBgNVHQ8BAf8EBAMCB4AwDAYDVR0TAQH_BAIwADBtBgNVHSABAf8EYzBhMF8GCSsGAQQBgjcVHzBSMFAGCCsGAQUFBwICMEQeQgBUAEMAUABBACAAIABUAHIAdQBzAHQAZQBkACAAIABQAGwAYQB0AGYAbwByAG0AIAAgAEkAZABlAG4AdABpAHQAeTAQBgNVHSUECTAHBgVngQUIAzBQBgNVHREBAf8ERjBEpEIwQDEWMBQGBWeBBQIBDAtpZDo0OTRFNTQ0MzEOMAwGBWeBBQICDANUR0wxFjAUBgVngQUCAwwLaWQ6MDI1ODAwMDcwHwYDVR0jBBgwFoAUaAThqfZhToosywMcnQAOoZ_3aIMwHQYDVR0OBBYEFHe1SoBjXVb32bGR0oSsMxkXLOGnMIGzBggrBgEFBQcBAQSBpjCBozCBoAYIKwYBBQUHMAKGgZNodHRwOi8vYXpjc3Byb2RldXNhaWtwdWJsaXNoLmJsb2IuY29yZS53aW5kb3dzLm5ldC9ldXMtaW50Yy1rZXlpZC1iMDY2ZDk2OTdmNWQzYTA3YjQyNWMxMGY1ODdjY2VlY2YxNmZmZTU4Lzc5MWYwYWUzLWYyNDQtNGE4Yy04NWQ1LWMzODNiYjdlMDM5My5jZXIwDQYJKoZIhvcNAQELBQADggIBACu6od4kRrvFTJmBiC5Fswnb_lg2siAOwu-BvU_UFhyiGzyrGhq82An5q4hO_OmzV2nVMLMmCzcQCTkqz5BBbkrVsDgdNhsBaVAM1o4ko_HY0VESeNmBOpuGEIVEV7PypC9D7MH4RE8OrM2AMmAinaW2P0fV_AA351pRopKgarZb-Firiuw42HTuYDBaxXfD8EnphoE0QuBi-ZK1YGQHDau6BQAZkQWTZt2NxBqhtlxcy3Xipfwx-5oHsz6KKFQA5W-C7aA_hTX8X9YEpJZtLzSU_uV-EfAPFcj9-sVsw_Cc8M0vJ8q6QXw0KE4l-5OuNpF-Rk2ww7AIXWTygqBntewFryTY31za9WFxg-LKMMBArTS8sYuSRioRJtzw1w9ymqyNG2yjjGEC19G1RpO1W_GcYCn2CIzWg2LwVr0dsMmdDr9SjuadSTdc_5NcThQiaEz5PA7qkXDJGXYE8v4YBIj7Oy-OlHd1r3Qidm0-OMIIPHkDbOAVaMBa4YePoDyFeHxTUQHNoar-Q3q10870uEt0q4wOlVbklnrBKoqJLxIjoj-wwRH4T8Yjz13gGrSal4j383zQOy1ExqG6RHl_xVbclH1OKqn_fX0As0PyVPrSKg_Z5HRj6t7NZ75csOz7dtKsxAE1NG5MCS4rNWZAaNFk9LonWN3l3W962e48jZxvWQbwMIIG7DCCBNSgAwIBAgITMwAAA9TNmGZQ0JUydwAAAAAD1DANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjE2MDQGA1UEAxMtTWljcm9zb2Z0IFRQTSBSb290IENlcnRpZmljYXRlIEF1dGhvcml0eSAyMDE0MB4XDTIxMDYwMzE3NTEwNVoXDTI3MDYwMzE3NTEwNVowQjFAMD4GA1UEAxM3RVVTLUlOVEMtS0VZSUQtQjA2NkQ5Njk3RjVEM0EwN0I0MjVDMTBGNTg3Q0NFRUNGMTZGRkU1ODCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMe8XHbaqGYc0qdWqeJPZxStUBxEXPtjPwsrzGxuGHHOaBbtQwIWtDXRQ6QS98gE68iI7qOQYS5fNVAmjegKanXtGS31txkgWwD_IzPraIXslV8yXbiY13d8TDJd6xAyzTmb8HP3LSPlpoQQfd4zF_nsljjowRH2TUU5rUn2mAKksfjNDwIq5JgjaKuNtD5XehZ0qw7Lngu83-pRECbsiduhvSbnBp7xiulClPyAw6gMOhoGNVvTkq4V38lM6NMrGD6cQCJcolc8X4rXqsaILnLeDU_ixaKZ4SLTF4xN4bTm3-Wm38tTVCHnRI5uWGN89ML02IDAesHEviwkSnZKld9LRjISVWR0rA-0O5Cup9CEvTCife_4jurIbCv7XlasiFSdhgB0rFzOiFQGMIiZUGXKI1SRbyRNbmk5t-S4nqLPL2Dba3KaSC56q6yT4bftDukf-tyf-O7oktmEF8zieca4WiKWgA3jvX25FJbqHVMdDER17hUwXDPEW0sjCCisxK66iN6XF0IXRlO66DsqimwGK-dhR5tlpGOUyYEPejmH-zbzGTy7jSymdM4Lr1Ux-iStwXnkfPg7ewTDfKW03GKEiuAngheTbPj05tXGUFkxtFWABuNRpdBg_FQia8jiG0fF5VUBMP2AboFInkBKMS9jhC0xY_lOGebRgdWtVRL3AgMBAAGjggGOMIIBijAOBgNVHQ8BAf8EBAMCAoQwGwYDVR0lBBQwEgYJKwYBBAGCNxUkBgVngQUIAzAWBgNVHSAEDzANMAsGCSsGAQQBgjcVHzASBgNVHRMBAf8ECDAGAQH_AgEAMB0GA1UdDgQWBBRoBOGp9mFOiizLAxydAA6hn_dogzAfBgNVHSMEGDAWgBR6jArOL0hiF-KU0a5VwVLscXSkVjBwBgNVHR8EaTBnMGWgY6Bhhl9odHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpb3BzL2NybC9NaWNyb3NvZnQlMjBUUE0lMjBSb290JTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMjAyMDE0LmNybDB9BggrBgEFBQcBAQRxMG8wbQYIKwYBBQUHMAKGYWh0dHA6Ly93d3cubWljcm9zb2Z0LmNvbS9wa2lvcHMvY2VydHMvTWljcm9zb2Z0JTIwVFBNJTIwUm9vdCUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTIwMjAxNC5jcnQwDQYJKoZIhvcNAQELBQADggIBAIn2-e6yks9tusjR0XWTZzZDq7H_Il9qy3C8wTuk4D_ZUahpvXlXuU21SMQH6gWOr07AlHV5Flp-LPBRrk7Ray-0gyNIM-Q8GellqBG67f04ReF8xaQYO_ZcgVupcRwhyjuaLgwqjcBvjlw_jXbONLdrgViWUKi3nADu-xsI0Qy5-E_UFbJpa8oj9CfyNMzK-6Uku5B1uj9HdFxWx65dO4IUURp-eUjfjoXdFcuxkNiA39-mLNmyF6IWuZnJzkSqtDM2MMk_WNGEFa3HmcWs8X_ln7pxaGTY7q0ettSD8hz-bOvhr7EG0cJh_fNky8e9tf9UJMnXpP3_PGuYBMxO-a4P-LciisLF3DtveR9T-Ut2oVA4hTjD6aL6sL-rbarfClQLGlJ1JdD7lGlZyXKjU25-VCYLInkjXfNfyWIJX_QtPG5QYIU6m9H2wTFZeTXJ5MrFF7UFWIo3lkPa0zlywXRaW7U4ivV0PAL6mgyK_y1DsPisaD4Wh64h4DDnhxjli6o3WF6oEn2FGgVT2K_LXeK57KnpNWHmfzvftStYTb9mQkJf-s2yih_GSP9AzI0pj-43ZGeZYjDG39PQfXYMcLcfpz_DF41FIVhTfLmm15yaPtLQDvQSvQKjUczG13QH_cGlqhDHVuZrlAVXgych0XaFDtFR2k7LBIzC6_UovXLGZ3B1YkFyZWFYdgAjAAsABAByACCd_8vzbDg65pn7mGjcbcuJ1xU4hL4oA5IsEkFYv60irgAQABAAAwAQACBsTUhywouePhMvxbU9zymNAUYS2NJp3_gYHzV1zw-EGwAgY3g5px8tUzHqsFnhEmEMScFvS57-vvH_haMt5LUNqrRoY2VydEluZm9Yof9UQ0eAFwAiAAuwGNyIXvjlDLNOMMwWZu1k7RVxifo1zBisMyQQ2psrjQAUpTKUiFtQH2XGSBzcFoXEiaKqGC4AAAAANs38ior_OqNg8HUJAVBjq9YNxp3fACIAC_WBvzP7tjA4pJblKmgt3zOaDFC7IynkyPhd-f5hGA4-ACIAC59Wx8z7ydNJKWUEOSERfeb7FaXxsiWdT8ZvUPdExerOaGF1dGhEYXRhWKQH3xy-VWDSlviIV2mnLTJaBNtsINg_01svvRfNwzbM3kUAAAAACJhwWMrcS4G24TDeUNy-lgAgAS2zpcqF6j7z3xTekAzCckR4dD61Gaqar5wRm1eJc-qlAQIDJiABIVggbE1IcsKLnj4TL8W1Pc8pjQFGEtjSad_4GB81dc8PhBsiWCBjeDmnHy1TMeqwWeESYQxJwW9Lnv6-8f-Foy3ktQ2qtA
Historically speaking, libfido2 has positioned itself slightly more towards CTAP than WebAuthn
Now I understand why libfido lacks options like verifying the certificate requirements, verifying certificate-chain, etc, :) But I dont see any other library written in C/C++ to do RP's role of webauthn.
Am still evaluating how libfido fares against different hardware keys and platform authenticators to understand whether the algorithm support from it to verify attestation is good enough.
Got the TPM attestation and registration details from here, MasterKale/SimpleWebAuthn#238
I am running into the same issue. When using a Feitian Biopass USB FIDO2 token, the attestation statement contains two certificates:
- an intermediate certificate (subject=C=US, O=Feitian Technologies, CN=Feitian FIDO CA 01)
- the attestation certificate (subject=C=US, O=Feitian Technologies, OU=Authenticator Attestation, CN=FT BioPass FIDO2 USB)
However, when retrieving certificates using fido_cred_x5c_ptr(), only the attestation certificate is returned.
This means that attestation validation is not possible using libfido2, as there is no way to complete the CA chain up to its MDS root.
Also note that OpenSSH relies on libfido2, and this issue makes attestations saved during key generation impossible to verify whenever there is an intermediate certificate present in the attestation statement.
For reference, an example statement containing an intermediate certificate returned from fido_cred_attstmt_ptr() is here:
o2NhbGcmY3NpZ1hGMEQCIHWaq/75jQK/DM1PU/P2qVXK2/f0z7lMiEl6fG85SMz9AiAR1ZqN9+VzPwXx
gTRjMuVHQp5lKv6f0twFGn/cTfyT5WN4NWOCWQJHMIICQzCCAeigAwIBAgIQHfK1WlHcS2iFo9meaX/t
FDAKBggqhkjOPQQDAjBJMQswCQYDVQQGEwJVUzEdMBsGA1UECgwURmVpdGlhbiBUZWNobm9sb2dpZXMx
GzAZBgNVBAMMEkZlaXRpYW4gRklETyBDQSAwMTAgFw0xODA2MjEwMDAwMDBaGA8yMDMzMDYyMDIzNTk1
OVowbzELMAkGA1UEBhMCVVMxHTAbBgNVBAoMFEZlaXRpYW4gVGVjaG5vbG9naWVzMSIwIAYDVQQLDBlB
dXRoZW50aWNhdG9yIEF0dGVzdGF0aW9uMR0wGwYDVQQDDBRGVCBCaW9QYXNzIEZJRE8yIFVTQjBZMBMG
ByqGSM49AgEGCCqGSM49AwEHA0IABGBQ+G7hJNkWhdUzIUHRL+5Nnhdd2wSDHnKtilv9DYLPng1Fa7Fd
gaitdV1tLDonjgXPGB4n6bl2dGuY1ritv0KjgYkwgYYwHQYDVR0OBBYEFAHywrTcuV57hh/bTpnKWJ83
ezP1MB8GA1UdIwQYMBaAFH/slP9KuSNg6BVbjL07RVBUxxwkMAwGA1UdEwEB/wQCMAAwEwYLKwYBBAGC
5RwCAQEEBAMCBSAwIQYLKwYBBAGC5RwBAQQEEgQQdwEL1yEqT8myNtLKXp1AhDAKBggqhkjOPQQDAgNJ
ADBGAiEAjQ4/TrF/qK8LZ8HkMmmCUne0uQIE4uI6mf53ffW//W0CIQD73wYOoPrL7heIbcga7fm1kjSp
8jzUhcwLdqaEtws5ZFkB/jCCAfowggGgoAMCAQICEBgVK0G3Q65ttBWZw7F9ggYwCgYIKoZIzj0EAwIw
SzELMAkGA1UEBhMCVVMxHTAbBgNVBAoMFEZlaXRpYW4gVGVjaG5vbG9naWVzMR0wGwYDVQQDDBRGZWl0
aWFuIEZJRE8gUm9vdCBDQTAgFw0xODA1MjAwMDAwMDBaGA8yMDM4MDUxOTIzNTk1OVowSTELMAkGA1UE
BhMCVVMxHTAbBgNVBAoMFEZlaXRpYW4gVGVjaG5vbG9naWVzMRswGQYDVQQDDBJGZWl0aWFuIEZJRE8g
Q0EgMDEwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT4FqBDgshRGexE1xX9tsYzp9gSnf0x82wo8Lhy
eSiTuU26p/+/4GE1LKxeaHIoMTMOchpCCFPwYBwoxqGsoVs7o2YwZDAdBgNVHQ4EFgQUf+yU/0q5I2Do
FVuMvTtFUFTHHCQwHwYDVR0jBBgwFoAUS72HJhGtHInPBFi+cNIIjGsWI7cwEgYDVR0TAQH/BAgwBgEB
/wIBADAOBgNVHQ8BAf8EBAMCAQYwCgYIKoZIzj0EAwIDSAAwRQIhANaf5XbvM5wWFXjgaFrb1qcv/Ahd
6FkGHoykOJVmNReDAiAd5wwvj2oYXU7ElQGtM4kgTNDDonmAKOSthi/Dx6VnFGcU
Have submitted a PR #781 to store all the certificates in x5c. Hopefully that will be considered for merging after corrections.
This should now be resolved, thank you very much for your contributions! Apologies for the slight delays.