zlint
zlint copied to clipboard
zmap
How to implement LINTs for the upcoming SMIME BRGs?
Dear maintainers!
Do you have a preferred way, how to organize the lints for the upcoming SMIME BRGs? I would create a new folder cabf_smime within the `v2/lints' folder. Do you share this opinion?
And how do we want to handle the situation, that many of those lints will be duplicates of the cabf_br lints? Shall we copy those lints or do we want to somehow 'link' them?
What criteria would be make these lints applicable? Would they not run the cabf_br lints at all if they had the right EKU? This is a good question overall since new cert types (looking at you, Qualified certs) don't necessarily apply to cross-sectional EKU baseline requirements like BR (OV)->EVGs (EV).
So, as it stands right now, the SMCWG (S/MIME) is wholly independent of the SCWG (TLS); thus, the requirements are best described as a "fork" (with no common ancestor), even if they're identical. When you think about S/MIME and TLS being independent hierarchies, this is actually quite good and makes sense. The question of having some common "base" requirement is... complex and complicated and we shouldn't use this issue to debate it ;)
So as a practical level, I think the question is whether or not the ZLint structure should align with how the CA/B Forum is structuring things (naively, I'd say yes; which is to say, copy), and what to do if the CA/B Forum ever creates a third "base" document (in which case, if such a day ever comes about, we could consider adopting that).
In a world of purpose-segmented roots, this isn't so bad - you'd only ever run "one" of these suites per root. However, I suspect some CAs are still slow to modernize, and thus will want to run both TLS and S/MIME on the same PKI hierarchy. In that case, the question is, I think whether it makes sense to use a "common" lint for both TLS and S/MIME (with no restriction on CheckApplies), or whether it makes sense to use two lints (as I suggest above), with separate CheckApplies. Because they're separate documents, and increasingly likely to be subject to separate supervision and audit regimes, I'm more supportive of the "copy-and-duplicate" vs trying to share.
I think that makes a lot of sense. In this case, the common base document would be the RFCs, right? Would these separate linting hierarchies imply compliance with RFCs? Is it something that a user would have to specify? Or should it be managed through the CheckApplies function within the Lint interface for each set of lints? I assume that would require a pretty extensive change across the corpus of existing BR lints.
I'm not sure I follow?
Like, the S/MIME WG could decide to reject RFC 5280 and adopt ITU-T's (incompatible) X.509, for example, in which case, S/MIME wouldn't run RFC lints at all.
What I'm suggesting is the CA should be able to decide whether to run cabf_br, cabf_smime, or rfc, each independent of each other.
Are you asking whether https://github.com/zmap/zlint/blob/master/v3/lint/base.go#L86 should be moved into cabf_br for each lint?
Like, the S/MIME WG could decide to reject RFC 5280 and adopt ITU-T's (incompatible) X.509, for example, in which case, S/MIME wouldn't run RFC lints at all.
Ohhh, ok. I see what you're saying here. The Working Group will decide what a valid cert hierarchy should look like. 👍
What I'm suggesting is the CA should be able to decide whether to run cabf_br, cabf_smime, or rfc, each independent of each other.
I agree with this and think we've moved that direction. I was wondering about the default behavior when a cert with the SMIME related EKU is passed to zlint.
Are you asking whether https://github.com/zmap/zlint/blob/master/v3/lint/base.go#L86 should be moved into cabf_br for each lint?
Tangentially, yes.
I was wondering about the default behavior when a cert with the SMIME related EKU is passed to zlint.
Are you asking whether https://github.com/zmap/zlint/blob/master/v3/lint/base.go#L86 should be moved into cabf_br for each lint?
Tangentially, yes.
Gotcha. Yeah, I think it may still be too early as the SMCWG works on their draft, and AIUI based on today's CABF Forum Teleconference, are working through this exact question themselves.
My own, weakly-held preference, is that if/as ZLint supports other types of certificates (S/MIME, for example), it probably makes sense to have each lint test in their CheckApplies whether or not it applies (e.g. each lint can test for the S/MIME EKU, if that's what the SMCWG adopts). For things like the OCSP Delegated Signer issue, for example, that would exist in cabf_br but not test for that EKU. It would be the CA's responsibility to enable/disable lints for their hierarchy, or sub-portions of it. That does create the risk of the CA forgetting to enable some categories for their CA / disabling the wrong categories, but that allows individual Lints the maximum flexibility to signal issues.
Put more concretely (and, again, weakly held/easily convinced otherwise):
- If/as the SMCWG copies SCWG requirements in to their (independent) doc, copy lints from
cabf_brtocabf_smimeand- Update the
CheckAppliesto test for S/MIME EKU
- Update the
- Independently/in parallel, remove that line from
base.goand update the lints incabf_brto add that to theirCheckApplies
However, we can probably defer that until there's a public draft of the SMCWG BRs circulating, to know what direction is being pursued re: policy OIDs.
Do you think we could start a small test balloon in a branch of this repro, where we create a subfolder cabf_smime and copy some of the lints from cabf_br to of which we can assume with reasonable certainty, that they will also be used in the S/MIME BRGs, e.g. the serial number length? If this then turns out to be the way into the future, I would fork that branch and have someone working on it to keep it in sync with what is currently being discussed in the SMCWG.
The background to my question is, that, as you know, we are issuing plenty of S/MIME certificates every day and I would like to start linting for the upcoming S/MIME BRGs as early as possible to detect possible deviations from the S/MIME BRGs as soon as possible and not on the last minute after the S/MIME BRGs are finalized.
I definitely think it's a good idea to make a proposal branch so we can look at what the changes would be and validate that direction as the direction we want to go. If we like it, then I think we still need to decide what the "Default behavior" of a zlint scan is when no particular lint groups are requested. My personal preference would be that we default to regular BR and EVG scanning similar to how we do today, and the SMIME lints would need to be specifically requested. This is kind of where I get lost on approach because I can also see value to always running every lint by default and having the CheckApplies function handle whether the lint is relevant to the cert.
Just to add some weight to what you're saying, we already issue SMIME Class 1 and Class 3 certs so it would definitely be nice to get zlint support for those in as early as possible.
@cardonator @christopher-henderson Do you think one of the maintainers could create such a branch so that we could start working on a PoC?
@RufusJWB certainly, I reckon that all we need is a branch in the repo for forks to open PRs against? As far as content of the branch goes I admit that I'll have to study this thread a bit in order to catch up.
