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

Mon Apr 25 20:47:58 UTC 2022

Hello Christophe (and Bruce):

Similarly, new text (based on similar language already approved in the CSBR)
has been added to 6.1.2 and 6.1.3 permitting CAs to generate Private Keys,
and laying out requirements for their secure transport.

https://github.com/cabforum/smime/blob/preSBR/SBR.md#612-private-key-deliver
y-to-subscriber

Thanks again for the feedback.

Regards, Stephen

From: Stephen Davidson 
Sent: Monday, April 25, 2022 1:04 PM
To: Christophe Bonjean <christophe.bonjean at globalsign.com>; SMIME
Certificate Working Group <smcwg-public at cabforum.org>
Subject: RE: Comments and questions on draft SMIME BRs

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
<mailto: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 <mailto: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/c86ba743/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4999 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220425/c86ba743/attachment-0001.p7s>