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

[Corey Bonnell]

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).

 

Thanks,

Corey

 

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?

 

Russ

 





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 4.2.1.6

 

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>
https://tools.ietf.org/html/rfc5322

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

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

 

_______________________________________________
Smcwg-public mailing list
 <mailto:Smcwg-public at cabforum.org> Smcwg-public at cabforum.org
 <https://lists.cabforum.org/mailman/listinfo/smcwg-public>
https://lists.cabforum.org/mailman/listinfo/smcwg-public

 

-------------- 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>