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

Tue Oct 24 09:43:00 UTC 2023

Hi Dimitris,

The definition for sponsor-validated refers to individual attributes but not individual identity information at the moment. 

My perspective is that there are use cases where the email can be considered an individual attribute.

I suggest we further discuss this on our next WG call.

Christophe

From: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr> 
Sent: Tuesday, October 24, 2023 10:38 AM
To: Christophe Bonjean <christophe.bonjean at globalsign.com>; SMIME Certificate Working Group <smcwg-public at cabforum.org>; Adriano Santoni <adriano.santoni at staff.aruba.it>; Ashish Dhiman <ashish.dhiman at globalsign.com>; Martijn Katerbarg <martijn.katerbarg at sectigo.com>
Subject: Re: [Smcwg-public] [External Sender] RE: RE: Re: Re: Re: SV certificates devoid of individual attributes

Hi Christophe, please allow me to jump in the conversation,

According to the early discussions and the intent of the Sponsored Validated profile, the SV (Enterprise RA) is only allowed to validate the identity of the individual, even for the legacy profile, and add that information in the S/MIME Certificate under the SV-Legacy profile.

Your use case does not include any identity information of an individual in the final SV-legacy end-entity S/MIME Certificate. Identity information (first and last name) can be conveyed only via the specific attributes in the subject of the certificate, namely givenName, surname and commonName. If the CA chooses to use the commonName attribute to include the identity of the individual associated with an organization (sponsor), then the CA should add "John Doe" in the commonName, that's ok. However, if the CA wants to use the commonName attribute to include an email address to convey the identity information, then I believe this can be challenged because it will be very difficult to find an official name in an official identity document with the value  <mailto:john.doe at example.com> "john.doe at example.com".

With that said, I agree with Adriano that a certificate with a subject of "C=XX, O=Example Inc., CN=john.doe at example.com <mailto:CN=john.doe at example.com> " does not match the expectations of the Sponsored Validation profile because the Sponsor has no identity to validate :)

Best regards,
Dimitris.

On 24/10/2023 11:14 π.μ., Christophe Bonjean via Smcwg-public wrote:

Hi Adriano,

There’s no definition to support that a mailbox address is an individual attribute in all cases, but as you indicated there are circumstances where it is (i.e. If the Subscriber or the Enterprise RA assert this is a mailbox address for an individual). I'm not convinced that this is sufficient reason to ban it completely.

Although the purpose might be to align with the definition, we are changing the permitted contents of the CommonName, which is a significant change. I also think it’s up to the wider community to indicate whether this is a niche use case, before we consider this a fact.

Can we put this on the agenda for further discussion?

Christophe

From: Adriano Santoni  <mailto:adriano.santoni at staff.aruba.it> <adriano.santoni at staff.aruba.it> 
Sent: Tuesday, October 24, 2023 9:43 AM
To: Christophe Bonjean  <mailto:christophe.bonjean at globalsign.com> <christophe.bonjean at globalsign.com>; SMIME Certificate Working Group  <mailto:smcwg-public at cabforum.org> <smcwg-public at cabforum.org>; Ashish Dhiman  <mailto:ashish.dhiman at globalsign.com> <ashish.dhiman at globalsign.com>; Martijn Katerbarg  <mailto:martijn.katerbarg at sectigo.com> <martijn.katerbarg at sectigo.com>
Subject: Re: [External Sender] RE: [Smcwg-public] RE: Re: Re: Re: SV certificates devoid of individual attributes

Hi Christophe,

frankly, it seems obvious to me that an email address is not, generally speaking, an individual attribute. Would you argue that info at example.com <mailto:info at example.com>  is a natural person's attribute? It may be so in specific cases (for example when it is of the type givenname.surname at example.com <mailto:givenname.surname at example.com>  and the email service provider applies a rule that ensures proper attribution to users and disambiguation of similar names), but it certainly is not so by definition. 

Evidently a natural person (or more likely more than one) can have access to the mailbox at an address like info at example.com <mailto:info at example.com> , but it is evident that such address is not specific to any particular natural person in the same sense and in the same way in which givenname and surname are attributes of a natural person.

And no, no intent at all to modify the SV profile; quite the opposite: to respect its definition even in the legacy case (where among other things, the needs of niche use cases can very well be satisfied by OV certificates).

Adriano

Il 24/10/2023 09:25, Christophe Bonjean ha scritto:

Hi Adriano,

>From your proposed change, it seems that you are not considering a mailbox address as an individual (natural person) attribute? Could you provide some context on that?

We should also keep in mind the initial purpose of the legacy profile. Even though the suggestion of using an OV profile for CN=email, O=Company might be sensible, we’re still fundamentally modifying the legacy SV profile.

Christophe

From: Smcwg-public  <mailto:smcwg-public-bounces at cabforum.org> <smcwg-public-bounces at cabforum.org> On Behalf Of Adriano Santoni via Smcwg-public
Sent: Friday, October 20, 2023 10:33 AM
To: Ashish Dhiman  <mailto:ashish.dhiman at globalsign.com> <ashish.dhiman at globalsign.com>; SMIME Certificate Working Group  <mailto:smcwg-public at cabforum.org> <smcwg-public at cabforum.org>; Martijn Katerbarg  <mailto:martijn.katerbarg at sectigo.com> <martijn.katerbarg at sectigo.com>
Subject: Re: [Smcwg-public] [External Sender] RE: Re: Re: Re: SV certificates devoid of individual attributes

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 <mailto:department at example.com>  or ashish.dhiman at globalsign.com <mailto: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 <mailto: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 <mailto:department at example.com>  in sponsor profile as email address and also use ashish.dhiman at globalsign.com <mailto: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  <mailto:smcwg-public-bounces at cabforum.org> <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  <mailto:martijn.katerbarg at sectigo.com> <martijn.katerbarg at sectigo.com>; SMIME Certificate Working Group  <mailto:smcwg-public at cabforum.org> <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  <mailto:smcwg-public-bounces at cabforum.org> <smcwg-public-bounces at cabforum.org> on behalf of Adriano Santoni via Smcwg-public  <mailto:smcwg-public at cabforum.org> <smcwg-public at cabforum.org>
Date: Monday, 16 October 2023 at 18:09
To: smcwg-public at cabforum.org <mailto:smcwg-public at cabforum.org>   <mailto:smcwg-public at cabforum.org> <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 <mailto: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 <mailto:Smcwg-public at cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/smcwg-public

_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org <mailto: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/20231024/32590e4a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8477 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20231024/32590e4a/attachment-0001.p7s>