RFC 2632 is fairly clear on the requirements for email addresses:
3. Using Distinguished Names for Internet Mail
End-entity certificates MAY contain an Internet mail address as
described in [RFC-822]. The address must be an "addr-spec" as defined
in Section 6.1 of that specification. The email address SHOULD be in
the subjectAltName extension, and SHOULD NOT be in the subject
distinguished name.
Receiving agents MUST recognize email addresses in the subjectAltName
field. Receiving agents MUST recognize email addresses in the
Distinguished Name field in the PKCS #9 emailAddress attribute.
Sending agents SHOULD make the address in the From or Sender header
in a mail message match an Internet mail address in the signer's
certificate. Receiving agents MUST check that the address in the From
or Sender header of a mail message matches an Internet mail address
in the signer's certificate, if mail addresses are present in the
certificate. A receiving agent SHOULD provide some explicit alternate
processing of the message if this comparison fails, which may be to
display a message that shows the recipient the addresses in the
certificate or other certificate details.
It should be obvious, but apparently is not, that "Sending and receiving
agents MUST accept certificates that do not contain an email address
in either the subject distinguished name or the subjectAltName extension."
For the son of RFC 2632, I propose:
1) appending a sentence to that effect to the first paragraph
of section 3.
2) changing the last sentence of the third paragraph from SHOULD to MUST:
"A receiving agent MUST provide some explicit alternate processing ..."
Individual communities of interest will profile whether their CAs
populate the subjectAltName extension, based on their judgement of
whether it is a benefit or an operational headache and security risk.
I just want to ensure that community-specific CAs have that choice, and
are not forced to populate the extension by a proliferation of
non-compliant user agents.