[Smcwg-public] [EXTERNAL]- Clarifications on Section 1.3.2.1

Thu Feb 16 20:45:55 UTC 2023

I think this is heading in the wrong direction.

I explicitly brought this use case to the S/MIME group’s attention on two occasions during drafting.  An example, for clarity, is the email address timfromdigicert at gmail.com<mailto:timfromdigicert at gmail.com> that is associated with the organization DigiCert.  As you note, the email address control could be done via challenge response or other acceptable email address validation procedures, and the identity and organizational vetting could also be done in the standard way.  This allows CAs to vet that this is an email address that is associated with that person and an organization, which is information that otherwise is difficult or impossible for a relying party to obtain.  And hence I think allowing such certificates might actually be useful.

However, the consensus of the vast majority of the working group was not to allow this use case, and so the version 1.0 that we voted on does not allow it.  And since, as a matter of policy, WG members didn’t want to allow this use case, it wasn’t further explored.  It can be made to work, but you would in fact have to have guardrails to make sure the identity linkage is verified correctly, with proper coordination between the two parties, one of whom is under audit and one of whom subject to requirements that are intentionally far less invasive (because it’s an enterprise customer).  Even after coming up with some procedures to allow verification that the person who demonstrated email control to the CA and identity to the RA are the same person, you would indeed face difficult questions about whether the controls on the RA are sufficient in order for it to safely participate in this complicated cross-organization validation process.

If people want to try to figure out how the audit and compliance requirements need to be written in order to validate such a certificate, it is possible to do so and a ballot could be proposed to enhance the SMBRs with the appropriate procedures and controls.  But it wasn’t omitted as an oversight, and adding it isn’t as simple as adding a sentence saying “hey, and you can also validate email addresses using 3.2.2.2 for the .1 and .3 profiles.”  That won’t work, because you have failed to establish that the independently validated subject attributes belong to the same subject, and instead have the validation spread across two entities, one of which isn’t even subject to a full third part audit.

So yes, it can be done, but first, the majority of the working group has to be convinced that the effort to develop requirements in this area is even desired.  And as I noted above, both times I brought it up, the reception was rather cold.

-Tim

From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Pedro FUENTES via Smcwg-public
Sent: Thursday, February 16, 2023 1:14 PM
To: Stephen Davidson <Stephen.Davidson at digicert.com>
Cc: SMIME Certificate Working Group <smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] [EXTERNAL]- Clarifications on Section 1.3.2.1

Stephen,
An ERA is always constrained to one or more prevalidated organizations, and the domain validation (whatever the method chosen) is responsibility of the CA. And I said that if the ERA can’t prove control on the whole domain then 3.2.2 is required, which is also a responsibility of the CA that can’t be delegated. This is NEVER giving full rights to an ERA that could allow them to act as a full RA.

Can you please elaborate your statement according to the above? What is the unverified information that could end up in a certificate?

Txs

Le 16 févr. 2023 à 18:29, Stephen Davidson <Stephen.Davidson at digicert.com<mailto:Stephen.Davidson at digicert.com>> a écrit :

Hi Pedro:

An Enterprise RA is constrained, and therefore given more leeway in their delegated powers.
The issue with allowing an ERA to combine O identity details with external email domains – without guardrails -- is that it could be misused.
Without the constraints, it’s arguable the Enterprise would in fact have the powers of a full RA and require an audit in accordance with Section 8.
I believe the proposed text accurately describes what the WG agreed upon earlier in the process.

Regards, Stephen

From: Pedro FUENTES <pfuentes at WISEKEY.COM<mailto:pfuentes at WISEKEY.COM>>
Sent: Thursday, February 16, 2023 10:44 AM
To: Stephen Davidson <Stephen.Davidson at digicert.com<mailto:Stephen.Davidson at digicert.com>>
Cc: SMIME Certificate Working Group <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>>
Subject: Re: [EXTERNAL]-[Smcwg-public] Clarifications on Section 1.3.2.1

So I have to go back to my previous question, asking for the motivation to stipulate such limitation.

Demonstrating control on each mailbox is actually stronger than having a general validation for the whole domain, so I don’t see what’s the issue to still allow it.

