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

Wed Oct 26 07:13:54 UTC 2022

It’s really apples and oranges, but if people want parity, I’d point out that the TLS IV validation has not changed in something like seven years, and were not particularly state of the art at that time.  There’s a lot of great work on identity vetting that has been done in the meantime, especially in Europe.

If people want to work on updating TLS IV vetting to be more in line with recent standards, that would be a reasonable topic to discuss.

-Tim

From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Pedro FUENTES via Smcwg-public
Sent: Tuesday, October 25, 2022 10:58 AM
To: Adriano Santoni <adriano.santoni at staff.aruba.it>; SMIME Certificate Working Group <smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] [EXTERNAL]-Re: Ballot SMC01v3: Final Guideline for “S/MIME Baseline Requirements”

I share the exact same thoughts on the parallelism in identity validation requirements with for the TLS certificates.

But this discussion is futile once the voting has just started.

BR/P

On 25 Oct 2022, at 16:54, Adriano Santoni via Smcwg-public <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>> wrote:

Stephen,
I regret not having participated in the discussion on this issue at the time, and I apologize again for raising this issue only now.
However, I remain of the opinion that the "real time" requirement is an exaggeration for S/MIME certificates (while it is undoubtedly appropriate for eIDAS qualified signature certificates).
Neither Mozilla nor Microsoft require ETSI audits on S/MIME certificates to be based on an NCP type policy: both browser vendors accept the LCP policy, as can be seen from their respective root store program websites. If I am mistaken, please Ben and Karina correct me.
However, if the other CAs reading us here (and especially those that issue IV S/MIME certificates) believe that §3.2.4.2 is fine AS IS, it is important to realize that it clashes with some (many?) of their current procedures. From the moment these BRs are enacted and referred to by at least one root store policy, those CA's procedures immediately become non-compliant. If everyone realizes this and is okay with it, then it's fine to me too; otherwise let's talk about it.
I want to point out that I am not questioning the value of "real time" from a security point of view, but I don't understand why an IV S/MIME cert should be more secure than an IV SSL cert (for which no "real time" is required for the scan of a photo id). Both are issued to natural persons and should be equally secure, at least. Indeed, an IV SSL cert should in my opinion be more secure than an IV S/MIME cert, given that its possible insecurity impacts on many more subjects.
I am saying this only as a matter of logic, not because it is "a priori" necessary that the SSL BR and the S/MIME BR are aligned.
On top of that, I think we all agree that the S/MIME BR should reflect current procedures, at least for the "legacy" generation; how about requiring "real time" for the "strict" generation?
Adriano

Il 25/10/2022 15:38, Stephen Davidson ha scritto:
NOTICE: Pay attention - external email - Sender is Stephen.Davidson at digicert.com<mailto:Stephen.Davidson at digicert.com>

Hello Adriano:
This text has been in the draft S/MIME BR for close to 10 months and has been reviewed at some length.
Certificate Consumers stated that information included in the Subject DN needs to be reliably validated, and that a link needs to be made between the Subject and the cert, whether the Subject is a legal entity or a real natural person.
The requirement in question was derived from ETSI TS 119 461, which defines baseline procedures aimed at delivering at the NCP (Normalized Certificate Policy) level.
The issue with some legacy practices is that separate images of the ID and a user could be harvested and presented without the Subject’s knowledge.  By requiring their linked collection, the standard seeks to improve security in the remote vetting methods.
Best, Stephen

From: Smcwg-public <smcwg-public-bounces at cabforum.org><mailto:smcwg-public-bounces at cabforum.org> On Behalf Of Adriano Santoni via Smcwg-public
Sent: Monday, October 24, 2022 5:34 PM
To: smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] [External Sender] Ballot SMC01v3: Final Guideline for “S/MIME Baseline Requirements”

All,
I apologize for raising doubts at the very "last minute", but since the SMC BR are about to be put to the vote, I wanted to give them a complete re-reading and I noticed a passage that leaves me a little perplexed.
Maybe this aspect was discussed at length, but then I missed that discussion - sorry about that (in case).
Under "3.2.4.2 Validation of individual identity" we have the following sentence:
The CA or RA MAY use manual (in person) or remote procedures. A remote process SHALL ensure that the Applicant has the document in hand and presents the document in real‐time in front of a camera.
Where did we borrow "in real-time" from? Not from the TLS BR nor from EVGL, it seems.
What's the rationale for that? It seems too demanding, to me, for S/MIME certificates.
Several CAs that I am aware of are doing individual identity verification (for S/MIME certificates) based on a Photo ID and a selfie (showing both the Applicant and his/her Photo ID), and this latter is not required to be taken in "real time".
I am therefore a bit surprised that all the people here agree on this "in real time" which implies the non-compliance of current procedures and the need to move to more complex and more expensive procedures. Seems a bit excessive for S/MIME certificates.
Adriano

