[Smcwg-public] [EXTERNAL]- Clarifications on Section 1.3.2.1
Stephen Davidson
Stephen.Davidson at digicert.com
Thu Feb 16 17:28:51 UTC 2023
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>
Sent: Thursday, February 16, 2023 10:44 AM
To: Stephen Davidson <Stephen.Davidson at digicert.com>
Cc: SMIME Certificate Working Group <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.
* 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.
* 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://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=>
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=
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<http://www.wisekey.com/>
THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks
CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender
DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.
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<http://www.wisekey.com/>
THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks
CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender
DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.
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<http://www.wisekey.com/>
THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks
CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender
DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.
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<http://www.wisekey.com/>
THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks
CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender
DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.
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<http://www.wisekey.com>
THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks
CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender
DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20230216/0239bc19/attachment-0001.html>
More information about the Smcwg-public
mailing list