On 16 Feb 2023, at 15:39, Stephen Davidson <Stephen.Davidson at digicert.com<mailto:Stephen.Davidson at digicert.com>> wrote:

In such case, the recommendation would be for the company to use the Mailbox-validated profile.

Regards, Stephen

From: Pedro FUENTES <pfuentes at WISEKEY.COM<mailto:pfuentes at WISEKEY.COM>>
Sent: Thursday, February 16, 2023 10:20 AM
To: Stephen Davidson <Stephen.Davidson at digicert.com<mailto:Stephen.Davidson at digicert.com>>
Cc: SMIME Certificate Working Group <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>>
Subject: Re: [EXTERNAL]-[Smcwg-public] Clarifications on Section 1.3.2.1

Sorry, but I think you don’t see my point here...

Imagine the following situation… There’s a company, “XYZ, Co.” With 50 employees, but they use gmail accounts.

Why can’t we give them rights to operate an ERA that entitles them to issue certificates containing the pre-validated O, ST, C fields in the subject name, and still use gmail accounts, if we allow 3.2.2.2, control on each individual mailbox is verified by the CA?

P

On 16 Feb 2023, at 15:14, Stephen Davidson <Stephen.Davidson at digicert.com<mailto:Stephen.Davidson at digicert.com>> wrote:

Hi Pedro:

Half joking, I assert that assumptions carry little weight in compliance.

The ERA is delegated RA power to “issue certs for its internal users” containing identity information. The boundaries for its internal users are email domains it either controls or is authorized to use.  Thus the reference to 3.2.2.1 and 3.2.2.3 which make that link between the ERA and the domain.

3.2.2.2 only verifies mailbox control – not the entire domain – so may be used for Mailbox-validated certificates which contain no identity information in the Subject.

Best, Stephen

From: Pedro FUENTES <pfuentes at WISEKEY.COM<mailto:pfuentes at WISEKEY.COM>>
Sent: Thursday, February 16, 2023 10:03 AM
To: Stephen Davidson <Stephen.Davidson at digicert.com<mailto:Stephen.Davidson at digicert.com>>
Cc: SMIME Certificate Working Group <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>>
Subject: Re: [EXTERNAL]-[Smcwg-public] Clarifications on Section 1.3.2.1

Hi Steven
Although I understand the practical reason for assuming that the domain would be linked to the referenced org, I don’t understand the motivation for making this a compliance requirement.
Could you please explain the choice for the “must” here?
BR/P

On 16 Feb 2023, at 14:55, Stephen Davidson <Stephen.Davidson at digicert.com<mailto:Stephen.Davidson at digicert.com>> wrote:

Hi Pedro:

The purpose of Section 1.3.2.1 is to describe the delegation from the CA to an Enterprise RA (ERA) for “internal” certs issued to domains controlled by the ERA.

  1.  As the `Organization-validated` or `Sponsor-validated` profiles contain identity information, the entire email domain must be linked to the referenced org using 3.2.2.1 or 3.2.2.3.
  2.  As the `Mailbox-validated` profile contains no identity info, 3.2.2.2 may alternatively be used to affirm the certificate holder has control over the mailbox.
Sure, the CA can additionally deploy 3.2.2.2 for `Organization-validated` or `Sponsor-validated` profiles if it wishes, but only in addition to 3.2.2.1 or 3.2.2.3.

We added a reference to “external” certs in Section 1.3.2.1 as well to make it clear that ERAs issuing to emails not on their domains should be using the `Mailbox-validated` profile.

Regards, Stephen

From: Pedro FUENTES <pfuentes at WISEKEY.COM<mailto:pfuentes at WISEKEY.COM>>
Sent: Thursday, February 16, 2023 5:37 AM
To: Stephen Davidson <Stephen.Davidson at digicert.com<mailto:Stephen.Davidson at digicert.com>>
Cc: SMIME Certificate Working Group <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>>
Subject: Re: [EXTERNAL]-[Smcwg-public] Clarifications on Section 1.3.2.1

Hi Stephen,
Actually this is not what I was pointing, as I was mentioning that I failed to see why the ERA can’t use 3.2.2.2 also to validate the email address for `Organization-validated` or `Sponsor-validated` profiles. It’s clear that this would be uncommon, but the current wording would disallow that.

