Lint for CABF SMIME 7.1.2.3.h - subjectAlternativeName SHOULD NOT be marked critical unless the subject field is an empty sequence

[christopher-henderson]

Resolves #745. Address subjectAlternativeName, all: SHALL NOT be marked critical unless subject field is empty (7.1.2.3.h) from #712.

Note that the SHALL NOT from the original tracker is incorrect. The full text of the section is...

h. subjectAlternativeName (SHALL be present)

This extension SHOULD NOT be marked critical unless the subject field is an empty sequence.

The value of this extension SHALL be encoded as specified in Section 7.1.4.2.1.

[CBonnell]

A few observations:

The SMIME BRs are not introducing any requirements above and beyond the requirements prescribed in RFC 5280. Section 4.1.2.6 says:

If the subject field
contains an empty sequence, then the issuing CA MUST include a
subjectAltName extension that is marked as critical. When including
the subjectAltName extension in a certificate that has a non-empty
subject distinguished name, conforming CAs SHOULD mark the
subjectAltName extension as non-critical.

Given this, I believe this lint should be a RFC lint. Additionally, the status of the lint result returned upon encountering a non-critical SAN with empty subject name sequence should be an error.

[cardonator]

@CBonnell that quoted text is from 4.2.1.6 but I'm guessing this similarly written section in 4.1.2.6 implies the same behavior.

If subject
naming information is present only in the subjectAltName extension
(e.g., a key bound only to an email address or URI), then the subject
name MUST be an empty sequence and the subjectAltName extension MUST
be critical.

Does lint_subject_empty_without_san cover this scenario already?

[christopher-henderson]

@CBonnell

Additionally, the status of the lint result returned upon encountering a non-critical SAN with empty subject name sequence should be an error.

I believe that I agree with @zakird's interpretation that the branch should simply be removed from this lint altogether.

The branch does not address the clause subjectAlternativeName SHOULD NOT be marked critical unless the subject field is an empty sequence an any direct way. As such, any interpretation of the branch would be sourced from a separate document-or-clause which itself should have its own dedicated lint.

---

Given this, I believe this lint should be a RFC lint.

Indeed, however the issue is irrespective as ZLint does not operate on the concept of "shared" lints between governing documents.

That is to say, even if two documents happen to contain the same wording, they still receive their own version of the given lint.

While it is indeed moderately redundant, it does drastically reduce the risk of a code change interfering with the interpretation of an unrelated governing document.

So we are going to need a lint for this requirement under the CABF SMIME umbrella, irrespective if we happen to have (or need) a doppelganger lint for 5280.

---

@cardonator

Does lint_subject_empty_without_san cover this scenario already?

(lint_subject_empty_without_san.go)

It at least does something similar, albeit without criticality testing.

[cardonator]

That is an RFC lint at any rate, but I think I agree with you philosophically that if the SMIME BRs outline behavior, it makes sense for the lints designated for those standards to cover the described behavior, even if duplicative.