Fix a few issues with maa.jwt.verifier.dotnet - #34
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
Scope the expiration bypass so expired UVM signing certificates are not accepted indefinitely.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
Updates the .NET JWT verifier for AMD Turin VCEK roots and expired UVM endorsement certificates.
Changes:
- Adds and registers the AMD Turin trusted root.
- Updates trusted AMD root definitions.
- Adds configurable leaf-expiration handling for UVM endorsements.
- The expiration bypass is too broad and requires a scoped or time-bounded policy.
File summaries
| File | Summary |
|---|---|
maa.jwt.verifier.dotnet/Utilities.cs |
Adds configurable certificate leaf-expiration handling. |
maa.jwt.verifier.dotnet/TrustedValues.cs |
Adds and organizes AMD trusted root keys. |
maa.jwt.verifier.dotnet/Program.cs |
Enables expired-leaf handling for UVM validation; this currently bypasses lifetime checks too broadly. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| // Step 3: Validate full certificate chain (COSE Sign1 Object -> ProtectedHeaders -> x5chain). | ||
| var trustedRoots = new[] { Utils.PemStringToRsa(((CoseSign1.TrustedCertChainSigner)trustAnchor.Signer).CertChain.PemRootCaPublicKey) }; | ||
| if (!Utils.BuildAndValidateCertChain(certificates, trustedRoots, Utils.CertValidationTarget.Root)) | ||
| if (!Utils.BuildAndValidateCertChain(certificates, trustedRoots, Utils.CertValidationTarget.Root, ignoreLeafExpiration: true)) |
There was a problem hiding this comment.
I think this recommendation can be passed on because the sample does not recommend disabling leaf certificate expiration validation. The sample is to demonstrate how to validate a MAA-issued JWT.
Crypto libraries such as OpenSSL (https://docs.openssl.org/master/man3/X509_VERIFY_PARAM_set_flags/) already provide flags that allow consumers to configure validation behavior based on their specific requirements or for testing purposes. Adding this flag provides the same convenience.
Purpose
This PR fixes a couple issues with the maa-jwt-verifier.dotnet app:
Does this introduce a breaking change?
[ ] Yes
[x] No
Pull Request Type
What kind of change does this Pull Request introduce?
How to Test
What to Check
Verify that the final line in the console window is:
Other Information