Aia ca issuers must have http only #852
Conversation
…f the Issuing CA’s certificate; removed unnecessary assertion from older lint.
|
How does or should this lint relate to the existing lint https://github.com/zmap/zlint/blob/26ca0f3bed092ef6e6b34f546f68068ae9d808a1/v3/lints/cabf_smime_br/lint_strict_aia_has_http_only.go ? FYI, I'm assuming the answer is "TLS vs SMIME" but just wanted to clarify that. |
Exactly :) It is the same requirement and the same implementation but only for the caIssuers method. We could just take the SMIME implementation and re-use it (changing citation, description, test certificates, etc.). The checkApplies implementation is then the only change. Still, this might arise the question why not have a "bigger" lint in TLS that checks both methods for HTTP scheme, as the SMIME lint does. My impression is that having small lints with (very) narrow focus is a better choice that allows more flexibility, and especially to align implementation with the specification and changes in the specification. For example, to exaggerate a litlle, we could have a big lint that checks everything associated to authority information access, like presence or not, correct criticality, correct values and so on. But this approach has not been followed in zlint. As a rule of thumb I would say that one sentence (maybe even a subordinate clause?) in a specification with one reserved keyword could be one lint. I would be willing to update the lint to match the SMIME lint (bright focus option) or create a new one for the OCSP URL (narrow focus option). Let us wait what you and other users say on this and then I can start working on this. Best, |
|
I agree with your statement on keeping the lints simple and single purpose, and it was something I questioned in the SMIME lint at least internally (as it also used to have an even larger scope than it does). I think the argument for a single lint is likely simply that the check is dealing with fields in the same "bucket" so to speak, and checking the same rules on those fields. However, I'm not convinced that is a compelling enough argument to have a single lint for both... basically I am torn on it :) |
yes. I just added a new test case. This required a change in the implementation to catch the HTTPS case, if both http and https are a correct match for: "A HTTP URL of the Issuing CA’s certificate." (https://cabforum.org/uploads/CA-Browser-Forum-BR-v2.0.0.pdf, Section 7.1.2.7.7) |
|
I don't believe that https is a valid case for this. We had a similar conversation on the SMIME version of this lint. |
it boils down to whether an https URL falls under "A HTTP URL of the Issuing CA’s certificate.". Would an https URL in a certificate be a violation of the BR requirements? My proposal is that I place an issue at the github repository of CAB Forum for clarification and wait for some feedback there. |
|
FWIW, I got that information from @CBonnell . |
|
Update: https is a violation see: cabforum/servercert#522 and https://lists.cabforum.org/pipermail/servercert-wg/2024-April/004462.html. PR is updated. |
This pull request adds a lint to check that the value of of the id-ad-caIssuers access method is an HTTP URL and outputs an error if the scheme is not http. This work has been made in close cooperation with the D-Trust CA. We would be grateful if you could incorporate this PR in the main project.
Citation (https://cabforum.org/uploads/CA-Browser-Forum-BR-v2.0.0.pdf):
7.1.2.7.7 Subscriber Certificate Authority Information Acces
id-ad-caIssuers
1.3.6.1.5.5.7.48.2 uniformResourceIdentifier
SHOULD
*
A HTTP URL of the Issuing CA’s certificate