conformance 1.7.20 4 #531
conformance 1.7.20 4 #531
Conversation
|
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #531 +/- ##
==========================================
+ Coverage 73.95% 74.79% +0.84%
==========================================
Files 98 102 +4
Lines 2638 2742 +104
Branches 446 464 +18
==========================================
+ Hits 1951 2051 +100
+ Misses 586 582 -4
- Partials 101 109 +8 ☔ View full report in Codecov by Sentry. |
| if (trustPath.Length > 1 && attestationRootCertificates.Any(c => string.Equals(c.Thumbprint, trustPath[^1].Thumbprint, StringComparison.Ordinal))) | ||
| { | ||
| throw new Fido2VerificationException(Fido2ErrorMessages.InvalidCertificateChain); | ||
| } |
There was a problem hiding this comment.
@aseigler Would appreciate your eyes here too, but to me it just looks like we have the addition of above if-block that is more strict than without it.
There was a problem hiding this comment.
@abergs Are we able to reference the rule in https://datatracker.ietf.org/doc/html/rfc5280 that this new condition enforces?
There was a problem hiding this comment.
Perhaps @googyi could help us here?
There was a problem hiding this comment.
TrustAnchor.cs : 32
This exact testcase was fixed with this (conformance tests v1.7.15):
Server-ServerAuthenticatorAttestationResponse-Resp-5 Test server processing "packed" FULL attestation F-10 Send ServerAuthenticatorAttestationResponse with FULL "packed" attestation, with attStmt.x5c containing full chain, and check that server returns an error https://datatracker.ietf.org/doc/html/rfc5280#section-6.1
There was a problem hiding this comment.
@googyi Thanks for chiming in. What part of the datatracker.ietf.org/doc/html/rfc5280#section-6.1 is deciding checking the last entry of the trustpath to root certs?
There was a problem hiding this comment.
I think this 6.1 section was referenced in that testcase, I don't know which part describes this exactly.
This looks almost like that:
"When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of
the prospective certification path."
But I am not sure that this is a self-signed cert.
There was a problem hiding this comment.
6.1 also mentions " A certificate MUST NOT appear more than once in a prospective
certification path." which may be fixed by this? (although in a non-conclusive way)
There was a problem hiding this comment.
It is possible. My goal was not to understand the whole RFC or become an expert in cert validation.
I wanted to reach a state where conformance tests are passed.
So it may be buggy.
|
@aseigler See mentions. If you don't have time too look at them at the moment I might move those changes to a secondary PR wand wait for your review, while still landing some of these fixes. |
abergs
force-pushed
the
conformance-1.7.20-4
branch
from
1de524b to
745bcdb
Compare
TrustAnchor.cs : 32 Server-ServerAuthenticatorAttestationResponse-Resp-5 Test server processing "packed" FULL attestation F-10 Send ServerAuthenticatorAttestationResponse with FULL "packed" attestation, with attStmt.x5c containing full chain, and check that server returns an error https://datatracker.ietf.org/doc/html/rfc5280#section-6.1 AuthenticatorAttestationRawResponse.cs : 18 Server-ServerAuthenticatorAttestationResponse-Resp-1 Test server processing ServerAuthenticatorAttestationResponse structure F-4 Send ServerAuthenticatorAttestationResponse that is missing "type" field and check that server returns an error CredentialCreateOptions.cs : 96 Server-ServerAuthenticatorAttestationResponse-Resp-4 Test server support of the authentication algorithms P-8 Send a valid ServerAuthenticatorAttestationResponse with SELF "packed" attestation, for "ALG_SIGN_RSASSA_PKCSV15_SHA1_RAW" aka "RS1" algorithm, and check that server succeeds Server-ServerAuthenticatorAttestationResponse-Resp-9 Test server processing "tpm" attestation P-2 Send a valid ServerAuthenticatorAttestationResponse with "tpm" attestation for SHA-1, and check that server succeeds CredentialCreateOptions.cs : 210 Server-ServerPublicKeyCredentialCreationOptions-Req-1 Test server generating ServerPublicKeyCredentialCreationOptionsRequest P-1 Get ServerPublicKeyCredentialCreationOptionsResponse, and check that: (a) response MUST contain ... AuthenticationExtensionsClientInputs.cs : 23 public string AppID { private get; set; } Server-ServerPublicKeyCredentialGetOptionsResponse-Req-1 Test server generating ServerPublicKeyCredentialGetOptionsResponse P-1 Get ServerPublicKeyCredentialGetOptionsResponse, and check that: (a) response MUST contain ... AuthenticationExtensionsClientInputs.cs : 44 public bool? UserVerificationMethod { private get; set; } Server-ServerPublicKeyCredentialGetOptionsResponse-Req-1 Test server generating ServerPublicKeyCredentialGetOptionsResponse P-1 Get ServerPublicKeyCredentialGetOptionsResponse, and check that: (a) response MUST contain ... AuthenticatorAssertionResponse.cs : 128 Server-ServerAuthenticatorAssertionResponse-Resp-3 P4,P6,P7 CryptoUtils.cs 64 (trustpath length 1 with exact match in attestation root certs) Server-ServerAuthenticatorAttestationResponse-Resp-5 Test server processing "packed" FULL attestation P-3 Send a valid ServerAuthenticatorAttestationResponse with FULL "packed" attestation that contains batch certificate, that is simply self referenced in the metadata, and check that server succeeds CryptoUtils.cs 105 - X509RevocationMode.Online makes conformance sad Server-ServerAuthenticatorAttestationResponse-Resp-9 Test server processing "tpm" attestation P-1 Send a valid ServerAuthenticatorAttestationResponse with "tpm" attestation for SHA-256, and check that server succeeds‣ P-2 Send a valid ServerAuthenticatorAttestationResponse with "tpm" attestation for SHA-1, and check that server succeeds‣ P-3 Send a valid ServerAuthenticatorAttestationResponse with "tpm" attestation pubArea.nameAlg is not matching algorithm used for generate attested.name, and check that server succeeds TestController.cs tojson -> serialize serialization error
Json serialization fix. (Object type vs ToJson())
Back to 100% conformance. TokenBinding logic readded. AppId: prevent serialization in a nicer way. UV flags are verified differently for conformance testing, otherwise as described in the RFC.
fix azure pipeline's whitespace error + removing unused using
Improve trustanchor test coverage based on codecov report
abergs
force-pushed
the
conformance-1.7.20-4
branch
from
745bcdb to
11121e6
Compare
I'm keeping these around until we've understood if we really can drop them
abergs
force-pushed
the
conformance-1.7.20-4
branch
from
f64fc63 to
dfa6f72
Compare
This is based on #456 and results in a 100% pass on the v1.7.20-4 tool.