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

[Corey Bonnell]

Hi Wendy,

I realize that we haven’t quite yet discussed the validation processes for SAN entries, but how would you envision such a validation process for UPNs to work if we permit a UPN SAN to not match one of the validated email addresses?

 

Thanks,

Corey

 

From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Wendy Brown - QT3LB-C via Smcwg-public
Sent: Friday, November 20, 2020 8:07 AM
To: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; SMIME Certificate Working Group <smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] email addresses in S/MIME certificates

 

Also I do not remember a discussion that the UPN, if present, has to be identical to the email address.  Although I may have missed at least 1 of the calls.  I do not think this is always the case.

Another question is will we allow more than one email address SAN?

 

thanks,


Wendy

Wendy Brown
Supporting GSA FPKI
Protiviti Government Services

 703-965-2990 (cell)

 <mailto:wendy.brown at gsa.gov> wendy.brown at gsa.gov
wendy.brown at protiviti.com <mailto:wendy.brown at protiviti.com> 

 

 

On Fri, Nov 20, 2020 at 6:19 AM Dimitris Zacharopoulos (HARICA) via Smcwg-public <smcwg-public at cabforum.org <mailto:smcwg-public at cabforum.org> > wrote:


I believe this proposal prohibits directoryName values in the subjectAltName extention. I remember that the intent of the first version of S/MIME requirements was not to prohibit identity information to be included in the Certificate Profile.

Dimitris.



On 20/11/2020 12:11 π.μ., Stephen Davidson via Smcwg-public 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

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

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

 

 

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

 

_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org <mailto:Smcwg-public at cabforum.org> 
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/7e308a82/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/7e308a82/attachment-0001.p7s>