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

Thu Feb 16 14:56:14 UTC 2023

I may be misunderstanding the question here -
But if Pedro is suggesting that an ERA has validated O, ST, C fields that
they would like to be included in the subject name, and still use gmail
accounts, If the mailbox-validated method is used to validate the mailbox,
according to the profiles  O, ST, C fields are not allowed to be in the
certificate, even though in theory they were validated.

Thanks,

Wendy

Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)

On Thu, Feb 16, 2023 at 9:45 AM Pedro FUENTES via Smcwg-public <
smcwg-public at cabforum.org> wrote:

> 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>
> 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>
> *Sent:* Thursday, February 16, 2023 10:20 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
>
> 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>
> 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>
> *Sent:* Thursday, February 16, 2023 10:03 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
>
> 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>
> 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>
> *Sent:* Thursday, February 16, 2023 5:37 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
>
> 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>
> 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>
> *Sent:* Wednesday, February 15, 2023 5:49 PM
> *To:* Stephen Davidson <Stephen.Davidson at digicert.com>; SMIME Certificate
> Working Group <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> 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
>
> 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.
>
> _______________________________________________
> Smcwg-public mailing list
> Smcwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20230216/6c045ff8/attachment-0001.html>