[Smcwg-public] Individual's names in S/MIME certificates

Bruce Morton Bruce.Morton at entrust.com
Mon Feb 28 17:00:23 UTC 2022

I agree with Doug’s direction. We currently require the Enterprise RA to provide the CN and associated email address (based on a verified domain name) for each “enterprise” S/MIME certificate subject.


From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Doug Beattie via Smcwg-public
Sent: Monday, February 28, 2022 11:41 AM
To: SMIME Certificate Working Group <smcwg-public at cabforum.org>; Stephen Davidson <Stephen.Davidson at digicert.com>
Subject: [EXTERNAL] [Smcwg-public] Individual's names in S/MIME certificates

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 Stephen,

I’ve been out of the loop a bit on the lates status and some staffing changes have happened in the meantime so I didn’t release the level of auditing needed for individual names for the Sponsor validated method.

Reading the current spec, there is no way that the enterprise RA can provide an individual’s name without it being validated as their full legal name  and audited by the CA.

Section which says the CN must contain:
(subject:givenName and/or subject:surname) or  subject:pseudonym, or subject:email

By the way, I think you need to add the parentheses like above because this is not clear:
     subject:givenName and/or subject:surname, subject:pseudonym, or subject:email

It goes on to say that you must validate these in accordance with section 3.2.3 (Authentication of organization identity).  That section does not define the validation of any of those fields so I assume that this should reference 3.2.4 Authentication of individual identity.  I’m assuming yes.

This will drive usage to Mailbox or Organization because nobody will want to do audits (CAs or Customers), so there will no longer be readable names in S/MIME certificates.  That’s very unfortunate.  Maybe nobody looks at that field and rely on the “From: and “reply to” fields, so not using sponsor validated certificates isn’t an issue and we could look to remove this from the spec as something that won’t be adopted.


Is there no way we can come up with a way to permit the enterprise RA to optionally supply the name details (in some field) with less validation rigor/auditing?  As it stands, we cannot issue certs to helpdesk at example.com<mailto:helpdesk at example.com> with something like “Help Desk” in the subject DN.

Could we permit the Enterprise RA to supply Sponsor verified name details into the CN and omit givenName and surname and not require formal recordkeeping and audits?  Since these certificates will contain the Sponsor validated OID, relying parties will (could) know the level of validation applied to the CN is “Supplied by Organization and not validated by the CA” vs. the current level of assurance.  I totally understand the high level of validation needed for the Individual Validated certs, but the Sponsor validated certificates could/should(?) be different.

Thoughts from anyone?


Ps, the organizationIdentifier  field also threw me for a loop, but that’s another thread I’ll need to catch up on.

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/20220228/9c390996/attachment-0001.html>

More information about the Smcwg-public mailing list