zlint coverage of the new SMIME BRs

[robplee]

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.

[cardonator]

Definitely interest from our side.

[christopher-henderson]

@robplee thank you for you patience and bringing this to my attention 🙏 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.

zlint/v3/lint/base.go

Line 221 in 997ad51

if l.Source == CABFBaselineRequirements && !util.IsServerAuthCert(cert) {

...so I do not find ot to be unprecedented nor invasive.

[robplee]

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:

1. SMIME certificates SHALL have cRLDistributionPoints (7.1.2.3.b)
2. Strict and Multipurpose SMIME certificates SHALL have the cRLDistributionPoints URI scheme as HTTP others are not permitted (7.1.2.3.b)
3. Strict and Multipurpose SMIME certificate AIA fields: OCSP Responder "When provided, every accessMethod SHALL have the URI scheme HTTP." (7.1.2.3.c.1)
4. Strict and Multipurpose SMIME certificate AIA fields: caIssuers "When provided, every accessMethod SHALL have the URI scheme HTTP." (7.1.2.3.c.1)
5. Key usage, RSA certs, strict policies: prevent all key usages other than digitalSignature, nonRepudiation, keyEncipherment (7.1.2.3.e)
6. Key usage, RSA certs, multipurpose/legacy policies: prevent all key usages other than digitalSignature, nonRepudiation, keyEncipherment and dataEncipherment (7.1.2.3.e)
7. Key usage, EC certs, all: prevent all key usages other than digitalSignature, nonRepudiation, keyAgreement, encipherOnly, decipherOnly (7.1.2.3.e)
8. Key usage, EC certs, all: encipherOnly/decipherOnly are permitted only when keyAgreement is set (7.1.2.3.e)
9. Extended key usage, strict: emailProtection SHALL be present. Other values SHALL NOT BE PRESENT (7.1.2.3.f)
10. Extended key usage, multipurpose/legacy: emailProtection SHALL be present. Other values MAY be present (7.1.2.3.f)
11. Extended key usage, all: serverAuth, codeSigning, timeStamping, anyExtendedKeyUsage SHALL NOT BE PRESENT (7.1.2.3.f)
12. authorityKeyIdentifier, all: SHALL be present, SHALL NOT be critical. keyIdentifier SHALL be present, authorityCertIssuer and authorityCertSerialNumber SHALL NOT be present (7.1.2.3.g)
13. subjectAlternativeName, all: SHALL be present (7.1.2.3.h)
14. subjectAlternativeName, all: SHALL NOT be marked critical unless subject field is empty (7.1.2.3.h)
15. subjectDirectoryAttributes, strict/multipurpose: field is Prohibited (7.1.2.3.j)
16. subjectDirectoryAttributes, legacy: if present, field must not be marked Critical (7.1.2.3.j)
17. qcStatements, all: if present, field must not be marked Critical (7.1.2.3.k)
18. Legal Entity Identifier, mailbox-validated/individual-validated, all generations: is Prohibited (7.1.2.3.l)
19. Legal Entity Identifier, organization-validated, all generations: LEI (1.3.6.1.4.1.52266.1) MAY be present and SHALL NOT be marked critical (7.1.2.3.l)
20. Legal Entity Identifier, sponsor-validated, all generations: LEI (1.3.6.1.4.1.52266.1) or for role (1.3.6.1.4.1.52266.2) MAY be present and SHALL NOT be marked critical (7.1.2.3.l)
21. Adobe Extensions, strict: is Prohibited
22. extensions:subjectAltName all validations, all generations: SHALL be present, SHALL contain at least one GeneralName entry of the following types: Rfc822Name, otherName of type id-on-SmtpUTF8Mailbox (7.1.4.2.1)
23. subject:commonName, mailbox-validated: if present, this attribute SHALL contain... [a] Mailbox Address (7.1.4.2.2.a)
24. subject:commonName, organization-validated: if present, this attribute SHALL contain... subject:organizationName or [a] Mailbox Address (7.1.4.2.2.a)
25. subject:commonName, sponsor-validated/individual-validated: if present, this attribute SHALL contain... Personal Name, subject:pseudonym, or [a] Mailbox Address. PersonalName SHOULD be presented as subject:givenName and/or subject:surname (7.1.4.2.2.a)
26. subject:commonName, all: if present, the Mailbox Address SHALL contain a rfc822Name or otherName value of type id-on-smtpUTF8Mailbox from extensions:subjectAltName (7.1.4.2.2.a)
27. subject:givenName, subject:surname, subject:pseudonym: The subject:givenName and/or subject:surname SHALL NOT be present if the subject:pseudonym is present. (7.1.4.2.2.e/f)
28. subject:emailAddress, all: if present, the subject:emailAddress SHALL contain a single Mailbox Address. (7.1.4.2.2.h)
29. subject:countryName, all: SHALL contain the two letter ISO country code or 'XX' if no ISO 3166-1 code has been assigned (7.1.4.2.2.n)
30. subject DN attributes for mailbox-validated profile (7.1.4.2.3)
31. subject DN attributes for organization-validated profile - Legacy (7.1.4.2.4)
32. subject DN attributes for organization-validated profile - Multipurpose (7.1.4.2.4)
33. subject DN attributes for organization-validated profile - Strict (7.1.4.2.4)
34. subject DN attributes for sponsor-validated profile - Legacy (7.1.4.2.5)
35. subject DN attributes for sponsor-validated profile - Multipurpose (7.1.4.2.5)
36. subject DN attributes for sponsor-validated profile - Strict (7.1.4.2.5)
37. subject DN attributes for sponsor-validated profile - Multipurpose/Strict: profiles SHALL include either subject:givenName and/or subject:surname, or the subject:pseudonym (7.1.4.2.5)
38. subject DN attributes for individual-validated profile - Legacy (7.1.4.2.6)
39. subject DN attributes for individual-validated profile - Multipurpose (7.1.4.2.6)
40. subject DN attributes for individual-validated profile - Strict (7.1.4.2.6)

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!

[robplee]

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!