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

[Pedro FUENTES]

Hi all,
I’d just like to state that OISTE is supportive with the arguments presented by HARICA, and we aren’t comfortable with several of the restrictions imposed for subjectNames. In general we are more aligned with the approach of mandating that "any information present in the certificate must be verified and the evidence of such verification, auditable"… but not aligned with imposing restrictions that aren’t giving evident value.

In respect to the OCSP, while we consider it’s necessary to perform appropriate signature validations, and we deliver such service and we will continue delivering it, given the facts that (1) cert. consumers don’t seem to be willing to implement validations considering the time of signature and (2) cert. consumers are clearly moving away from OCSP for TLS and most likely S/MIME will follow the same path, right now we don’t see appropriate mandating the support to OCSP in the BR.

Also, concerning the latests inputs coming from CAs (e.g. Spain) that manifest that there are constraints in the BR that collide with national regulations, I think this should be seriously considered.

At this particular moment, OISTE doesn’t feel in a position to be able to formulate a vote for an eventual ballot, as we see the need to clarify several important open points.

Best,
Pedro

On 14 Sep 2022, at 07:16, Dimitris Zacharopoulos (HARICA) via Smcwg-public <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>> wrote:

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.
_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org<mailto:Smcwg-public at cabforum.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=48wyoc6B2NEZ9HVCZYzqLQI0hqDqTinbJne6A7h6p3U&s=US4svvpJup8eqgYnheCLNTGuf41XMJHMZosYv01cnYw&e=


WISeKey SA
Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790
Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
Stay connected with WISeKey<http://www.wisekey.com>

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220915/67dd0cfe/attachment-0001.html>