[Smcwg-public] [External Sender] Re: [EXTERNAL]-Re: Ballot SMC01: Final Guideline for “S/MIME Baseline Requirements”
Adriano Santoni
adriano.santoni at staff.aruba.it
Fri Sep 30 06:27:42 UTC 2022
That's okay for me too.
Adriano
Il 29/09/2022 20:32, Stephen Davidson via Smcwg-public ha scritto:
>
> Hello all:
>
> I merged a PR into the draft this morning reflecting our conversation
> yesterday. In short, any Subject Address info included in the cert
> Subject for the
>
> * Org or Sponsored certificate types is validated according to
> section 3.2.3.
> * Individual certificate types is validated according to section 3.2.4.
>
> See more at https://github.com/cabforum/smime/pull/185/files
>
> Thanks for the dialogue. I think it is useful to clarify this
> language. Please let me know if you think this helps.
>
> Regards, Stephen
>
> *From:* Smcwg-public <smcwg-public-bounces at cabforum.org> *On Behalf Of
> *Clint Wilson via Smcwg-public
> *Sent:* Thursday, September 29, 2022 3:20 PM
> *To:* Pedro Fuentes <pfuentes at WISEKEY.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 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>
> 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> 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> 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> 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
> 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.
>
>
> _______________________________________________
> 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/20220930/a6af20f4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4557 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220930/a6af20f4/attachment-0001.p7s>
More information about the Smcwg-public
mailing list