<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:"Yu Gothic";
        panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
        {font-family:"\@Yu Gothic";
        panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0cm;
        font-size:10.0pt;
        font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:32077681;
        mso-list-template-ids:77879380;}
@list l1
        {mso-list-id:104544803;
        mso-list-template-ids:960002546;}
@list l1:level1
        {mso-level-tab-stop:36.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l1:level2
        {mso-level-tab-stop:72.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l1:level3
        {mso-level-tab-stop:108.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l1:level4
        {mso-level-tab-stop:144.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l1:level5
        {mso-level-tab-stop:180.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l1:level6
        {mso-level-tab-stop:216.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l1:level7
        {mso-level-tab-stop:252.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l1:level8
        {mso-level-tab-stop:288.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l1:level9
        {mso-level-tab-stop:324.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2
        {mso-list-id:178008710;
        mso-list-template-ids:-438509614;}
@list l2:level1
        {mso-level-tab-stop:36.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level2
        {mso-level-tab-stop:72.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level3
        {mso-level-tab-stop:108.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level4
        {mso-level-tab-stop:144.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level5
        {mso-level-tab-stop:180.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level6
        {mso-level-tab-stop:216.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level7
        {mso-level-tab-stop:252.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level8
        {mso-level-tab-stop:288.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l2:level9
        {mso-level-tab-stop:324.0pt;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l3
        {mso-list-id:1667397053;
        mso-list-template-ids:1541024892;}
ol
        {margin-bottom:0cm;}
ul
        {margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi Dimitris,<o:p></o:p></p><p class=MsoNormal>I think we agree that multiple instances of OU can appear if OU is allowed, at least in the near term (Legacy).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’m not quite sure what you mean by “lack of support” for multiple instances of streetAddress and orgId; to the best of my knowledge, multiple instances of these attribute types pose no issue with processing in client software today. Can you clarify?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b>From:</b> Dimitris Zacharopoulos (HARICA) <dzacharo@harica.gr> <br><b>Sent:</b> Saturday, July 24, 2021 5:45 AM<br><b>To:</b> Corey Bonnell <Corey.Bonnell@digicert.com>; SMIME Certificate Working Group <smcwg-public@cabforum.org>; Sebastian Schulz <sebastian.schulz@globalsign.com><br><b>Subject:</b> Re: [Smcwg-public] Cardinality of subject fields<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi Corey,<br><br>So, to summarize, the current proposals for multiple values in the subjectDN are the following:<o:p></o:p></p><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>OU (probably makes sense to allow multiple instances until we decide further actions)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>streetAddress (probably makes sense to forbid because of lack of support)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>organizationIdentifier (probably makes sense to forbid multiple instances because of lack of support by Certificate Consumers)<o:p></o:p></li></ol><p>Is this a fair summary?<o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>Dimitris.<o:p></o:p></p><div><p class=MsoNormal>On 13/7/2021 11:40 μ.μ., Corey Bonnell via Smcwg-public wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Hi Seb,<o:p></o:p></p><p class=MsoNormal>Generally, I agree with you that multiple instances of a given attribute type may introduce complexity, although I think for the orgId case, there is value in allowing multiple registration schemes to assist RP software in automated lookups of supplementary information regarding the Subject.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>The rationale for including streetAddress as an allowed duplicate attribute type stems solely from historical practice seen in the TLS world. It appears that a common practice was/is to include the street information in one streetAddress RDN and any apartment/suite, etc. information in a subsequent RDN. If we decide that is not desirable for S/MIME, then we can forbid that attribute type from appearing more than once. I don’t have strong feelings either way.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>I suppose the cardinality of OU will go alongside the discussion of what we want to do with OU in general; as you mentioned, permitting its presence (or “presences”) in Legacy and Multipurpose but restricting it in Strict may be a viable way of providing a transition path.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b>From:</b> Sebastian Schulz <a href="mailto:sebastian.schulz@globalsign.com"><sebastian.schulz@globalsign.com></a> <br><b>Sent:</b> Tuesday, July 13, 2021 11:01 AM<br><b>To:</b> Corey Bonnell <a href="mailto:Corey.Bonnell@digicert.com"><Corey.Bonnell@digicert.com></a>; <a href="mailto:smcwg-public@cabforum.org">smcwg-public@cabforum.org</a><br><b>Subject:</b> RE: Cardinality of subject fields<o:p></o:p></p></div></div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:EN-US'>Hey Corey, Hey All,</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:EN-US'>Agreed – would be good to clarify that right off the bat. Is there a reason why multiple instances of the S field should be supported? For the organisational Identifier the different registration schemes are a valid point.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:EN-US'>Generally, I’d say that having multiple instances of attributes present significantly complicates validation and increases the risk of the certificate representing outdated information at some point during its validity. But given your argument for OID and the widespread use of multiple OU for all sorts of information it might be yet another case of something we’d want to avoid for “Strict” and allow for other profiles?</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:EN-US'>Best,</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:EN-US'>Seb</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:EN-US'> </span><o:p></o:p></p><div><p class=MsoNormal><b><span style='font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:EN-US'>Sebastian Schulz</span></b><span style='color:#1F497D;mso-fareast-language:EN-US'><br></span><i><span lang=EN-GB style='font-family:"Arial",sans-serif;color:#666666'>Product Manager Client Certificates</span></i><o:p></o:p></p></div><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:EN-US'> </span><o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b>From:</b> Smcwg-public <<a href="mailto:smcwg-public-bounces@cabforum.org">smcwg-public-bounces@cabforum.org</a>> <b>On Behalf Of </b>Corey Bonnell via Smcwg-public<br><b>Sent:</b> 13 July 2021 15:16<br><b>To:</b> SMIME Certificate Working Group <<a href="mailto:smcwg-public@cabforum.org">smcwg-public@cabforum.org</a>><br><b>Subject:</b> [Smcwg-public] Cardinality of subject fields<o:p></o:p></p></div></div><p class=MsoNormal><span lang=EN-GB> </span><o:p></o:p></p><p class=MsoNormal>Hello,<o:p></o:p></p><p class=MsoNormal>When reviewing the proposed set of allowed/required subject fields for the profiles we have discussed this far, I realized that there is room for better clarity regarding the allowed number of each attribute type that may be present in each subject. For example, the current specification leaves it unclear whether multiple CN attributes may be present in the subject Name. The cardinality of each attribute type is currently left unstated in the TLS BRs, which has led to a lack of clarity and disagreements on the allowed number of various attribute types.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>To prevent this confusion and provide concrete written guidance, I suggest that we add a column to the profiles spreadsheet that indicates whether multiple instances of an attribute type are allowed.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>To start, I propose that the following attributes be allowed to appear more than once:<o:p></o:p></p><ol style='margin-top:0cm' start=1 type=1><li class=MsoListParagraph style='margin-left:0cm;mso-list:l2 level1 lfo6'>OU (if we decide to allow its presence at all)<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0cm;mso-list:l2 level1 lfo6'>streetAddress<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0cm;mso-list:l2 level1 lfo6'>organizationalIdentifier (if different registration schemes are specified)<o:p></o:p></li></ol><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>All other attribute types must not appear more than once in each subject.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Thoughts?<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Smcwg-public mailing list<o:p></o:p></pre><pre><a href="mailto:Smcwg-public@cabforum.org">Smcwg-public@cabforum.org</a><o:p></o:p></pre><pre><a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><o:p></o:p></pre></blockquote><p class=MsoNormal><o:p> </o:p></p></div></body></html>