Il 14/10/2022 20:12, Stephen Davidson via Smcwg-public ha scritto:
NOTICE: Pay attention - external email - Sender is 01000183d7b27b10-4ccf8875-64fd-49e8-817e-0df9fe3a5117-000000 at amazonses.com<mailto:01000183d7b27b10-4ccf8875-64fd-49e8-817e-0df9fe3a5117-000000 at amazonses.com>

Ballot SMC01v3: Final Guideline for “S/MIME Baseline Requirements”

Note: the voting period for this ballot will commence following the SMCWG session at the upcoming CA/B Forum face-to-face Meeting 57.

Purpose of Ballot:

The S/MIME Certificate Working Group was chartered to discuss, adopt, and maintain policies, frameworks, and standards for the issuance and management of Publicly-Trusted S/MIME Certificates.  This ballot adopts a new “S/MIME Baseline Requirements” that includes requirements for verification of control over email addresses, identity validation for natural persons and legal entities, key management and certificate lifecycle, certificate profiles for S/MIME Certificates and Issuing CA Certificates, as well as CA operational and audit practices.

An S/MIME Certificate for the purposes of this document can be identified by the existence of an Extended Key Usage (EKU) for id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4) and the inclusion of a rfc822Name or an otherName of type id-on-SmtpUTF8Mailbox in the subjectAltName extension in the Certificate.

The following motion has been proposed by Stephen Davidson of DigiCert and endorsed by Martijn Katerbarg of Sectigo and Ben Wilson of Mozilla.

In accordance with the By-Laws, the discussion period has been extended with the distribution of this new version of the ballot, incorporating content that arose during the discussion period including regarding the use of suspension and updating ETSI references in section 8.2.

Charter Voting References

Section 5.1 (“Voting Structure”) of the SMCWG Charter says:

In order for a ballot to be adopted by the SMCWG, two-thirds or more of the votes cast by the Certificate Issuers must be in favor of the ballot and more than 50% of the votes cast by the Certificate Consumers must be in favor of the ballot. At least one member of each class must vote in favor of a ballot for it to be adopted. Quorum is the average number of Member organizations (cumulative, regardless of Class) that have participated in the previous three (3) SMCWG Meetings or Teleconferences (not counting subcommittee meetings thereof).

— MOTION BEGINS —

This ballot adopts the “Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates” (“S/MIME Baseline Requirements”) as Version 1.0.0.

The proposed S/MIME Baseline Requirements may be found at https://github.com/cabforum/smime/pull/178/files or the attached document.  A redline of changes since the SMC01 Ballot discussion started may be found at https://github.com/cabforum/smime/compare/28c0b904fe54f1c5f6c71d18c4786a3e02c76f52...b1ff7867dc85392e4c57b1993ed571e61e34dee2

The SMCWG Chair or Vice-Chair is permitted to update the Relevant Dates and Version Number of the S/MIME Baseline Requirements to reflect final dates.

— MOTION ENDS —

This ballot proposes a Final Guideline. The procedure for approval of this ballot is as follows:

Discussion (7+ days)
Start Time: 14 October 2022 14:00 ET (US Eastern)
End Time: not before 21 October 2022 14:00 ET (US Eastern)

Vote for approval (7 days)
Start Time: To be confirmed
End Time: To be confirmed

IPR Review (60 days)

_______________________________________________

Smcwg-public mailing list

Smcwg-public at cabforum.org<mailto:Smcwg-public at cabforum.org>

https://lists.cabforum.org/mailman/listinfo/smcwg-public
_______________________________________________
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=18G_plWPAeJu5QRlrkP0W1yv8Gr8jI4iylgOxeXnCo8&s=SWfQR2dc-tyhruDnioj37UW1IeiZOGDXW2S9EYiHy4g&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/20221026/7a5bdf7c/attachment-0001.html>