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

Lahtiharju, Pekka pekka.lahtiharju at teliacompany.com
Thu Feb 16 14:55:33 UTC 2023


Hi,

Telia has also customers that Pedro is referring to. I support Pedro’s idea that we would divide RA responsibility in this case so that ERA gives a right to use company’s prevalidated O, ST, C values and CA validates that each user can read their (gmail) mailbox by sending random code to that. If we are restricted to mailbox-validated profile it won’t fit for all current use cases.

Br Pekka

From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Pedro FUENTES via Smcwg-public
Sent: torstai 16. helmikuuta 2023 16.45
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

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.


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/20230216/e33b2db6/attachment-0001.html>


More information about the Smcwg-public mailing list