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

[Ryan Sleevi]

On Wed, Jun 13, 2018 at 2:04 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
wrote:

> 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:
>    - 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.
>
> Can you expand on this? We're talking about a green field solution here -
are you saying you don't believe ETSI can specify qcStatements effectively
(despite them already having done so?) I'm not sure why you believe it's a
more complicated solution, considering the specification already does that
in a variety of cases.

>
>    -
>       - 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.
>
> That's not an accurate portrayal. qcStatements are related to the EU SD
(and now eIDAS), for which the audit criteria have always been ETSI
derived. Going the qcStatements route requires *zero* modifications to the
CA/Browser Forum documents.

As such, using qcStatements mean that there is zero effort to keep it
aligned.

As to the second part - CAs having trouble with their core competencies
(understanding and correctly implementing specifications), I certainly have
seen a number of CAs fail at this basic task. However, that's not
necessarily a problem of the specification, nor should certain CA's
incompetence leave us throwing our hands up in the air saying "YOLO" or
assuming they're irredeemably bad.


>    - 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.
>
> Except this is secondary information - this is about identifying
information related to payment processing registries, not about naming the
subject.

It's clear from the specification that this is about naming the subject in
a particular PKI, of which publicly trusted certificates are far more
broader, and thus it no longer represents an accurate subject name. It's
fundamentally an expression of an attribute of the subject (namely, that
they are a payment processor), and not a naming type. I won't ascribe
intellectual laziness for it originally being specified as
organizationIdentifier - in a constrained and limited PKI, it may very well
be a good solution. However, for interacting with publicly trusted
certificates, it is laziness, and we can and should do better.

It is not clear that "ETSI" wants this to begin with. As presented, this is
a request from anticipating that some customers may want to use PTC
certificates (for inappropriate reasons, I will emphasize) and have them
recognized with this private PKI (which is just as bad an idea as having
payment terminals use PTCs, and is fundamentally unsound). It is not at all
unreasonable, and entirely justified, to state that if you are going to try
to merge two different PKIs (a bad idea to begin with), then the requestor
is the one that needs to adapt their specification to not conflict with
PTCs.

As explained in the F2F, this is not a 'serialNumber' type thing either -
that misconception was firmly put to bed by highlighting that this is about
indicating a context regarding a particular registry (namely, a payment
registry). Further, the fundamental design of it - in which it overlays
additional syntactic configuration (the countrycode-hypen-number approach)
that is equally unsound because it forces two different notions of parsing
to extract semantic information (first you parse the single string, then
you parse the string). The design and choice of ASN.1 was explicitly to
avoid this silliness, and practically speaking, is better addressed as two
independent attributes (one to indicate the country the payment processor
registry is operated under, another to indicate the registry number within
that country, in a hierarchal fashion).

It's simply a bad design to begin with, and to overlay with PTCs, it's a
bad design that poses real risks. Since this is a private PKI wanting to
use the public PKI, it's not at all unreasonable to ask for change.

>
>    - 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:
>       - 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
>
> It's not well defined, because you don't have the global DIT, and this
information is specific to a specific niche within certificates. It is not
a suitable OID, fullstop.

>
>    - it would require creating definitions and syntax/encoding rules for
>       the new OID which is a challenge to get right from the beginning
>
> This is trivial. It's a copy-paste job. If you're suggesting CAs have
trouble with ASN.1, or that ETSI does, I can't fault you - certlint
demonstrates that - but that's all the more reason why simply accepting
organizationIdentifier is the wrong thing. Even looking at what it is, it's
multipurposing a textual field with semantic ontologies (namely, it encodes
both the jurisdiction and the identifying information, which requires
secondary text parsing)

>
>    - 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.
>
> I'm sorry, but I'm going to have to ask you to provide a citation here.
For all the information provided by ETSI and Nick Pope, this is
demonstrably false. This is a greenfield approach to new certificates, with
a specific application, and not overlapping with any of these types you
mention. It's specifically for server-to-server authentication using
non-publicly trusted certificates, and the request is to alter the profile
of PTCs to allow this specification to be used unmodified from its limited
context of private PKIs to also use the Web PKI. That's highly undesirable,
as it repurposes a field that is perfectly reasonable for its limited scope
and non-public profile, but wholly inappropriate for a global profile.

I appreciate your clarification of the anticipated difficulty, because that
helps demonstrate how fundamentally wrong that objection is. It seems to
demonstrate either a lack of faith in ETSI or a lack of faith in your CA
colleagues, because for both parties, as such a specification activity
should be as simple as waking up in the morning, because it's such a basic
task of being a CA or being an SDO.

Here's your syntax:
"""
IMPORTS
  UnboundedDirectoryString
  FROM SelectedAttributeTypes {joint-iso-itu-t ds(5) module(1)
selectedAttributeTypes(5) 6}
<https://www.itu.int/ITU-T/formal-language/itu-t/x/x520/2008/SelectedAttributeTypes.html>
;

id-at-etsiPaymentProcessor OBJECT IDENTIFIER ::= {id-someETSIArc x y z}
etsiPaymentProcessor ATTRIBUTE ::= {
 WITH SYNTAX UnboundedDirectoryString
 EQUALITY MATCHING RULE caseIgnoreMatch
 SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
 SINGLE VALUE TRUE
 ID id-at-etsiPaymentProcessor }
"""

(To use the syntax from X.520/2012)

Want it like RFC 5280? Stupid easy:

"""
id-at-etsiPaymentProcessor AttributeType ::= {id-someETSIArc x y z}
etsiPaymentProcessor ::= DirectoryString (SIZE (1..MAX))
"""

Want to avoid the parameterized type? Still stupid easy:
"""
id-at-etsiPaymentProcessor AttributeType ::= {id-someETSIArc x y z}
etsiPaymentProcessor ::= CHOICE {
      teletexString     TeletexString   (SIZE (1..MAX)),
      printableString   PrintableString (SIZE (1..MAX)),
      universalString   UniversalString (SIZE (1..MAX)),
      utf8String        UTF8String      (SIZE (1..MAX)),
      bmpString         BMPString       (SIZE (1..MAX)) }
"""

Want to add this to OpenSSL? It's easy.

"""
oid_section = new_oids

[new_oids]
1.2.3.x.y.z = etsiPaymentProcessor

[req]
distinguished_name = name_sect

[name_sect]
etsiPaymentProcessor = ETSI Payment Processor
etsiPaymentProcessor_value = whatever_you_want_it_to_say
"""



>    -
>
>
> 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.
>

The specification, as written, does not apply to PTCs. It is a private PKI.
The request is to change the public PKI so that the private PKI does not
have to change. That's... silly.

Some users are anticipated to want to overlay PTCs with this private usage.
That's functionally bad, period - you should keep these PKIs separate.
However, rather than telling them (correctly) "No, sorry, this is a bad
design" - one that will cause pain similar to payment terminals and SHA-1 -
I'm actively trying to engage here to find a solution that doesn't blindly
ignore X.520, RFC 5280, or the goal of the BRs. There's no fundamental
requirement to use PTCs - so a "no" vote is an even better response - but
if we are going to permit it, requiring it be done "right" doesn't seem
unreasonable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180613/97ce6d55/attachment-0001.html>