[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

[Dimitris Zacharopoulos (HARICA)]

On 5/11/2018 11:01 μμ, Ryan Sleevi wrote:
>
>
> On Mon, Nov 5, 2018 at 3:10 PM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>     In my interpretation, direct reference to Regulation 910/2014
>     (eIDAS) for eSeals and QWACs provides the legal basis. Does it
>     directly mandate a specific implementation? I think it does. It
>     says "use whatever you have for eSeals and web authentication
>     under eIDAS and use it for PSD2". We can try to re-invent the
>     wheel but eSeals and QWACs as described by ETSI EN 319 411-2 and
>     the various ETSI EN 319 412-x profiles (which are European Norms)
>     are currently used as the defacto implementation of eSeals and
>     QWACs linked to eIDAS. If you don't think this is reasonable
>     enough, then this discussion will likely become very
>     legally-oriented and will move away from the technical elements.
>
> I'm very confused by your reasoning. You first posed it as a matter of 
> legal requirement, yet you also seem to acknowledge with respect to 
> the eIDAS regulation that it remains technology neutral nor does it 
> require the use of PTCs. So it sounds like we're in agreement that the 
> existence of PSD2 does not somehow trigger the BRs exception process, 
> correct?

I can't really answer yes or no because it seems to be more of a legal 
issue, and there are cases where the legal interpretation is in the gray 
area, like this case. Some courts are ruling in favor and accepting some 
defacto situations even though they are not explicitly written in the 
legal documents. Similarly, you say that there might be other 
implementations, not ETSI, that can fulfill the expectations set by 
eIDAS. I don't disagree with that but there is at least ONE 
implementation (ETSI) that fulfills eIDAS and must be treated with legal 
basis. To put it more simply, if a TSP gets a request for an electronic 
Seal Certificate or a QWAC as described by ETSI, they treat it as a 
request that originates from eIDAS, thus it has a legal basis.

My reference to 9.16.3 was not to trigger the exception per se, but to 
highlight the expectation that the Forum would try to accommodate local 
law in the requirements and resolve possible conflicts.

>>     Now, to your question, yes, the CAR would be against a hierarchy
>>     that is orthogonal to/separate from the PTC hierarchy, and
>>     reflect inclusion on the qTSL, which the TPP is already having to
>>     integrate with in order to achieve compliance with PSD2 if
>>     adopting the eIDAS context for the delivery of that information.
>>     This is similar to root programs' existing requirements regarding
>>     the separation of roots or intermediates for purpose. The TSP may
>>     be operating multiple trust services - some qualified, some non-,
>>     some PTC, some not - and creating hierarchies appropriate for
>>     those cases.
>>
>
>     As stated above, PSD2 and eIDAS are directly coupled, so PSD2
>     adopts the eIDAS context. Regulation 389/2018 is clear.
>
>
> Yes, and eIDAS adopts a technology-neutral approach, and thus does not 
> mandate the use of PTCs, and thus does not trigger 9.16.3 as you 
> previously suggested.
>
>     But I'm afraid that a TSP won't be able to get a clean audit
>     report for ETSI EN 319 411-2 under QCP-w, even if this is not
>     intended to be used by a publicly-trusted browser, because the
>     standard has a direct reference to the EV Guidelines which
>     currently doesn't allow the /organizationIdentifier /attribute in
>     subjectDN. So, we're back where we started.
>
>
> I hope we agree that it's functionally not necessary for a TSP to get 
> audited against ETSI EN 319 411-2 under QCP-w in order to be 
> recognized as qualified, both with regards to PSD2 and in general. EN 
> 319 411-2 is but one factor that the NAB/SB may consider in its 
> recognition of qualification.
>
> But again, I think we're in agreement here - EN 319 412-4 specifies a 
> particular profile, which is incorporated by 319 411-1 and 319 411-2. 
> TS 119 495 adopted a profile that is itself in conflict with 319 
> 412-4, and thus also 319 411-1 and 319 411-2. This was entirely 
> avoidable within the ETSI context.
>
> If we don't agree that this is a bug within the ETSI specification 
> process, I'm hoping you can clarify what steps the ESI group took to 
> identify and resolve profile conflicts.

Hopefully Nick Pope and other ETSI members can best answer this. In my 
interpretation of EVGs, as I already expressed it at the London F2F, per 
9.2.8 (2) allows other subjectDN attributes as long as they are properly 
validated by the CA. This interpretation is also aligned with the BRs 
7.1.4.2.2 (j) which is written more clearly.

In any case, I don't think ETSI thought there was any profile conflict 
between their requirements and the PTC requirements because they have 
the same interpretation, again, as expressed at the London F2F meeting.

>
> It seems to resolve this, now the Forum is being asked to modify 
> itself so that ETSI does not have to update any of its documents, at a 
> minimum. Whether or not such certificates functionally need to 
> interoperate with PTCs is unclear - no presentation or specification 
> gives effects to that, and indeed, both common sense and security best 
> practice provide ample evidence that such interoperability is a 
> net-negative for the goals of PSD2. Thus, the requirement to update 
> the documents for PTCs, for something that don't need to be PTCs, in 
> order to avoid having ETSI need to update its documents (either those 
> specifying PSD2 or those specifying QCP-w) seems... confusing, at 
> best. PSD2 or QCP-w could be specified in a way that avoids any 
> incompatibilities with PTCs, by not attempting to be PTCs and instead 
> separating out the requirements. If they want to be PTCs, it's not 
> unreasonable to expect them to not conflict with PTCs.
>
>>     Separate from all of this is recognizing that SDOs make mistakes
>>     from time to time, and the existence of a standard from a blessed
>>     organization - whether ETSI, IETF, or even the CA/Browser Forum -
>>     does not immediately compel the force of law. Perhaps I'm
>>     mistaken here, but every discussion I've seen of qualified PSD2
>>     certificates in the context of the ETSI specification are merely
>>     that the ETSI document is one attempt to frame the
>>     (technology-neutral) requirements of PSD2 with the
>>     (technology-neutral) requirements of eIDAS into a specific
>>     technical profile (X.509 certificates). It may be bugged, but
>>     that doesn't mean that PSD2 or eIDAS are somehow bugged or flawed
>>     - just the application of that specific technical profile failed
>>     to consider the technical interoperability necessary for PTCs.
>
>     I can't speak about interoperability issues of PTCs and the
>     recommendation to add /organizationIdentifier /in the subjectDN.
>     This would be a very interesting discussion and would be great if
>     all browser members were to present their views of potential risks
>     and problems they see in their platforms, if this attribute was
>     added in the subjectDN of EV Certificates.
>
>
> Given that there were concerns raised about the far more benign 
> DNQualifier with respect to the X.500 semantics, which would have 
> facilitated greater and more widespread use of TLS by resolving the 
> continued issue with common names, I'm not sure what you're expecting 
> here. I'm going to push back on this approach, because there's 
> fundamental issues at play here that haven't been addressed or resolved.
>

I think it's a very different problem. The DNQualifier didn't pass 
because some members were confused by the contents if that field.

"Contents: This field is intended to be used when several certificates 
with the same subject can be partitioned into sets of related 
certificates. Each related certificate set MAY have the same 
dnQualifier. The CA may include a dnQualifier attribute with a zero 
length value to explicitly indicate that the CA makes no assertion about 
relationship with other certificates with the same subject. The CA MAY 
set the dnQualifer value to the base64 encoding of the SHA1 hash of the 
subjectAlternativeName extnValue if it wishes to indicate grouping of 
certificates by alternative name set."

The /organizationIdentifier /we are currently discussing, has clearly 
validated information linked to the subject of the Certificate.

> There already had been given alternative paths forward to resolve 
> this, and it seems the goal is to avoid having to change any ETSI 
> documents by changing the BRs. Alternative paths included the 
> avoidance of the X.500 specific attribute with defined (and different) 
> semantics than being used here, making use of a subjectAltName here, 
> since, functionally, the PSD2 identifier is quite literally that - an 
> alternative name representation of the entity. Concerns were pointed 
> out with the structured string form of the identifier - itself going 
> against best-practices with respect to ASN.1 specifications in that it 
> encodes semantic meaning within unstructured (string) data, rather 
> than expressing it semantically - something EN 319 412-5 managed to 
> get right with QcEuLimitValue. Even using an alternative extension 
> would have avoided this conflict of profile.

ETSI introduced the /organizationIdentifier/ attribute in electronic 
Seals to link the Legal Entity with the key. I guess they thought it 
would be better than the JoI, serialNumber tupple currently used in the 
EV Guidelines. They want to extend this usage to QWACs. So, for all 
those TSPs that already issue eSeals, that made perfect sense (at least 
that was my impression after chatting with most European TSPs that 
participate in the CA/B Forum). Adding this attribute with validated 
information would be aligned with other existing attributes in the 
requirements. Would it be ok from Google if this was to be added in OV 
Certificates as currently allowed by the BRs? If yes, why does that not 
pose a similar threat and doesn't cause interoperability issues? If no, 
why not?

>
> TS 119 495 adopted a document that ignored several decades of industry 
> best practice, inherently created a conflict within its own relevant 
> standards (319 412-4 specifically, and thus transitively to 319 411-1 
> and 319 411-2), and is proposing that the resolution for that be that 
> such a definition be incorporated into either the BRGs or EVGs, so 
> that neither 319 412-4 nor 319 411-2 need to be updated. Such a 
> decision is the inverse of how the decision making process goes, and 
> it's entirely unclear at this point why the matter of TS 119 495 
> cannot be resolved by ETSI itself.
>

To the contrary, I think ETSI preferred to use the 
organizationIdentifier which is clearly described in the X.500 scheme 
instead of creating new custom attributes. They don't enforce different 
semantics for this attribute. They only offer an optional semantics 
representation (specific to ETSI), if it is asserted via a qcStatements 
declaration. IMHO this doesn't use the attribute differently.

> Can you clarify more about why the Forum should resolve this, given 
> both the technical and policy issues? Why the relevant ETSI documents 
> cannot be updated as appropriate, given that these ETSI documents are 
> themselves in conflict with eachother? And can you clarify what steps 
> are being taken, if any, to prevent future issues in which activities 
> in which the Forum is expected to correct issues created by other SDOs?

/organizationIdentifier /may be a good and "normalized" attribute. It 
doesn't seem to cause any interoperability issues, as currently allowed 
unambiguously by the BRs. It will also align with at least one 
implementation of a legal act in the EU with potential millions of 
beneficiaries.

The current language in EVG is ambiguous enough to have one 
interpretation (Google's) that including the /organizationIdentifier /in 
an EV Certificate will be treated as a violation of EVG and a 
misissuance, and others that interpret this as being allowed under 
9.2.8(2). Please correct me if this is not the case.

So, the least the Forum can do is to resolve this ambiguity. With that 
said, I will repeat my recommendation for people to consider Wayne's 
proposals 2 and 3 at the London F2F 
<https://cabforum.org/2018/06/06/minutes-for-ca-browser-forum-f2f-meeting-44-london-6-7-june-2018/#Subject-information-in-EV-certificates-specified-in-clause-92-of-the-EV-Guidelines-and-whether-this-allows-for-the-inclusion-of-X520-organizationIdentifier>.

"Wayne: Seems to reserve this field for ETSI use only. Two ways forward: 
no, you can’t use this field at all (status quo), or reserve it for ETSI 
and make sure it is extensible, or reserve it for ETSI and revisit 
guidelines when/if another request comes along".


Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181106/f7df9431/attachment-0001.html>