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

Tue Mar 1 13:08:57 UTC 2022

Hi Stephen and Doug,

I also think that in Enterprise RA case we should have some way to put name details (in some field) with less validation rigor/auditing.

In current Telia CA SMIME certificates we have let Enterprise RA to use CN value quite freely. I hope the new SMIME standard would have that kind of option also. Today we have divided subject attributes so that CN represents individual employee based on Enterprise RA information and O,C represent the company information verified by CA something like this:

CN=John Smith, O=Telia Finland Oyj, C=FI or
CN=Help Desk, O=Telia Finland Oyj, C=FI

Is there a way to continue this kind of subject formatting in any of the new SMIME options? I don’t think that it is essential that CN value in SMIME certificates must be absolutely correct and guaranteed by CA. Other attributes like Surname, Givenname, Title could be verified/audited somehow by CA but CN could have more freedom.

Best Regards
Pekka

From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Stephen Davidson via Smcwg-public
Sent: maanantai 28. helmikuuta 2022 22.59
To: Doug Beattie <doug.beattie at globalsign.com>; SMIME Certificate Working Group <smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] Individual's names in S/MIME certificates

Hi Doug:

Thanks for continuing the dialogue – we’ll return to the below points on our normal call this week on Wed March 2.  I hope members with particular interest will join the call.

Agenda to follow.

NAMES

For individuals, the intent is for Enterprise RA records to be usable as authoritative records for the Sponsor-validation cert profiles, as described in 3.2.4.1<https://github.com/cabforum/smime/blob/preSBR/SBR.md#3241-attribute-collection-of-individual-identity>

4. From Enterprise RA records:  In the case of Sponsor-validation certificates approved by an Enterprise RA, records maintained by the Enterprise RA shall be accepted as evidence of individual identity. The Enterprise RA MUST maintain records to satisfy the requirements of Section 8.8.

For individuals, the draft S/MIME BR does not require a full legal name at this time.  The description as it stands is for verified names “which should be current names” based on ID.

For generic names like “Help Desk”, I was reminded that in the chartering discussions for the WG, it was intended that Organisations would be able to “name” machine certs or accounts under the S/MIME BR.

AUDIT

As noted in our conversation at the F2F, we need to find the appropriate level of internal audit oversight to describe in section 8.8.  There is a level of internal audit by the CA of certificates it issues –  but the appropriate supervision of Enterprise RAs probably has different requirements.  The WG would welcome feedback on possible text for this requirement.

SECTION REFERENCES

You are correct – as noted at the beginning of the doc, some of the section references within the doc are still incorrect from the shifting tides of edits.  Will fix!

Again, thanks for engaging on this point.  We know Enterprise RAs are important and certainly want to get the standard right in this area.

Very best, Stephen

From: Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>
Sent: Monday, February 28, 2022 12:41 PM
To: SMIME Certificate Working Group <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>>; Stephen Davidson <Stephen.Davidson at digicert.com<mailto: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.

This email may contain information which is privileged or protected against unauthorized disclosure or communication. If you are not the intended recipient, please notify the sender and delete this message and any attachments from your system without producing, distributing or retaining copies thereof or disclosing its contents to any other person.

Telia Company processes emails and other files that may contain personal data in accordance with Telia Company’s Privacy Policy<https://www.teliacompany.com/en/about-the-company/privacy/>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220301/4502bfb7/attachment-0001.html>