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

[Stephen Davidson]

Hello Christophe:

Thanks for the feedback.  We'll address these comments in due course.

As it happens, I was already working on text to include the use of eID for validating individual identity attributes, but was lingering to see if any details for the pending EUDI Wallet Toolkit would be useful in this context.  For example, I think the CA or RA would need to be a formal relying party of the eIDAS eID scheme.  We also should acknowledge schemes such as NIST/Kantara, and provide more info on how validation must occur.

However, noting interest in the use of eID, I have merged the starter text at https://github.com/cabforum/smime/pull/86.  As before, I welcome comments and improvements to this text.

Regards, Stephen





From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Christophe Bonjean via Smcwg-public
Sent: Monday, April 25, 2022 5:54 AM
To: smcwg-public at cabforum.org
Subject: [Smcwg-public] Comments and questions on draft SMIME BRs



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220425/5590c4f4/attachment.html>