-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add IssuerAuth, MdocAuth, ReaderAuth checks #75
Conversation
6029784
to
10867e6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Preliminary suggestions to improve the code. I think we need a couple of iterations to make this clearer. Since this is very security sensitive code it is really important that it is obvious what it is doing, it is easy to follow, and it is well documented. That way we can have confidence that it is implemented correctly.
To that effect encapsulating code so that we don't have multi-hundred line validation functions, and adding lots of comments would be very welcome.
author Arjen van Veen <[email protected]> 1701187280 +0100 committer Arjen van Veen <[email protected]> 1717744754 +0200 refactor for readability WIP clean up comments and duplicates clean up, add some comments cargo fmt clippy fix fmt assert on tests address pr comments refactor handle_response to return a validated_response, submit parsing and decryption errors under errors support creating a trust_anchor_registry from pem strings Fix x5chain encoding. X5Chain decoding fixes and version checking Improve reader validation code. - Also add a CLI tool for validating issuer certificates. Fix public key parsing Feat/reader auth cn (#79) * rebase onto feat/mdoc-auth * rebase and use mdoc-auth functions * wip experiment with cert building * small clean up * Fix inconsistency. (#78) * validated request improvements --------- Co-authored-by: Jacob <[email protected]> remove duplicate code clippy fix
d43c6c7
to
b1ec197
Compare
Signed-off-by: Ryan Tate <[email protected]>
Co-authored-by: Jacob <[email protected]> Signed-off-by: Ryan Tate <[email protected]>
08b461e
to
8085446
Compare
- Moved and renamed to 'src/presentation/authentication'. - Added doc comments. - Removed 'decryption' and 'parsing' from ResponseAuthenticationOutcome, as these are errors, not part of validating the response.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wrapping up this work, just need a bit of help from @justAnIdentity on identifying these TODOs
* Remove unnecessary TODO regarding 18013-7: work will be underway soon. * Remove unnecessary TODO regarding reader certificate checks - already implemented. * Ensure that all critical extensions are checked and understood.
Refactored the x5chain validation code to help debug an issue with the chain validation. Added an e2e positive test for DS->IACA validation.
"CrlDistributionPoints" | ||
} | ||
|
||
fn validate(&self, extension: &Extension) -> Vec<Error> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% that I'm fully following the entire flow, but I think you should still check here that the CrlDistributionPoint extension is marked as non-critical.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that the critical
flag indicates that the consumer MUST understand the extension, otherwise it should fail the transaction. In these cases, the 18013-5 spec says that these extensions shall not be critical. But from a practical perspective we do understand these extensions, so I don't think it matters whether or not the extension is actually marked as critical. I'm leaning more toward a slightly more permissive implementation in cases where security isn't impacted, rather than strictly enforcing every requirement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you mean. My point of view is that since this is open source, developers may use this to validate their own certificates' iso compliance and this still leaves some room for them to do it incorrectly. Not a hill I'd die on though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. We probably want a "strict" mode and "permissive" mode to allow for that as we've discussed before. I think that's out of the scope of this work, but I'll make sure we have a task that captures this.
} | ||
|
||
fn validate(&self, extension: &Extension) -> Vec<Error> { | ||
let bytes = extension.extn_value.as_bytes(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same here. IAN should never be critical, so you could check here that it's not set as critical.
} | ||
|
||
fn validate(&self, extension: &Extension) -> Vec<Error> { | ||
let bytes = extension.extn_value.as_bytes(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
non-critical check here too
This PR adds support for the mdoc holder to validate the ReaderAuth, and the mdoc reader to validate the mdoc auth and issuer auth.
Remaining outstanding work items: