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

Tue Oct 25 14:54:28 UTC 2022

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
>
>
>
> 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> *On Behalf 
> Of* Adriano Santoni via Smcwg-public
> *Sent:* Monday, October 24, 2022 5:34 PM
> *To:* 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
>
>
>     *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
>
>     https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20221025/fbe32943/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4557 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20221025/fbe32943/attachment-0001.p7s>