I’d say that what the intent here is to ensure that 3.2.2.1 and 3.2.2.3 are only used for domains that are "under control" of the ERA, but I have the feeling that the way this is worded is overcomplicating it.

If we think in an ERA in the context of TLS, nothing stops the ERA to issue DV certificates for ANY whole domain once the control has been appropriately demonstrated (e.g. DNS Change or other acceptable methods), and in the TLS BR there’s no such complexity, because the validation of domains and validation of identity are clearly separated. And the TLS BR is not considering such concept of “control” (as this is a tricky point as Martijn just pointed out while I was writing this).

I’d have to think about this, but I wonder if we could find a way to reformulate all this, because at the end the idea is that if the organization name or any other identity attribute appears in the certificate, it needs to be appropriately validated according to the BR, and making these differences we see in the S/MIME BR on the validations to be done depending on the certificate profile and linking it to the domain validation, I’d say is making all quite more complex… and BTW, these are one of the reasons we couldn’t vote “Yes” in the ballot, because I still see too many things we can’t properly grasp.

So, in very blunt words that would need tons of polishing…
- The CA may delegate to the RA issuance to any email address in a particular domain if the RA can prove control via 3.2.2.1 or 3.2.2.3
- If the RA can’t prove control on the whole domain through the above methods, then 3.2.2.2 method is required to validate each individual email address

And the above would be independent on the certificate profile or domain ownership, because the identity attributes must anyway be validated, but I’m taking here about the domain/email validation only.

My 2 cents...

BR/P

On 16 Feb 2023, at 00:23, Stephen Davidson <Stephen.Davidson at digicert.com<mailto:Stephen.Davidson at digicert.com>> wrote:

Hi Pedro:

I see.  So what you are describing is something like this?
Thanks for the feedback.

Best, Stephen

The CA MAY delegate to an Enterprise Registration Authority (RA) to verify Certificate Requests from the Enterprise RA's own organization. The CA SHALL NOT accept Certificate Requests authorized by an Enterprise RA unless the following requirements are satisfied:

