<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi Corey,<br>
<br>
<div class="moz-cite-prefix">On 14/9/2022 12:00 π.μ., Corey Bonnell
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM6PR14MB21867ECF33E47EAEF313DD4092479@DM6PR14MB2186.namprd14.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@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;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin-top:0in;
margin-right:0in;
margin-bottom:8.0pt;
margin-left:0in;
line-height:105%;
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:0in;
font-size:10.0pt;
font-family:"Courier New";}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;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0in;}ul
{margin-bottom:0in;}</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]-->
<div class="WordSection1">
<p class="MsoNormal">Hi Dimitris,<o:p></o:p></p>
<p class="MsoNormal">Comments inline.<o:p></o:p></p>
<p class="MsoNormal">> However, until this analysis is
performed, mandating OCSP for S/MIME Certificates seems
premature.<o:p></o:p></p>
<p class="MsoNormal">There is a clearly stated Root Program
requirement mandating the inclusion of OCSP pointers for all
end-entity certificates. In the case for Code Signing, there
was a clear statement from the Root Program rep that OCSP is
optional for timestamping and code signing certificates. I
have yet to see any such statement concerning S/MIME from
Microsoft. In the absence of any such statement, then there is
risk in having the SMBRs diverge from Root Program policy
(i.e., a CA might “miss” the Microsoft Root Program
requirement for OCSP because the SMBRs declared it optional).</p>
</div>
</blockquote>
<br>
As Microsoft is not the only Root Program handling S/MIME
Certificates, and this group represents the industry consensus on
certain policies, I don't consider one Root Program's requirement to
be the <b>only </b>reason for adopting such a requirement in a
CABF Guideline. <br>
<br>
In any case, we would appreciate some statement from Microsoft
representatives, as it happened with the Code Signing WG case, about
whether OCSP is mandatory or optional (provided that CRLDP extension
exists in the end-entity certificate) for validating S/MIME
Certificates in their platform to clarify this issue.<br>
<br>
<blockquote type="cite"
cite="mid:DM6PR14MB21867ECF33E47EAEF313DD4092479@DM6PR14MB2186.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><br>
> The discussion was mainly around the localityName and the
stateOrProvinceName, especially in cases where the countryName
is sufficient for disambiguating the organization. The
countryName attribute is included in every ETSI-issued
identity Certificate used for S/MIME and is extremely easy to
validate, as explained in my previous message. Please consider
at least requiring the countryName for the Strict and
Multipurpose profiles.<o:p></o:p></p>
<p class="MsoNormal">The issue that was flagged by Martijn was
that the SMBRs required either L or ST to be included, but C
was optional [1]. Obviously, this was a bug regardless of
whether the geographic location attributes are desirable.
Stephen presented his fix to make all of C, ST, and L optional
in the prose (to match the tables) and there was no objection
raised. </p>
</div>
</blockquote>
<br>
I didn't read it that way but even so, we now have at least two
objections raised (HARICA, ACTALIS) for this issue. The main reason
we have these official discussion periods is for voting members to
re-examine the proposed ballot more carefully, catching issues that
were missed in previous discussions. I completely understand that
this feels frustrating but we need to try to build consensus as much
as we can.<br>
<br>
<blockquote type="cite"
cite="mid:DM6PR14MB21867ECF33E47EAEF313DD4092479@DM6PR14MB2186.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">As to the merit of mandating C (and
potentially the other geographic location fields), can you
expound on that further? </p>
</div>
</blockquote>
<br>
The main reasons for including the countryName when there is an
organizationName in the subject, is to alleviate the disambiguation
problem, allowing the subject to combine an Organization Name with a
specific Country. The same applies to Individuals. It is the first
step to narrow the scope of names.<br>
<br>
<blockquote type="cite"
cite="mid:DM6PR14MB21867ECF33E47EAEF313DD4092479@DM6PR14MB2186.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal">We already include globally unique
identifiers in the orgId attribute, so that is sufficient
information to identify the subject organization. </p>
</div>
</blockquote>
<br>
Current implementations display the countryName, L, ST but not the
orgId. Relying Parties currently cannot make sense of such an
identifier. It will take time.<br>
<br>
<blockquote type="cite"
cite="mid:DM6PR14MB21867ECF33E47EAEF313DD4092479@DM6PR14MB2186.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal">Any other information, such as geographic
location information, is merely supplementary information that
may not be useful to include. </p>
</div>
</blockquote>
<br>
To the contrary; existing standards (TLS BRs, CS BRs, ETSI EN 319
412-2) have established that these fields are useful and necessary
for Relying Parties to have some good idea about the subject of the
certificate.<br>
<br>
<blockquote type="cite"
cite="mid:DM6PR14MB21867ECF33E47EAEF313DD4092479@DM6PR14MB2186.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal">As I see it, the ETSI use case is
accommodated by making these attributes optional, so any
further changes become restrictive on other CAs.</p>
</div>
</blockquote>
<br>
Keeping the countryName optional doesn't serve the purpose of
identity verification and makes things worse for Relying Parties.
That's why I insist on making the countryName mandatory for the
Strict and Multipurpose profiles but not the Legacy. We already
decided to add useful ecosystem enhancements in the Strict and
Multipurpose profiles. This suggestion follows the same principle.
CAs can use the Legacy profile to have this field optional.<br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
</body>
</html>