Lint for CABF SMIME 7.1.4.2.2.a and 7.1.4.2.2.e - If present, Subject name fields must not contain placeholder data

[Marco-Fe]

We recently noticed that zlint seems not to check Subject Name fields like givenname, surname and common name for placeholder data like ".", "-" or " " (space). As these fields should contain the natural person's name, if present, these placeholders/Metadata are not allowed for Subject name fields. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1902042

Having a lint that checks for these characters would also help to enforce the SMIME requirement 7.1.4.2.2.e:
"Subjects with a single legal name SHALL provide the name in the subject:surname attribute."

After having a look at the implemented lints we found a similar one for source CABF BR that seems to already implement this check:

zlint/v3/lints/cabf_br/lint_subject_contains_noninformational_value.go

Line 40 in 04d863f

Description: "Subject name fields must not contain '.','-',' ' or any other indication that the field has been omitted",

However this lint does not seem to be run when checking S/MIME certificates. The question would now be if this lint could also be reused for this case.

[vanbroup]

@christopher-henderson We have seen some TLS BRs lints being duplicated for S/MIME recently, is this what should happen here and is this really the best approach?

This might cause quite a bit of duplication between lints for TLS, S/MIME, Code-Signing, ETSI, VMC, etc.

[cardonator]

I don't think there has been much conversation about creating a set of common criteria lints that apply across multiple regulatory docs and how that would work. As of now, the duplication is preferred to keep related lints bundled together in the folder structure. I would recommend copying that lint over to the SMIME lints.

[christopher-henderson]

Without reading too much into this particular case, @cardonator is correct in that we have historically avoided deduplication.

It is relatively common for two governing bodies to declare similar (if not precisely the same) requirements. It certainly seems as though DRY would be a useful approach here, however it can actually make maintenance matters far more complicated.

---

Consider that case where we have a shared lint between RFC 5280 and CABF/BRs. CABF then releases a new ballot that slightly modifies the requirement.

Steps Today

• Set an ineffective date on the previous CABF lint.
• Create a new CABF lint that is effective on the new ballot.
• Leave the RFC lint alone.

Steps With Shared Lints

• Cross reference against RFC 5280.
• Find the divergence, if any.
• Mark the shared lint as ineffective on the ballot date.
• Copy the shared lint, as-is, to the RFC directory.
• Write a new lint in CABF that is effective on the ballot date with the updated requirement.

---

Aside from simply being more steps, it is a significantly more complicated workflow that can easily lead to errors in implementing the language correctly. Specifically, Find the divergence, if any. can (and has) lead to endless discussion and yak shaving.

So while copy-pasting is not the best coding practice in the world, treating these shared requirements as mere coincidences has made life generally easier in the repo.