1. If the Certificate Request is for a `Mailbox-validated` profile, the CA SHALL confirm that the Enterprise RA has authorization or control of the requested email domain(s) in accordance with [Section 3.2.2.1](#3221-validating-authority-over-mailbox-via-domain), [Section 3.2.2.2](#3222-validating-control-over-mailbox-via-email) or [Section 3.2.2.3](#3223-validating-applicant-as-operator-of-associated-mail-servers).

2. If the Certificate Request is for an `Organization-validated` or `Sponsor-validated` profile, the CA SHALL confirm that the Enterprise RA has authorization or control of the requested email domain(s) in accordance with [Section 3.2.2.1](#3221-validating-authority-over-mailbox-via-domain) or [Section 3.2.2.3](#3223-validating-applicant-as-operator-of-associated-mail-servers).

3. The CA SHALL confirm that the `subject:organizationName` name is either that of the delegated enterprise, or an Affiliate of the delegated enterprise, or that the delegated enterprise is an agent of the named Subject. For example, the CA SHALL NOT issue a Certificate containing the Subject name "XYZ Co." on the authority of Enterprise RA "ABC Co.", unless the two companies are Affiliated as defined in [Section 3.2](#32-initial-identity-validation) or "ABC Co." is the agent of "XYZ Co". This requirement applies regardless of whether the accompanying requested email domain falls within the subdomains of ABC Co.'s Registered Domain Name.

The CA SHALL impose these limitations as a contractual requirement on the Enterprise RA and monitor compliance by the Enterprise RA in accordance with [Section 8.8](#88-review-of-delegated-parties).

An Enterprise RA MAY also submit Certificate Requests using the `Mailbox-validated` profile for users whose email domain(s) are not under the delegated organization’s authorization or control.  In this case, the CA SHALL confirm that the mailbox holder has control of the requested Mailbox Address(es) in accordance with [Section 3.2.2.2](#3222-validating-control-over-mailbox-via-email).

From: Pedro FUENTES <pfuentes at WISEKEY.COM<mailto:pfuentes at WISEKEY.COM>>
Sent: Wednesday, February 15, 2023 5:49 PM
To: Stephen Davidson <Stephen.Davidson at digicert.com<mailto:Stephen.Davidson at digicert.com>>; SMIME Certificate Working Group <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>>
Subject: Re: [EXTERNAL]-[Smcwg-public] Clarifications on Section 1.3.2.1

Hello,
I missed today’s call, but as I commented by chat in the last call the main issue was that old “No 2” was a general statement for RAs issuing `Mailbox-validated` profile, without discriminating “internal” or “external” users, so the intent, as reflected in the wording of V1.0.0 was totally different to what is stated now.

Said that, the new wording is much closer to what we’d have liked to see there in the first version, but I fail to understand why the ERA can’t use 3.2.2.2 also for domains they control, if they wish to do so.

BR/P

On 15 Feb 2023, at 22:16, Stephen Davidson via Smcwg-public <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>> wrote:

Hello:

As discussed on the call today, here are some edits to clarify the text in Section 1.3.2.1 regarding Enterprise RA.

https://github.com/srdavidson/smime/commit/49bacdf09b3bb3b27a78ece305ec08987cbd026f<https://url.avanan.click/v2/___https:/urldefense.proofpoint.com/v2/url?u=https-3A__github.com_srdavidson_smime_commit_49bacdf09b3bb3b27a78ece305ec08987cbd026f&d=DwMFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=WYfdoRzScaol1-kBJZN-eB_a3JYZXE66C6fSI19dnM4&s=NHMBpU9z__vB4mxuRsqTnGQi4UXorb-GvjEdJh7HL0I&e=___.YXAzOmRpZ2ljZXJ0OmE6bzpkYTNmNGIwZWVhMzU2NDdkMzAyYzZkYTEyZmJhODFhNTo2OmMzZGM6NTBjOTFmYzgzOTYzNDMzMjgzNzViYjRhNzI0ZGFmNTQ3Mjk4ODg4OGFhZGU3NmY3YTQ0NzU3MDA5MWRlOWNkOTpoOkY>

To wit:

•       The ERA may issue `Mailbox-validated`, `Organization-validated` or `Sponsor-validated` profiles to email domains they control (i.e., “internal”) using Section 3.2.2.1 (TLS BR methods) or Section 3.2.2.3 (DNS method)

•       The ERA may request  `Mailbox-validated` profiles for email domains they do NOT control (i.e., “external”) with the CA using Section 3.2.2.2 (mailbox control)

I do not believe this text changes the intent of the existing v1.0.0 but rather presents a clearer description.

Feedback is welcomed; otherwise this will be included in an eventual cleanup ballot.

Regards, Stephen
_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org<mailto:Smcwg-public at cabforum.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=WYfdoRzScaol1-kBJZN-eB_a3JYZXE66C6fSI19dnM4&s=ovVhqoYDOBq5cU7-2M83J1hqeqx2y783SNtJ5c7QBU8&e=<https://url.avanan.click/v2/___https:/urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=WYfdoRzScaol1-kBJZN-eB_a3JYZXE66C6fSI19dnM4&s=ovVhqoYDOBq5cU7-2M83J1hqeqx2y783SNtJ5c7QBU8&e=___.YXAzOmRpZ2ljZXJ0OmE6bzpkYTNmNGIwZWVhMzU2NDdkMzAyYzZkYTEyZmJhODFhNTo2OjFhMGE6NTdlYWUwZmQ1ZmE4NWUzZTFkMDk1MDk5MjQ0MzUzZDAxOWQ2OTUwNDVjMzA1NDIxNTYxNTZjNDcxZjg5MDJmMDpoOkY>

WISeKey SA
Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790
Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
Stay connected with WISeKey<https://url.avanan.click/v2/___http:/www.wisekey.com/___.YXAzOmRpZ2ljZXJ0OmE6bzpkYTNmNGIwZWVhMzU2NDdkMzAyYzZkYTEyZmJhODFhNTo2OjU3ZWU6NThjMmUwYzMxZDJlNTBjMWU3NGNiMjA1MDM3ZDFiYjU3MzQ2MjU2ZjIwYmRhOTcxYmYzMjRiYWQzYmUwZWMyOTpoOkY>