[Smcwg-public] [EXTERNAL]-Re: Ballot SMC01: Final Guideline for “S/MIME Baseline Requirements”

Thu Sep 29 19:43:03 UTC 2022

Yes, thank you very much for helping make sure we’re all on the same page about the ballot’s intent and interpretation.  These things are tricky to get right.

-Tim

From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Pedro FUENTES via Smcwg-public
Sent: Thursday, September 29, 2022 3:05 PM
To: Clint Wilson <clintw at apple.com>
Cc: SMIME Certificate Working Group <smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] [EXTERNAL]-Re: Ballot SMC01: Final Guideline for “S/MIME Baseline Requirements”

Hi Clint,
I totally agree with your views, and even when this is not impacting us, it’s always good to be sure a rule is endorsed with the right consensus.
BR/P

Le 29 sept. 2022 à 20:20, Clint Wilson <clintw at apple.com<mailto:clintw at apple.com>> a écrit :
Hi Pedro,

There may well be impact to both the ideal wording in the guidelines, and to impacted practices. The goal, as I understand it, is at a high-level to establish a set of requirements which define processes that result in a consistent output of information in a certificate, assuming the same input, regardless of issuing CA. As I understand current practices, achieving this goal will absolutely necessitate some alteration to some implemented practices.

On Sep 29, 2022, at 7:41 AM, Pedro FUENTES <pfuentes at WISEKEY.COM<mailto:pfuentes at WISEKEY.COM>> wrote:

Thanks, Clint. Therefore, your understanding is that the C/ST/L are related always to the O, and not to the person that is getting the certificate. This definitely implies to change the current writing of the guidelines, as we noticed yesterday.

To be in the same page, these examples would be impacted practices:

  *   Company “Foo” is registered in the US. There’s an employee that represents the company sales operation in Mexico, but there’s not Mexican registered company. In this case the employee can’t get a certificate stating “Mexico” as country. His certificate must always include “C=US”
This reflects my understanding.

  *   Company “Bar” is registered in California, USA. There’s an employee working in the Chicago office, but this is just a sales office. All important operations (e.g. Billing) are in California. In this case the employee can’t get a certificate stating “Illinois” as State. His certificate must always include “ST=California, C=US”
That also sounds correct, in most cases. If we add that “Bar” is not registered in Illinois nor Chicago, then I think it becomes correct in all cases.

Are we OK with that?

As I said at the beginning, currently we use the registered address information and this is not an issue for us in particular, but I mostly want to open a discussion to ensure we are all in the same page, and to know what will be eventually forbidden.

BR/P

On 29 Sep 2022, at 15:58, Clint Wilson <clintw at apple.com<mailto:clintw at apple.com>> wrote:

My understanding is as follows: where present, the legal entity identified in the Subject (i.e. the “O” field) is the legal entity used to populate the C, ST, and L fields as well (again, where present). That is, if there is an organization named “Foo”, and it is registered as “Foo” in South Africa, Australia, Germany, and Brazil, then it can use “Foo” as the O, and different certificates could have different C, ST, L values representing that legal entity in South Africa, Australia, Germany, or Brazil. If that same organization had a subsidiary or similar registered as “Bar” in Bulgaria, Japan, and Canada, it could use “Bar” as the O, and different certificates could have the C, ST, and L values related to Bulgaria, Japan, and Canada. “Foo” could not appear with Japan as the country, and “Bar” could not appear with Germany as the country, as those legal entities are not registered in those respective countries.
Would it help to convey the “groupings” of subjectDN values, with the goal of making it clearer what values are being populated with the same base/source data?

On Sep 29, 2022, at 3:55 AM, Pedro FUENTES via Smcwg-public <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>> wrote:

Well… I don’t say that it’s confusing, what I’d say is that “country of operation” is a very vague concept…

You seem to understand that the company needs to have registered offices to operate in a country, but there are companies that operate in countries where they have people working from home (i.e. sales staff).

I don’t think we can assimilate directly concepts of BRSSL here, because in SSL the subscriber is an entity that can be an individual or a company, but there’s a clear and direct relationship between the organization name in the TLS certificates and the subscriber… In the case of SMIME this relationship between the subscriber and the organisation is not so clear at first sight.

Also, we could need to extend this discussion to the ST (and L, eventually), not only to the country.

BR/P

On 29 Sep 2022, at 12:27, Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr<mailto:dzacharo at harica.gr>> wrote:

On 29/9/2022 12:59 μ.μ., Pedro FUENTES wrote:

Txs. Then it could be understood that the country of the employee could be considered as a country where the company operates… I’m OK with that, and I support this interpretation, but this is not what was discussed yesterday, so we should see about the consensus on this topic.

Why is this confusing? The CA must validate that the company operates (i.e. has registered offices) at a certain location. Then, this country can be used in a sponsored validated profile. If an employee is working remotely in a country where the company does not have registered offices, then that country cannot be used in a sponsored validated profile.

Thanks,
Dimitris.

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<mailto:Smcwg-public at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/smcwg-public

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/20220929/c1486f90/attachment-0001.html>