[Smcwg-public] [External Sender] RE: Re: Re: Re: SV certificates devoid of individual attributes

Fri Oct 20 08:32:49 UTC 2023

Ashish,

my intent would not be to prohibit anything, but rather to make two 
types of certificates (OV, SV) distinguishable that otherwise are not, 
and to make the S/MIME baseline requirements consistent with the 
definition of Sponsor-Validated.

Furthermore, I don't understand why what I'm proposing could cause 
problems for those who need, for their legacy use case, S/MIME 
certificates that simultaneously contain Subject.organizationName AND 
/any type /of email address in the Subject.commonName (like 
department at example.com or ashish.dhiman at globalsign.com to quote your 
examples), plus of course locality and organizationIdentifier. In fact, 
in such use case you can very well use OV-type S/MIME certificates. 
Don't you?

Adriano

Il 20/10/2023 10:20, Ashish Dhiman ha scritto:
> NOTICE: Pay attention - external email - Sender is 
> ashish.dhiman at globalsign.com
>
>
>
> Respected: CA/B – S/MIME Forum Members.
>
> I feel the problem that we are trying to solve by prohibiting email 
> address from CN in Legacy will only make things complex rather than 
> solve it. During our discussion, the intent for legacy, always was to 
> have minimum impact on existing practices and give time for wider 
> industry to move to multipurpose or strict profile. I feel, we are 
> defeating the whole purpose of legacy with suggested change, as I am 
> trying to understand how; eliminating email address from CN will help 
> us differentiate a sponsor profile from organization profile. As, 
> Technically, people can still use department at example.com in sponsor 
> profile as email address and also use ashish.dhiman at globalsign.com in 
> Organization Profile as email address.
>
> On the other hand, this change will also deviate from current 
> practices for CN use for legacy use cases Also, during implementation, 
> we see in most of the cases; email address used in Sponsor profiles 
> are correct.
>
> I think removing email in CN makes legacy no longer like legacy and 
> seems to make it stricter than multi and strict where its allowed. 
> There is also no indication that the intent for changes, will be 
> achieved without mandatory use of Given Name and Sur Name in Legacy 
> profile, which is again a big change considering legacy intent, and 
> make these profiles similar to multi and strict version. Overall, this 
> change seems to defeat its goal of supporting wider ecosystem for a 
> while.
>
> Ashish
>
> *From:* Smcwg-public <smcwg-public-bounces at cabforum.org> *On Behalf 
> Of* Adriano Santoni via Smcwg-public
> *Sent:* Thursday, October 19, 2023 5:00 PM
> *To:* Martijn Katerbarg <martijn.katerbarg at sectigo.com>; SMIME 
> Certificate Working Group <smcwg-public at cabforum.org>
> *Subject:* Re: [Smcwg-public] [External Sender] Re: Re: Re: SV 
> certificates devoid of individual attributes
>
> I have created the pull request below.
>
> https://github.com/cabforum/smime/pull/218
>
> Even if there exists some niche legacy uses cases, I believe it would 
> be highly preferable to avoid allowing SV certificates that do not 
> match the SV definition and are indistinguishable from OV certs. 
> Besides, it appears that in such particular contexts OV certificates 
> would still meet the need.
>
> Looking for endorsers.
>
> Adriano
>
> Il 16/10/2023 18:38, Martijn Katerbarg ha scritto:
>
>     Happy to work with you on that. I do wonder what the cause and
>     original intent behind this was.
>
>     I wonder if they key lies in the Note added to section 7.1.4.2.5:
>
>     “Legacy Generation profiles MAY omit the |subject:givenName|,
>     |subject:surname|, and |subject:pseudonym| attributes and include
>     only the |subject:commonName| as described in Section 7.1.4.2.2(a)
>     <https://github.com/cabforum/smime/blob/main/SBR.md#71422-subject-distinguished-name-fields>.”
>
>     Could it be that the original intent here was that
>     subject:givenName, subject:surname and subject:pseudonym are
>     allowed to be left out, *only* if subject:commonName was included
>     *and* had either the pseudonym or givenName+surname in it?
>
>
>     I could see that as a possible legacy use case, with the intend to
>     deprecate. I’m not sure if any CA needs that use case at current
>     though.
>
>     Regards,
>
>     Martijn
>
>     *From:* Smcwg-public <smcwg-public-bounces at cabforum.org>
>     <mailto:smcwg-public-bounces at cabforum.org> on behalf of Adriano
>     Santoni via Smcwg-public <smcwg-public at cabforum.org>
>     <mailto:smcwg-public at cabforum.org>
>     *Date:* Monday, 16 October 2023 at 18:09
>     *To:* smcwg-public at cabforum.org <smcwg-public at cabforum.org>
>     <mailto:smcwg-public at cabforum.org>
>     *Subject:* Re: [Smcwg-public] [External Sender] Re: Re: SV
>     certificates devoid of individual attributes
>
>     CAUTION: This email originated from outside of the organization.
>     Do not click links or open attachments unless you recognize the
>     sender and know the content is safe.
>
>     I would suggest an amendment in order to correct this unintended
>     result; I'm available to dratf a proposal it if there are any
>     endorsers.
>
>     Adriano
>
>     Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public ha
>     scritto:
>
>         NOTICE: Pay attention - external email - Sender is
>         0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com
>
>
>         I agree it's not a good thing. The SV profile was to support
>         certificates that include attributes of individuals validated
>         by the Enterprise RA. If we allow those to be missing, making
>         it effectively an OV Certificate, seems like an unintended result.
>
>         Best regards,
>
>
>
>
>         _______________________________________________
>
>         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/20231020/55527f26/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4620 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20231020/55527f26/attachment-0001.p7s>