Clarify applicability of S/MIME email validation policies

[wthayer]

Clarify which certificate fields our S/MIME email address validation rules apply to. Is it only Rfc822Names in the SAN, or does it include the CN, Subject:Email, and potentially other fields?

Some research is needed to determine if Thunderbird will validate an S/MIME certificate with an email address in the CN or some other field besides the SAN.

[dougbeattie]

This is a good question. Certainly the email addresses in the following need to be validated:

• Subject DN: CN: Although, we should not really use that for email addresses. Perhaps we should forbid this? If the value is here, then it should/MUST also be in the SAN RFC822 field
• Subject DN: E: yes, certainly this needs to be validated, and any value here MUST be in the SAN RFC822 field
• SAN: RFC822: yes, certainly all of the email addresses in this field need to be validated.

I have a question about the SAN: Other Name: UPN. This is a login ID that is in the format of an RFC822 email address. Since it's not used for SMIME, does this need to be validated following the same rules as the fields containing email addresses above?

[juanangelmg]

I have a question about the SAN: Other Name: UPN. This is a login ID that is in the format of an RFC822 email address. Since it's not used for SMIME, does this need to be validated following the same rules as the fields containing email addresses above?

This login ID is recommended to be in RFC822 email address’ format.

I've seen several UPNs that only have the prefix and I'm not sure that it's a violation of anything.

[dougbeattie]

I'd like to propose this change to section 2.2 of the Mozilla Policy:

Change this:

the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate.

to this:

the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address that is contained in the subject:commonName, subject:emailAddress, or subjectAltName:rfc822Name fields and that any value in the subject MUST also appear in the subjectAltName:rfc822Name.

[dougbeattie]

Hi Ben and Kathleen,

What are your thoughts on the proposed change above?

[BenWilson-Mozilla]

When you say "that any value in the subject MUST also appear in the subjectAltName:rfc822Name" I assume that needs to be limited to an email address if it appears in the commonName or emailAddress, so does it need to say that explicitly?

[BenWilson-Mozilla]

@dougbeattie
In other words, I think there is just a little bit of wordsmithing that needs to be done, right?

Should it say, "the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address that is contained in the subject:commonName, subject:emailAddress, or subjectAltName:rfc822Name fields and that any email address in the subject:commonName or subject:emailAddress MUST also appear in the subjectAltName:rfc822Name. ?  Is that the intent?

[dougbeattie]

@BenWilson-Mozilla , Yes! This clarifies a few things:

1. the scope of the requirement for email address validation now specifies the exact fields which must be validated in accordance with section 2.2 vs. "the email address referenced in the certificate"
2. You MUST to put the email address in the subjectAltName:rfc822Name
3. Email addresses in other fields within a certificate intended for Secure Mail don't need to follow this level of validation (for example in the UPN when the certificate is used for Secure Mail and Client Authentication.)

[BenWilson-Mozilla]

With that clarification, it sounds OK to me.