[cabf_validation] Proposed Update to EV to include OrganisationIdentifier as per ETSI standard

[Dimitris Zacharopoulos]

On 12/6/2018 11:35 μμ, Ryan Sleevi wrote:
>
>
> On Tue, Jun 12, 2018 at 3:14 PM, Dimitris Zacharopoulos 
> <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>> wrote:
>
>     [snip]
>
>     We may not have unanimous agreement on this topic which means that
>     if other members feel very strong about this proposal (HARICA does
>     not), they could proceed with a ballot and risk a possible vote
>     failure or a majority pass. It will not be the first time.
>
> I think that's actively detrimental towards the goal of finding a 
> solution, and could just as easily result in browsers changing to 
> explicitly reject certificates with organizationIdentifiers from being 
> publicly trusted, if their validation fails to meet sufficient goals.
>

No one wants to have improperly validated information in PTCs (that goes 
for all certificate types). If we include an organizationIdentifier it 
must be properly validated with language that will address this issue at 
a global scale and not just European jurisdictions. RPs can't make trust 
decisions based on not properly validated information.

> I appreciate your arguments in favor, but you've not really addressed 
> the meaningful criticisms. I agree that we may be going in circles at 
> this point, and it may be that simply adopting whatever ETSI says is 
> good to adopt is a viable solution for HARICA, but it doesn't seem 
> viable for the Web at large.
>

I've tried to address all criticisms (meaningful or other) and provide 
HARICA's point of view, I think that was obvious :)  We should certainly 
not adopt whatever ETSI or any other STO says without some evaluation 
and examination of whether they are compatible with existing CA/B Forum 
policies and practices. For this particular case, HARICA believes it is 
a compatible and fair proposal, in-line with existing requirements in 
the EV Guidelines thus, as viable for the web at large as the rest of 
the existing requirements.


> Could you help clarify: What do you find deficient in the two viable 
> technical alternatives that are proposed that resolve all complaints.

Sure. Other than the fact that I expect unique and validated information 
that uniquely binds with the Subject to be included in the subjectDN 
extension, which I believe covers the spirit and the description of the 
X.520 organizationIdentifier attribute, I find adding the other 2 
proposed solutions to be inferior because:

  * For adding this information (the actual organizationIdentifier
    value) in the qcStatements extension:
      o it is a much more complicated solution which requires adding
        complicated technical language in the requirements (thus
        susceptible to errors during implementation) about how the
        qcStatements is structured, its ASN.1 syntax, references to at
        least 3 external documents, and possibly more for no real added
        value. Adding it in the subjectDN and using an existing OID from
        X.520 sounds a lot simpler.
      o qcStatements is more of an "ETSI" thing. They were introduced
        with Qualified Certificates for digital signatures and expanded
        for QWACs. It would be very hard to bring requirements about
        qcStatements in the CA/B Forum documents and keeping them
        aligned with the ETSI requirements as they are modified. I have
        already seen many bad implementations of TSPs trying to get the
        ETSI requirements for qcStatements for eSignatures right.
      o existing ETSI documents that describe qcStatements do not
        include information directly linked with the Subject of the
        Certificate. They only include secondary information like
        semanticsIdentifiers, links to PKI Disclosure Statement
        documents, signals about the certificate type (whether it is for
        eSign, eSeal, QWAC), information about retention period,
        information about liability limits and that sort. It would be a
        first to include subject information in the qcStatements and
        would require a lot of discussion and analysis of RFC 3739 and
        definitely an update in ETSI documents to allow for this. For
        me, this doesn't justify all this effort.
  * For creating a new "ETSI" OID under some arc, like it happened with
    the JoI which is under Microsoft's arc and adding that in the subjectDN:
      o it feels like re-inventing the wheel because we already have a
        very well defined and suitable OID (2.5.4.97) in X.520
      o it would require creating definitions and syntax/encoding rules
        for the new OID which is a challenge to get right from the beginning
      o this OID would have to be adopted by other existing non-SSL but
        publicly trusted certificates, several requirements documents
        would have to be ammended where the use of the
        organizationIdentifier attribute is already very well defined,
        structured and already in use in other Certificate Types
        (eSignatures, eSeals). It already serves existing policy
        decisions about how to uniquely identify a Natural Person or
        Legal Entity in an unambiguous, globally identifiable way and
        would require modifying several other standards if a new OID
        would be adopted. It would be great to allow some compatibility
        between PTCs for SSL and non-SSL so that TSPs that want to
        handle both cases are not overly confused.


> Could you indicate why, besides that's not what Nick asked for 
> (noting, most importantly, that the status quo does *not* apply to 
> PTCs, as clearly stated), you find those problematic?
>

I am not sure I understand your question about the status quo not 
applying to PTCs. Do you mean that mr. Pope said that his request does 
not apply to PTCs? I understood the opposite.

> It doesn't feel like the conversation is moving, if viable 
> alternatives are being ignored and not even responded to. I feel like 
> I'm doing all I can to help find a solution here, but please help me 
> understand why you feel that's not possible.

This is a bit unfair. I think the conversation went very well so far and 
the alternatives were definitely responded to. I can't speak for others 
but I think the members should have a clear view of the pros and cons of 
each position. For what it's worth, I think there are good arguments for 
both positions. I guess it's up to the proposer to evaluate all this 
input and decide how to move forward (or not).

Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180613/18bae789/attachment.html>