[cabf_validation] Proposed Update to EV to include OrganisationIdentifier as per ETSI standard
Dimitris Zacharopoulos
jimmy at it.auth.gr
Tue Jun 12 23:04:34 MST 2018
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>
More information about the Validation
mailing list