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

[Bruce Morton]

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 3.2.3.6 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 SMIME BRs

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 7.1.4.2.4) and individual-validated profile (7.1.4.2.5), 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 3.2.4.1 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 3.2.4.1 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 3.2.4.1 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 7.1.4.2.2 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220425/f43d6347/attachment-0001.html>