Closed robplee closed 1 year ago
Definitely interest from our side.
@robplee thank you for you patience and bringing this to my attention :pray: I have been under a lot of pressure from duties elsewhere.
a) there was interest in lints for SMIME certificates issued under any of the mailbox/organisation/sponsor-legacy/multipurpose/strict policy OIDs? (For the record, I am happy to participate in writing/reviewing new lints for this)
I, at least, would be amenable to this as I believe that it would be consistent with the charter and usecases of ZLint.
b) if there was interest it might help to have a plan for where we are going to add them (I propose lints/cabf_smime_br as the new location)
Indeed reasonable at face value.
c) do we need an issue where we can make a checklist of the new lints we want? (It could be this one and I can do a bit of BR parsing into a checklist if there is positive thoughts about having these lints)
A short list would definitely be a good idea and would be appreciated (similar to a stabilization checklist or an "epic" in tracking tools such as Jira). I can set this tracking up, however I would certainly appreciate help in actually populating the short list since I am not immersed in the ecosystem on a daily, FTE, basis.
d) if there is an effort to add some new SMIME BR lints added can we expect a new zlint release before the new rules come into force in September? I'd help with this but I don't have the permissions so this is probably just a plea for some
Indeed I believe that this would be one of the less invasive changes/proposals recently made (a merged infra for CRLs and a proposal for pre-sign linting). From what I can immediately see, I don't think that we're going to require too much more infrastructure (depending on)...
certificates issued under any of the mailbox/organisation/sponsor-legacy/multipurpose/strict policy OIDs?
A lot of the "easiness" of this work is likely predicated on this notion - that there is a single, or small combination, of facts embedded within a certificate that says
The is an SMIME cert, do not even try to run this against RFC 5280
We already do this within the linting infra in order to skip out on CABF/BR lints for certs that are not for server auth.
https://github.com/zmap/zlint/blob/997ad5143216f4a3f461545f277be7e20bdcb557/v3/lint/base.go#L221
...so I do not find ot to be unprecedented nor invasive.
Hi all, thanks for the positive responses. I guess we can probably close this issue and assume the result of this discussion is a "Let's get cracking".
This list is by no means conclusive but here's a bunch of lints we might want from a quick scan through section 7 of the SMIME BRs that should at least get us started:
I've finished my first scan through of the particularly zlint-y section 7 and as the list contains 40 potential new-lints I'm going to stop there as that seems enough to be getting on with!
I think this has been a quick open and shut issue so I'm going to close it in favour of the massive to do list issue I've just opened as #712.
Last thing to add in response to @christopher-henderson 's question/comment/concern about applicability of the lints. I think we can do a similar step as in the CABF BR lints. The SMIME BRs open with a comment saying :
An S/MIME Certificate for the purposes of this document can be identified by the existence of an Extended Key Usage (EKU) for id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4)
So I think we can have a similar if source==SMIMEBRs and !util.IsEmailProtectionCert(cert)
line as we do currently for the server cert BRs which I think answers that concern? We can discuss further via the first SMIME BR lint PR in a second I guess!
Hi all,
As there are going to be SMIME BRs coming into force in September I was wondering if: a) there was interest in lints for SMIME certificates issued under any of the mailbox/organisation/sponsor-legacy/multipurpose/strict policy OIDs? (For the record, I am happy to participate in writing/reviewing new lints for this) b) if there was interest it might help to have a plan for where we are going to add them (I propose lints/cabf_smime_br as the new location) c) do we need an issue where we can make a checklist of the new lints we want? (It could be this one and I can do a bit of BR parsing into a checklist if there is positive thoughts about having these lints) d) if there is an effort to add some new SMIME BR lints added can we expect a new zlint release before the new rules come into force in September? I'd help with this but I don't have the permissions so this is probably just a plea for some @christopher-henderson time.