Qc type web also smime#919
Conversation
| LintMetadata: lint.LintMetadata{ | ||
| Name: "w_qcstatem_qctype_web", | ||
| Description: "Checks that a QC Statement of the type Id-etsi-qcs-QcType features at least the type IdEtsiQcsQctWeb", | ||
| Name: "e_qcstatem_qctype_web_esign_eseal", |
There was a problem hiding this comment.
I believe that I would consider the name of the lint to actually be in the public interface of ZLint. Library usages pull up individual lints by name. Additionally, downstream automation may be parsing ZLint's JSON output and looking for a particular name
Now, the only reason I can think someone would do that is if the CA had a history of failing that particular lint, and thus have a particular interest in referring to it specifically. Regardless, however much more accurate the new name may be, I don't think the risk of breaking downstream automation is quite worth it.
| Name: "e_qcstatem_qctype_web_esign_eseal", | |
| Name: "e_qcstatem_qctype_web, |
| Name: "w_qcstatem_qctype_web", | ||
| Description: "Checks that a QC Statement of the type Id-etsi-qcs-QcType features at least the type IdEtsiQcsQctWeb", | ||
| Name: "e_qcstatem_qctype_web_esign_eseal", | ||
| Description: "Checks that a QC Statement of the type Id-etsi-qcs-QcType features at least the type IdEtsiQcsQctWeb, in case of a server certificate, or it features one of the types IdEtsiQcsQctEsign or IdEtsiQcsQctEseal, in case of an S/MIME certificate.", |
There was a problem hiding this comment.
One clause applies to server certificates and the other clause refers to S/MIME certificates. I can't help but feel that original lint (for server certificates) should be left as-is and that a new lint should be introduced that focuses on S/MIME.
Thoughts? Did you have a particular reason extending this lint rather than creating a new one?
There was a problem hiding this comment.
One clause applies to server certificates and the other clause refers to S/MIME certificates. I can't help but feel that original lint (for server certificates) should be left as-is and that a new lint should be introduced that focuses on S/MIME.
Thoughts? Did you have a particular reason extending this lint rather than creating a new one?
No, actually not. I believe the main reason was that the original lint mixed warnings and errors. The warning was issued because the non-positive path was not considered an error, as other ETSI-QC certificates could have uses beyond the web. Having two separate lints feels better to me as well. Still, the original lint needs some adjustments, specifically, it should be refactored to produce only errors and not mix warnings and errors. I will start working on this.
There was a problem hiding this comment.
I have incorporated the comments. Now, two distinct lints exist, with only minor refactoring done to the first one. The integration tests do not run, but I am not sure whether this is something I can fix.
christopher-henderson
left a comment
christopher-henderson
left a comment
There was a problem hiding this comment.
Ah, I see that the bits rotted. I went out to the store and got us some fresh bits, so the integration tests are good again.
|
|
||
| /* | ||
| * ZLint Copyright 2024 Regents of the University of Michigan | ||
| * ZLint Copyright 2025 Regents of the University of Michigan |
There was a problem hiding this comment.
Ah. Good point. I should do the annual +10000/-10000.
3 participants
This lint was implemented before the S/MIME BRs were introduced. This PR considers S/MIME certificates. One change is that it checks that IdEtsiQcsQctWeb must be present only when the certificate is a server certificate. A second change is that it checks that either IdEtsiQcsQctEsign (natural persons) or IdEtsiQcsQctEseal (legal persons) must be present when the certificate is an S/MIME one. Additionally, the warning has been replaced with an error, as having both warnings and errors in the same lint is not considered good practice.