[Smcwg-public] email address in CommonName

Tim Hollebeek tim.hollebeek at digicert.com
Thu Mar 24 14:53:26 UTC 2022


I actually suggested this draft text internally, to help people avoid the footgun here:

Note: subject:commonName and subject:emailAddress need to comply with the length requirements in RFC 5280.

Getting more detailed than that is actually dangerous, as there's some subtlety here regarding encodings, so the reader should just go read RFC 5280 and get it right.

I'm not sure what to do about the fact that these two fields are not special in this regard.  On the one hand, I like Corey's suggestion that for completeness, a more general statement for the entire section makes sense.  On the other hand, I think Inigo has correctly identified that a few of these fields are more likely to cause problems than others.  Perhaps we need a general note up top, but specifically call out a few of the more common problem fields (e.g. also subject:Organization) so that if someone is searching the document for one of those fields, they'll find the note...

Just thinking out loud.

-Tim

From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Corey Bonnell via Smcwg-public
Sent: Wednesday, March 23, 2022 5:36 PM
To: Inigo Barreira <Inigo.Barreira at sectigo.com>; SMIME Certificate Working Group <smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] email address in CommonName

Hi Inigo,
Thanks for raising this. Comments inline.


> If we support emailaddress in CN, then there could be a potential truncation if the length is beyond 64 characters. Or are not allowing to enter the email address if it´s above this value? Up to the CAs to decide?

I see this as similar to the situation we currently have with serverAuth certificates: if a Domain Name exceeds 64 characters, then it cannot be included in the CN despite being included in a SAN dNSName. Allowing values >64 characters violates RFC 5280, and we require adherence to 5280. Additionally, truncating the email address may be an attack vector, as an unvalidated email address would be included in the CN. For these reasons, I don't believe it's permissible to include such email addresses in the CN.


> Even though CN is an optional field in the Subject for all types (MV, OV, SV and IV), in all of them, it´s allowed the use of email address. Furthermore, in MV is the only option. Maybe a clarification is needed in section 7.1.4.2.2 a.

I think it's a good idea to add clarity here, but I'm not quite sure of the best way to do it. If we explicitly call out the length limitation for CN, then it raises the question why we didn't explicitly specify the length limits for the other attribute types. Would a general "Attribute values MUST be encoded according to RFC 5280"-esque statement at the top of 7.1.4 add clarity?

Thanks,
Corey


From: Smcwg-public <smcwg-public-bounces at cabforum.org<mailto:smcwg-public-bounces at cabforum.org>> On Behalf Of Inigo Barreira via Smcwg-public
Sent: Tuesday, March 22, 2022 1:13 PM
To: SMIME Certificate Working Group <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>>
Subject: [Smcwg-public] email address in CommonName

Hi,

Reviewing the profiles, we realized that the encoding and upper bounds according to RFC5280 could create some issues when including the email in the CN.

Encoding

EmailAddress is IA5String to permit inclusion of the character '@'.
The attribute value for emailAddress is of type IA5String to permit inclusion of the character '@', which is not part
of the PrintableString character set.



CN is DirectoryString (UTF8String or PrintableString)

common name, employ the DirectoryString type, which supports internationalized names through a variety of language encodings.

Conforming implementations MUST support UTF8String and PrintableString



Upper bounds

ub-common-name INTEGER ::= 64

ub-emailaddress-length INTEGER ::= 255



If we support emailaddress in CN, then there could be a potential truncation if the length is beyond 64 characters. Or are not allowing to enter the email address if it´s above this value? Up to the CAs to decide?



Even though CN is an optional field in the Subject for all types (MV, OV, SV and IV), in all of them, it´s allowed the use of email address. Furthermore, in MV is the only option. Maybe a clarification is needed in section 7.1.4.2.2 a.



Regards



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220324/2649e493/attachment.html>


More information about the Smcwg-public mailing list