-
Notifications
You must be signed in to change notification settings - Fork 105
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
ISSUE: Time Stamping certificates with false warning results #602
Comments
@sandorszoke Thank you for the detailed description! 🙇 Minor note: In the future I think we would prefer if you can keep to one problem per issue instead of describing two problems in one. It makes the follow-up discussion easier :-) Problem 1
Problem 2I think this is a case where ZLint's use-case has always been certificates in the web PKI and you're seeing a mismatch using it with another domain. I don't think we should add logic to our existing lints for this and instead you should exclude the lints that aren't appropriate to your context instead of using the defaults. If the profile support in #595 lands there might be a future where we can do some of that work as a community with a custom profile but I'm a little bit hesitant to see the scope of the project creep. There's lots of work for a small number of people just sticking to the web PKI. If you're running zlint -excludeNames="w_ct_sct_policy_count_unsatisfied" ... If you're using ZLint programmatically you'll want something like: registry, _ := lint.GlobalRegistry().Filter(lint.FilterOptions{
ExcludeNames: []string{"w_ct_sct_policy_count_unsatisfied"},
})
zlintResultSet := zlint.LintCertificateEx(parsed, registry) |
You could also exclude lints from specific sources (e.g., Apple Root Store Program and Baseline requirements). This is likely easier than trying to exclude specific named lints. |
@cpu with regard to #595 I am also cooking up some code that should allow for lints to accept arbitrary contexts that contain information that is out-of-band of the certificate itself [e_some_lint]
the_stock_market_was_up_that_year = true struct eSomeLint {
theStockMarketWasUpThatYear bool
}
func (e *eSomeLint) Lint(cert *x509.Certificatge) *lint.LintResult {
if !e.theStockMarketWasUpThatYear {
return &lint.LintResult{Status: lint.Error, Details: "oh no!"}
}
return &lint.LintResult{Status: lint.Pass}
} Of course there are details to hammer out (not the least of which are global configurables that are easy to maintain without being dynamic and complications arising from runs of ZLint having global state which does not work well for unit tests). But it should help out with issues like this. |
Certificates with potential issues
As part of a wider test, we checked several of our Time Stamping certificates with Zlint ver.3.1.0 and we could identify two potential issues with the following certificates:
Only a few of them are available through crt.sh, but the issue is the same with all of them.
The summarized result of the zlint tests
The results of the zlint tests are sligthly different for the different TSA certificates, but they all contain the following problematic information:
The use of Qualified certificate statements
All tested Time Stamping certificates contain the QCStatements extension in accordance with the following ETSI standard:
ETSI EN 319 412-5 V2.3.1 (2020-04)
4 Qualified certificate statements
"1.3.6.1.5.5.7.1.3 QCStatements" extension includes among others the following values:
All these certificates are qualified certificates for electronic seals in accordance with Regulation (EU) No 910/2014.
They all contain the "Time Stamping" EKU, so they are special seal certificates dedicated to issuing time stamps.
PROBLEM I., WARNING - "w_qcstatem_qctype_web"
We checked the scope of the lint "w_qcstatem_qctype_web" on GitHub:
The zlint documentation provides the following description regarding this lint:
Our findings
The citation refers to an outdated version of the ETSI standard, the current version is:
If I understand the source code properly, this lint is dedicated only to verifying the TLS certificates, and the extension "id-etsi-qcs-QcType", if exists, should contain the following value:
In our Time Stamping certificates this assumption is not correct, so this lint should return with the value "Not Applicable".
Our proposal
If you agree with our interpretation we suggest to run this lint only in case of an SSL/TLS subscriber certificate.
In case of any other certificate type ZLint should return with an "NA" output.
PROBLEM II., INFO - "w_ct_sct_policy_count_unsatisfied"
ZLint raised this issue with a lower weight, but the source of the problem can be the same as in case of the previous lint.
We checked the scope of the lint "w_ct_sct_policy_count_unsatisfied" on GitHub:
The ZLint documentation provides the following description regarding this lint:
Our findings
This requirement exists only for TLS certificates as part of the Certificate Transparency.
In the case of any other type of certificates, it should return with the value "Not Applicable".
Our proposal
If you agree with our interpretation we suggest to run this lint only in case of an SSL/TLS subscriber certificate.
In case of any other certificate type ZLint should return with an "NA" output.
General comment/question
Similar problem was raised in #581
The solution would probaly be to identify the type of the analysed certificate more precisely by making deeper tests of the different attributes.
We do not know the structure and operation of ZLint and what is the best way to do it.
The text was updated successfully, but these errors were encountered: