[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).
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>
More information about the Smcwg-public
mailing list