[Smcwg-public] email addresses in S/MIME certificates

Corey Bonnell Corey.Bonnell at digicert.com
Fri Nov 20 10:01:20 MST 2020

Hi Russ,

I think for the SAN extension, a clarifying statement is unnecessary as
rfc822Name must unconditionally be encoded as an IA5String. I agree that
such a clarification would be useful to mandate the use of UTF8String for
any subject attribute that contains an email address, such as CN (except for
E, which must be an IA5String).





From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Russ
Housley via Smcwg-public
Sent: Friday, November 20, 2020 1:05 AM
To: Stephen Davidson <Stephen.Davidson at digicert.com>
Cc: SMIME Certificate Working Group <smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] email addresses in S/MIME certificates


FROM RFC 5280:


   Implementers should note that the at sign ('@') and underscore ('_')

   characters are not supported by the ASN.1 type PrintableString.

   These characters often appear in Internet addresses.  Such addresses

   MUST be encoded using an ASN.1 type that supports them.  They are

   usually encoded as IA5String in either the emailAddress attribute

   within a distinguished name or the rfc822Name field of GeneralName.

   Conforming implementations MUST NOT encode strings that include

   either the at sign or underscore character as PrintableString.


Do we want to say anything about using IA5String or UTF8String?




On Nov 19, 2020, at 5:11 PM, Stephen Davidson via Smcwg-public
<smcwg-public at cabforum.org <mailto:smcwg-public at cabforum.org> > wrote:


To date our discussion related to email addresses in S/MIME has been a
general reference to rfc822Name along the lines of:


Extension ID:                      subjectAlternateName

Required?:                          Yes

Critical:                                 Yes if the subject is an empty
sequence; otherwise, SHOULD NOT be critical

Permitted Value(s):        MUST contain at least one rfc822Name value. MUST
NOT contain values of type: dNSName, iPAddress, uniformResourceIdentifier.
otherName values (such as Microsoft UPN) MAY be included if the value is
identical to an rfc822Name expressed in the SAN extension. Any rfc822Name
and otherName value in the Subject DN must be repeated in the SAN extension.
Each rfc822Name and otherName value must be verified with publicly
documented and audited measures in accordance with Section 3.2.2.

References:                        RFC 5280, Section


S/MIME and rfc822Name has enjoyed a proliferation of standards which leads
to the question:

*	Do we wish to summarise those rules relating to rfc822Name in this
standard or in an informative appendix?
*	Or do wish simply to provide a listing of the relevant standards?


If the latter, I believe the most relevant would include RFC 5322 (internet
message format, sections 3.2.3 and 3.4.1), RFC 3696 (informational, checking
of names), and RFC 8398 (internationalized email addresses).


Missing anything?  Comments?


Best regards, Stephen


RFC 5322:  <https://tools.ietf.org/html/rfc5322>

RFC 3696:  <https://tools.ietf.org/html/rfc3696>

RFC 8398:  <https://tools.ietf.org/html/rfc8398>


Smcwg-public mailing list
 <mailto:Smcwg-public at cabforum.org> Smcwg-public at cabforum.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20201120/440f765e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20201120/440f765e/attachment-0001.p7s>

More information about the Smcwg-public mailing list