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

Thu Feb 16 21:50:45 UTC 2023

Well, I made two points.  One is that it’s difficult, but I don’t see any problem overcoming those difficulties.  Be careful with the argument you are making about delegation, because it doesn’t end with the result you want.  If a CA is delegating its audit-relevant duties, then the party being delegated to needs to be within audit scope.  Do you really want to have to include all your relevant customer’s ERAs in your audit?  That’s the sort of thing Stephen is helpfully trying to guide you away from.  The individual use case is much easier because the validation is typically done entirely by a CA, with no RA involvement.

But the other point I made is more important: there doesn’t seem to be much appetite for this work.  It seems like a waste of time to discuss the technical, implementation, and compliance details unless we can get consensus that this is a problem worth solving.  If it does indeed have a chance of passing, then sure, let’s get some people together and see what we can do about figuring out the details for a post-1.0 ballot, but I don’t want people to get too excited unless the review how these discussions went last time.  Because doing that all again and ending up in the same spot doesn’t sound like much fun.

-Tim

From: Pedro FUENTES <pfuentes at WISEKEY.COM> 
Sent: Thursday, February 16, 2023 4:33 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: SMIME Certificate Working Group <smcwg-public at cabforum.org>; Stephen Davidson <Stephen.Davidson at digicert.com>
Subject: Re: [Smcwg-public] [EXTERNAL]- Clarifications on Section 1.3.2.1

Hey Tim,

Although I appreciate your detailed answer, I must say that I still disagree. 

For me the base problem is to identify if this case refers to 1.3.2 or to 1.3.2.1. If we take as reference the delegation of duties that is accepted in 1.3.2, these constraints about the domain validation methods useable by an ERA are basically an artifact.

The uncertainties that you evoque would apply eventually to individual-validated certificates if the identity validation was not properly linked to the mailbox validation. And my position here would be that if linking the individual identity to the mailbox is acceptable, then it must be equally acceptable linking the professional identity, as long as the validation process is dutifully executed and documented… and again, let’s always keep in sight the wording of 1.3.2 and the fact that delegation of these duties is acceptable… if the problem is that we don’t know how to manage such delegation, it should be just disallowed. 

I basically understand you say that this was left as is “because is difficult”… which is indeed an acceptable risk management approach, but not the kind I like. :)

Best,

Pedro

Le 16 févr. 2023 à 21:46, Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > a écrit :

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 <mailto: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 <mailto:Stephen.Davidson at digicert.com> >
Cc: SMIME Certificate Working Group <smcwg-public at cabforum.org <mailto: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

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
 <mailto:Smcwg-public at cabforum.org> 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=

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  <https://urldefense.proofpoint.com/v2/url?u=https-3A__url.avanan.click_v2_-5F-5F-5Fhttp-3A_www.wisekey.com_-5F-5F-5F.YXAzOmRpZ2ljZXJ0OmE6bzpkYTNmNGIwZWVhMzU2NDdkMzAyYzZkYTEyZmJhODFhNTo2OjU3ZWU6NThjMmUwYzMxZDJlNTBjMWU3NGNiMjA1MDM3ZDFiYjU3MzQ2MjU2ZjIwYmRhOTcxYmYzMjRiYWQzYmUwZWMyOTpoOkY&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=eAcAJg7itXZRmAlXshymUW0TZ5HnBHQtF21zSfT5h5s&m=fKELGEHvTuq_R7WMi8WX60yYC2s9zYZfcuhr54XHRXk&s=17cImqXCX3Tx-jkxcksaMO_0u_cvPl0Lm4GL037JT4U&e=> WISeKey