-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
crypto/x509: add a PKITS test #45857
Comments
Hello I have started with this and just want to know if I'm on the right track before carrying on with CRL tests I understand that you are looking for a list of unsupported tests/functionality and I am assuming these will be fixed/catered for on a case by case basis ? Are you also looking for a PKITS test in a golang test case format ? Ran the tests for 4.1.1 through to 4.5.8 for now. Here are the observations for test failures: 4.1.4
fails in x509.go 4.1.5
Failed parsing of DSAParametersInheritedCACert.crt in
paramsData and params are nil 4.1.6
fails in x509.go because only rsa, ecdsa and ed25519 public keys are supported 4.3.3,4,5,10,11
in cert_pool.go
The raw issuer does not match raw subject because of spaces, capitilization.
also in verify.go
Conforming implementations MUST use the LDAP StringPrep profile I also suspect that some tests pass (and should) but only a subset of checks are done For example: test 4.3.6 [Verifying Name Chaining : Valid Name Chaining UIDs Test6]: passed. The subject and issuer uids are catered for in the asn.1 certificate struct but not ever copied over to Certificate in the parseCertificate function in asn.1 certificate struct
Is it ok for me to complete the test analysis like the above, package it in a better format when complete or did you have another approach in mind? |
Hello @dandare100, thank you for giving this a spin! I encourage you to send a small CL/PR with the tests you have so far, so we can discuss the approach without reviewing a massive change set. The test should be a standard test in a In general, it's expected there will be test cases that PKITS calls valid but we reject. We tend to be stricter than the standard where we can afford it. For those, we want to clearly document in the test what is going on, and check that they fail. What we don't want is the opposite, invalid chains that we accept. |
Change https://golang.org/cl/339292 mentions this issue: |
Hello. |
Change https://go.dev/cl/618415 mentions this issue: |
This vendors the vectors (generated using [0], derived from the BoringSSL script which generates their test headers) and all of the certs, but only runs the subset of the suite that is focused on policy validation. In the future we may want to run more of the suite, since it is focused on path validation, not path building, the way it interacts with our hybrid path builder/validator is kind of complicated. Updates #68484 Updates #45857 [0] https://gist.github.com/rolandshoemaker/a4efa9d65c2cef74a46ea40f47f0729e Change-Id: Ic04323dcd76aa5cbd6372c8cb1c44ccb91ccbca4 Reviewed-on: https://go-review.googlesource.com/c/go/+/618415 Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
PKITS is a large X.509 test suite. Some of the stuff in there we don't actually support, but it would be good to run through it all and explicitly mark the things we don't support.
The text was updated successfully, but these errors were encountered: