[Servercert-wg] Ballot SC17 version 7: Alternative registration numbers for EV certificates

[Adriano Santoni]

Thank you both, now I see more clearly the line of reasoning that 
brought to the current text.

Adriano


Il 09/05/2019 16:26, Tim Hollebeek ha scritto:
>
> Yup, that’s a good summary of how we got here.
>
> The only other thing that I’d add is that the ballot also gives CAs a 
> reasonable amount of time to implement this new extension (it isn’t 
> mandatory until next year).
>
> -Tim
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf 
> Of *Ryan Sleevi via Servercert-wg
> *Sent:* Thursday, May 9, 2019 10:19 AM
> *To:* Adriano Santoni <adriano.santoni at staff.aruba.it>; CA/B Forum 
> Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] Ballot SC17 version 7: Alternative 
> registration numbers for EV certificates
>
> On Thu, May 9, 2019 at 5:11 AM Adriano Santoni via Servercert-wg 
> <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>> wrote:
>
>     Hello Tim, Dimistris,
>
>     I probably missed some posts to the list, as I just realized that
>     this ballot (since version 4) mandates inclusion of the new
>     extension CABFOrganizationIdentifier if the
>     subject:organizationIdentifier field is present. Home comes that?
>     I got lost in the discussions...
>
>     That seems exceedingly complex to me, especially as I cannot see
>     its purpose, and implies development work on CA software for
>     implementation of the new CABFOrganizationIdentifier extension.
>
>     Please bear with me and remind me the rationale leading to such a
>     proposal....
>
> Hi Adriano,
>
> I'm not Tim or Dimitris, but I can hopefully shed some insight into this.
>
> This was discussed somewhat during the CA/Browser Forum F2F in 
> Cupertino. The reasoning is that the use of the 
> subject:organizationIdentifier to convey structured information like 
> this is problematic on a number of dimensions, as has previously been 
> shared with our ETSI Liasons. Much like ITU-T and IETF collaborated in 
> the definition of the Subject Alt Name extension, recognizing the 
> inherent problems of the X.500 naming scheme of the Subject in the 
> absence of a global X.500 hierarchy, the extension represents an 
> attempt by the CA/Browser Forum to more collaboratively engage with 
> ETSI on matters of technical expertise. By ensuring that the extension 
> is present, this provides the opportunity for ETSI to, in a future 
> update to its TS set of documents related to PSD2, seemlessly 
> transition from the problematic form of the 
> subject:organizationIdentifier and into the more structured form of 
> the CABFOrganizationIdentifier, without disrupting sites or end users.
>
> By ensuring both are present, we have a system that is compatible with 
> the unfortunate legacy decisions found within the current PSD2 
> profile, while providing a seamless path forward, to a more compliant 
> approach. The approach taken with respect to the 
> CABFOrganizationIdentifier aligns with the approach ETSI has taken in 
> other aspects of its qualifications - ensuring that information is 
> reliably and unambiguously separated, for example - and thus avoids 
> the significant security risks that the approach presently taken by 
> ETSI presents.
>
> Does that help?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190510/77ae1f88/attachment.html>