[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