[Smcwg-public] Comments and questions on draft SMIME BRs

Adriano Santoni adriano.santoni at staff.aruba.it
Tue Apr 26 12:16:25 UTC 2022

We also find it unjustified to require EV-style vetting in "Baseline 

More comments will follow in subsequent emails.

Thank you,



Il 25/04/2022 16:48, Bruce Morton via Smcwg-public ha scritto:
> Entrust would also like to provide some comments to the S/MIME BRs. 
> First, great job, we have gone from zero to a set of baseline 
> requirements which are now open for community review before finalization.
> In some cases, we find the requirements are above current practices, 
> so could also be considered above what we have considered to be 
> baseline for SSL and Code Signing. The result might be to either 
> increase time required for adoption, or potentially reducing identity 
> which we currently see in certificates.
> Monitoring of Enterprise RAs
>   * Although this is required from SSL BRs, the Enterprise RA can only
>     approve sub-domains and approve certificate issuance. There is
>     nothing to monitor for sub-domains, as this is in the Subscriber’s
>     control. For approving SSL certificate issuance, this could be as
>     simple as 2-factor login. In essence for SSL certificates
>     monitoring of an Enterprise RA is a minimal task.
>   * For S/MIME certificates, the Enterprise RA would have to verify
>     firstName/surname and the front end of the email address. In
>     addition, the customer could have many Enterprise RAs, which
>     support the issuance of thousands of certificates per year. So how
>     do we monitor this activity and do we really need to? Enterprise
>     RAs are really technically constrained to verified organizations
>     and domain names, so is monitoring required? Could we enforce the
>     Enterprise RA requirements in the Subscriber agreement?
>   * If auditing/monitoring is required, then should a list of methods
>     be provided? If not, then each CA can do whatever they can
>     convince their auditor is good enough.
> EV Verification
>   * EV vetting does not appear to be a baseline requirement, it is
>     costly and there is no extended benefit which we have from SSL and
>     Code Signing. OV vetting does appear to an appropriate baseline
>     requirement and is currently used by CAs today.
>   * If we have EV vetting for an Organization, how does this extend to
>     Certificate Approver, Contract Signer and Certificate Requester
>     validation? Do we need this? This is increased vetting for S/MIME
>     BR, which is not required by the SSL or Code Signing BRs. We
>     already have the Enterprise RA, which can authorize a certificate
>     to be issued.
>   * Also, there may be too many restrictions which would result in
>     decreasing identity. For instance, can we remove
>     Operational Existence?
> S/MIME Revocation
>   * Should revoked S/MIME certificates be removed from the CRL/OCSP
>     responses after the certificate has expired? Since an email can be
>     read after certificate expiry, shouldn’t the relying party know
>     the revocation status?
> Subscriber Private Key Generation
>   * Section 6.1.2 doesn’t provide any indication that a CA could
>     generate the key pair for the subscriber. The CA should be allowed
>     to do this and that the section should provide requirements for
>     protecting key delivery. This has been addressed in the CSBRs.
> Subscriber Key Recovery
>   * Not addressed. Should we address recovery, if a CA has generated
>     the key pair?
> Multi-factor
>   * Should this either be removed or updated? “The CA SHALL enforce
>     multi-factor authentication for all accounts capable of directly
>     causing certificate issuance.” This appears to be a drop-in
>     requirement, which again could be removed or updated for more clarity.
> Thanks, Bruce.
> *From:* Smcwg-public <smcwg-public-bounces at cabforum.org> *On Behalf Of 
> *Christophe Bonjean via Smcwg-public
> *Sent:* Monday, April 25, 2022 4:54 AM
> *To:* smcwg-public at cabforum.org
> *Subject:* [EXTERNAL] [Smcwg-public] Comments and questions on draft 
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know 
> the content is safe.
> ------------------------------------------------------------------------
> Hi all,
> In reviewing the draft S/MIME Baseline Requirements, GlobalSign has 
> the following comments and questions:
> **
> *Validation level*
> With SMIME certificates, the goal is to provide “reasonable assurance” 
> that the other party to the communication identified in the 
> certificate has control of the domain or email address being asserted.
> We realize that additional validation elements as described in the TLS 
> EVGs could provide a higher level of assurance than merely "reasonable 
> assurance", however certain elements that are central to the TLS EVGs 
> may place a significant burden on the Applicant organization (physical 
> address, verified method of communication, operational existence).
> What's the justification for requiring EV level validation over OV 
> level validation?
> *Profiles*
> Multiple levels of profiles have been defined (legacy, strict) to 
> allow for transitioning from legacy to a stricter profile, however the 
> principle appears to be not consistently applied.
> For example, there is a requirement for subject:givenName and 
> subject:surname in the sponsor-validated (section and 
> individual-validated profile (, both for legacy and strict.
> If the intent for the legacy profile is to capture the profile of 
> existing certificates, should givenName and surname be required only 
> for the strict profile?
> *Enterprise RAs*
> If Enterprise RAs validate first name, last name and the first part of 
> the email address, to which extent could that be considered 
> constrained? The requirements of section 8.8 are subject to 
> interpretation. If review or auditing is required, should we define 
> specific criteria or practices?
> *Identity validation: eIDs*
> eIDs as defined and notified under eIDAS are currently excluded under 
> "Digital Identity Documents" (section option 2), which seems 
> to aim at physical identity documents but with a digital component.
> Given the defined framework, recognition and practical application of 
> eIDs, it seems their purpose would fulfill the identity validation 
> requirements of individuals for SMIME certificates. What's the 
> rationale for excluding them?
> *Identity validation: Sponsor-validated without Enterprise RA*
> For sponsor-validated certificates with Enterprise RA, the validation 
> of the individual identity information can be based on Enterprise RA 
> records (section option 4). For non-Enterprise RA 
> sponsor-validated certificates, there is no equivalent option to rely 
> on an attestation made by the sponsor for the individual identity 
> information (e.g. first name, last name) or affiliation.
> Would it be possible to introduce the option to rely on attestation of 
> the validated sponsor in the same way as we would rely on the 
> Enterprise RA records if it meets the same requirements (Section 1.3.2 
> and Section 8.8) for individual identity information and/or affiliation?
> *Identity validation: Individual identity information*
> Should we also consider incorporating agency sources as a source for 
> listed director individual identity information (akin to the 
> Enterprise RA records, but publicly available and where the identity 
> validation is regulated in the relevant jurisdiction of incorporation)?
> *Identity validation: Digital signatures*
> For digital signatures (section option 3), could we allow 
> additional adopted standards to be used under certain conditions, for 
> example:
>   * CA has a documented procedure to review adopted standards against
>     the SMIME BRs to ensure they meet the required assurance level;
>   * the CA lists additional accepted standards in their CPS; and
>   * CA notifies these additional standards for inclusion within the
>     SMIME BRs, but pending acceptance/rejection these standards may be
>     used.
> *Organizational Units*
> Would departments as organizational units fit within the profile? And 
> if yes, could they be included in organization-validated or 
> sponsor-validated? The current definition of organizationalUnitName 
> (section item c) seems to be limited to affiliate entities, 
> but not departments?
> **
> *Key generation*
> Section 6.1.2 does not currently specify whether it's prohibited or 
> allowed to generate private keys for customers?
> *Revocation status*
> Since emails may be read a while after the validity period of the 
> certificate, should status information remain on OCSP/CRL after expiry 
> of the certificate?
> Thank you
> Christophe
> /Any email and files/attachments transmitted with it are confidential 
> and are intended solely for the use of the individual or entity to 
> whom they are addressed. If this message has been sent to you in 
> error, you must not copy, distribute or disclose of the information it 
> contains. _Please notify Entrust immediately_ and delete the message 
> from your system./
> _______________________________________________
> 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/20220426/012cf1a0/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/20220426/012cf1a0/attachment-0001.p7s>

More information about the Smcwg-public mailing list