[Smcwg-public] Ballot SMC01: Final Guideline for “S/MIME Baseline Requirements”

[Dimitris Zacharopoulos (HARICA)]

Hi Corey,

On 14/9/2022 12:00 π.μ., Corey Bonnell wrote:
>
> Hi Dimitris,
>
> Comments inline.
>
> > However, until this analysis is performed, mandating OCSP for S/MIME 
> Certificates seems premature.
>
> 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).
>

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 *only *reason 
for adopting such a requirement in a CABF Guideline.

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.

>
> > 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.
>
> 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.
>

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.

> As to the merit of mandating C (and potentially the other geographic 
> location fields), can you expound on that further?
>

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.

> We already include globally unique identifiers in the orgId attribute, 
> so that is sufficient information to identify the subject organization.
>

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.

> Any other information, such as geographic location information, is 
> merely supplementary information that may not be useful to include.
>

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.

> As I see it, the ETSI use case is accommodated by making these 
> attributes optional, so any further changes become restrictive on 
> other CAs.
>

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.


Thanks,
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220914/00a4bf29/attachment.html>