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

[Stephen Davidson]

Looking further into this:

 

Section 7.1.4.2.2 item (a) includes a table that lays out the CN options by profile type, saying that they must be verified in accordance with the relevant parts of Section 3.2.

 

The reference to section 3.2.3 is part of the next section 7.1.4.2.2 item (b) which lays out options for the O field.

 

Wherever possible I am hotlinking to the closest reference – but as noted earlier, these references are still shifting as we add text or sections to the draft.

 

 

 

From: Doug Beattie <doug.beattie at globalsign.com> 
Sent: Monday, February 28, 2022 12:41 PM
To: SMIME Certificate Working Group <smcwg-public at cabforum.org>; Stephen Davidson <Stephen.Davidson at digicert.com>
Subject: Individual's names in S/MIME certificates

 

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 7.1.4.2.2 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.

 

 

Question:

 

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?

 

Doug

 

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

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220301/ad65760c/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/20220301/ad65760c/attachment-0001.p7s>