-
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: lint "e_key_usage_and_extended_key_usage_inconsistent" in technically constrained CA certificates #593
Comments
Thanks @sandorszoke ! I think you're spot on here: the KU/EKU consistency check in the context of RFC 5280 assumes an end-entity certificate, because RFC 5280 only normatively addresses the behaviour of EKUs with respect to end-entity certificates. Despite several efforts of various vendors, representing clear "rough code and (real world) rough consensus", the treatment of EKUs on CA certificates wasn't included as part of RFC 5280. So I think your proposed outcome sounds entirely reasonable, and apologies for missing it during review! Would you like to submit a patch to resolve this, or is the primary goal to raise the issue to the community? |
We do not have any experience with the ZLint source code, so our primary goal was to raise this issue to the community. |
Hi @sandorszoke, thanks for filing this issue (and testing ZLint releases).
Is the question mark here because you're not sure if it was 3.0.0 or 3.1.0 you tested?
This sounds good to me but I think will necessitate splitting the lint. Guidance on adding new lints documents a desire to keep each lint to a single result level. |
Hi @cpu, yes, the question mark means we are not sure which version of Zlint used for the original test. The reason is that the version of Zlint is not indicated in our logs and we could not find how to request the version of Zlint from the installed program. Is there any way to ask the installed version from Zlint? We are absolutely sure that the version used was not 3.1.0 because the output contained only 270 lints and version 3.1.0 uses 274 lints. After realizing this version issue, we upgraded our test environment and ran all tests again. The ver. 3.1.0 does not contain this problematic lint. I checked the guidance and you are right, this issue can only be solved by splitting this lint into CA-lint and not-CA lint. |
Not at the current time, we have an open feature request for this: #519
Great 👍
Certainly doable. I'm not sure I'll have time to implement this myself in the next week or so but will keep it in-mind. |
@sandorszoke While looking into this I realized you can run curl -L https://github.com/zmap/zlint/releases/download/v3.1.0/zlint_3.1.0_Linux_x86_64.tar.gz -o latest.tar.gz 2>/dev/null && \
tar -xvf latest.tar.gz 2>/dev/null && \
zlint_3.1.0-rc1_Linux_x86_64/zlint -h
ZLint version 3.1.0-rc1
<snipped> Clearly that's too subtle (I forgot it was even implemented!) so #598 adds an explicit |
@cpu Thank you for this useful information. -version flag will be also useful to include the version information into each test result. |
PKI Consortium supports zlintPKI Consortium decided to help the improvement of zlint, and as a first step we studied the lint e_key_usage_and_extended_key_usage_inconsistent. We checked the RFC requirements for using KU and EKU, and the correspondig zlint issues: #497 #519 #528 #553 #556 #557 #561 #583 #595 #598 #605 Summary of our main findings
Following this interpretation, we created the logical functions that should be checked in case of the presence of an EKU:
Current statusThe e_key_usage_and_extended_key_usage_inconsistent lint is currently not included in zlint due to the identified problems. The retired lint can be found here: The previous version of this lint checked all the requirements in one lint and could only result a general warning message. Potential issues to be solvedCurrently PKIC suggests the following actions
|
@sandorszoke I like the thorough listing of consistency checks. Different logic for a field in different types of certificates almost always leads to issues in the field so good linting support for this is important and very helpful. |
Resolved by #708 |
Short Summary
As part of a wider test we checked all of our CA certificates by Zlint ver.3.0.0 (?) and we could identify a potential issue with different types of technically constrained CA certificates.
Some of the certificates with this potential issue
The summarized result of the zlint test
Each certificate has the following summarized test result.
The scope of lint "e_key_usage_and_extended_key_usage_inconsistent"
When we tried to find details about this lint we realized that this lint has already been removed from Zlint, at least temporarily.
Some corresponding issues are:
#497
#528
#553
#556
#557
As I see there is no common agreement on this requirement so let me summarize our findings.
Our interpretation
Current cases
Our Subordinate CA certificate contains the CodeSigning EKU but does not contain the digitalSignature KU.
This way it can not be used to sign codes due to a key usage conflict according to RFC 5280.
In our interpretation it is not an error, because we definitely do not want to sign codes with this Subordinate CA certificate. The purpose of having this EKU in the CA certificate is to technically constrain its use only to issue code signing end-entity certificates (EKU chaining).
Our proposal
If you agree with our interpretation we suggest to make difference between the Subordinate CA certificates and end-entity certificates.
The KU - EKU consistency should be checked for both types, but the finding should have different weight.
The text was updated successfully, but these errors were encountered: