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

[Wendy Brown - QT3LB-C]

I haven't really thought through the validation aspects yet, but I mainly
support an environment where the certs are issued to those affiliated with
an organization and the CA has a direct relationship with that
organization.  If the DNS portion of the UPN matches the DNS portion of an
email that has been validated, I would consider that sufficient if the
portion of the UPN in front of the @ was supplied by the
organization, which is also responsible for assigning that UPN to the
individual.  As others have said the UPN value is for authentication not
secure email and at this time may not have to be fully validated to the
same level as the email address.  But should not be prohibited from being
included in the certificate as it may break many current implementations
unnecessarily.

thanks,

Wendy

Wendy Brown
Supporting GSA FPKI
Protiviti Government Services

 703-965-2990 (cell)

wendy.brown at gsa.gov
wendy.brown at protiviti.com


On Fri, Nov 20, 2020 at 9:17 AM Corey Bonnell <Corey.Bonnell at digicert.com>
wrote:

> 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)
>
> wendy.brown at gsa.gov
> 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> 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
>
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
>
>
> _______________________________________________
> Smcwg-public mailing list
> 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/08fc23e4/attachment.html>