On 31/10/2018 4:47 μμ, Ryan Sleevi via dev-security-policy wrote:
There's a lot of nitpicking in this, and I feel that if you want to
continue this discussion, it would be better off in a separate thread on
terminology. I disagree with some of the claims you've made, so have
corrected them for the discussion.
I would much rather keep this focused on the discussion of TUVIT as
auditors; if you feel that the nitpicking is relevant to that discussion
(which I don't believe anything you've said rises to that level), we should
certainly hash it out here. This is why I haven't forked this thread yet -
to make sure I've not misread your concern. However, if there's more
broadly a disagreement, but without impact to this discussion, we should
spin that out.
Indeed, my comments were more related to the ETSI terminology so I
created a new thread. More answers in-line.
On Wed, Oct 31, 2018 at 7:11 AM Dimitris Zacharopoulos <[email protected]>
wrote:
On 30/10/2018 6:28 μμ, Ryan Sleevi via dev-security-policy wrote:
This establishes who the CAB is and who the NAB is. As the scheme used in
eIDAS for CABs is ETSI EN 319 403, the CAB must perform their assessments
in concordance with this scheme, and the NAB is tasked with assessing
their
qualification and certification under any local legislation (if
appropriate) or, lacking such, under the framework for the NAB applying
the
principles of ISO/IEC 17065 in evaluating the CAB against EN 319 403. The
NAB is the singular national entity recognized for issuing certifications
against ISO/IEC 17065 through the MLA/BLA and the EU Regulation No
765/2008
(as appropriate), which is then recognized trans-nationally.
Some clarifications/corrections because I saw some wrong usage of terms
being repeated.
A CAB MUST perform their assessments applying ISO/IEC 17065 AND ETSI EN
319 403 AND any applicable legislation (for EU CABs this includes
European and National legislation).
Dimitris, I'm sorry, but I don't believe this is a correct correction.
EN 319 403 incorporates ISO/IEC 17065; much like the discussion about EN
319 411-2 incorporating, but being separate from, EN 319 411-1, the
structure of EN 319 403 is that it incorporates normatively the structure
of ISO/IEC 17065, and, at some places, extends.
Your description of the system is logically incompatible, given the
incompatibilities in 319 403 and 17065.
You're correct that any applicable national legislation applies, with
respect to the context of eIDAS. However, one can be assessed solely
against the scheme of EN 319 403 and 319 411-1, without going for qualified.
I have to disappoint you and insist that your statement "As the scheme
used in eIDAS for CABs is ETSI EN 319 403, the CAB must perform their
assessments in concordance with this scheme, and the NAB is tasked with
assessing their qualification and certification under any local
legislation (if appropriate) or, lacking such, under the framework for
the NAB applying the principles of ISO/IEC 17065 in evaluating the CAB
against EN 319 403"
and specifically the use of "or" in your statement, is incorrect. NABs
*always* assess qualification of CABs applying ISO/IEC 17065 AND ETSI EN
319 403 AND any applicable legislation. Only Austria is an exception (if
I recall correctly) because they don't apply ETSI EN 319 403 for CAB
accreditation.
Then, each CAB is accredited for specific standards (e.g. ETSI EN 319
411-1, 411-2, 421, eIDAS regulation and so on).
ISO 17065 and ETSI EN 319 403 apply only to CABs and ETSI EN 319 411-1,
411-2 apply only for TSPs. 411-2 incorporates 411-1 and 401 but does not
incorporate 403 or 17065. They are completely unrelated.
Also, a NAB issues "Accreditations" to CABs and not "Certifications".
Also, a CAB issues "Certifications" to TSPs and not "Accredidations".
So, T-Systems is "Certified", not "Accredited".
Fair. If you replace these words, does it change the semantic meaning of
the message at all? I don't believe so.
No, it doesn't but I know how much you like being accurate :-)
As the framework utilizes ISO/IEC 17065, the complaints process and
certification process for both TSPs and CABs bears strong similarity,
which
is why I wanted to explore how this process works in function.
Note that if either the TSP is suspended of their certification or
withdrawn, no notification will be made to relying parties.
This depends on applicable legislation and the implementation of ISO
17065 sections 4.6, 7.11.3 by each CAB. Some CABs have a public
repository where RPs can query the validity of TSP Certifications so if
a Certification is Suspended or Revoked, it will be displayed
accordingly. I don't think WT has a notification scheme for RPs either.
If the TSP publishes the seal URL or the CAB's URL to the TSP
Certificate (which is not mandatory), RPs can manually check the
validity of the TSP Certification.
I don't think this is a valid criticism, particularly in the context of the
specific case we're speaking about. I'm speaking about what's required -
you're speaking about what's possible. Many things are possible, but what
matters for expectations is what is required. 7.11.3 simply defers to the
scheme to specify, which EN 319 403 does not as it relates to this
discussion.
ISO 17065 sets the base and 7.11.3 describes the principles that need to
be followed. It is very likely that different CABs will choose to
implement this principle in a different way but at the end of the day,
their implementation must satisfy the principle and they are evaluated
by the NAB that ensures the principles are met.
This standard is a very old and very mature, used to evaluate products
and processes related to food, elevators and so many critical
life-threatening products. Depending on the criticality of the audited
standard, there may be additional requirements for the disclosure of
non-conformities, certification suspension/withdrawal and others. For
example, the food industry has additional rules for CABs (accredited
under ISO 17065) evaluating companies that produce certain food products
so that in case they detect a certain pathogens or other major
non-conformities, they must inform specific regulatory authorities. It
is not impossible to set out similar rules in ETSI EN 319 403 or, as we
agreed in my previous post, in Root program requirements.
Note that Supervisory Bodies (only related to eIDAS) have no authority
for TSP Certifications under ETSI EN 319 411-1, but only ETSI EN 319
411-2. In all cases of Certification (ETSI EN 319 411-1 or ETSI EN 319
411-2), the NAB is assessing the CAB. In most EU countries, the NAB IS
NOT the Supervisory Body.
The NAB is still responsible for the oversight of the CAB's execution of EN
319 403, and the investigation therein. The SB suspends qualified status,
but the NAB ensures that the CAB is meeting the requirements of the
certification scheme (EN 319 403) as part of supervising the accreditation
of that CAB.
Correct.
Similarly with TSPs losing their Certification, if a CAB loses their
Accreditation it will be displayed on the NAB's web site.
More concretely, the absence will be.
They should be using a similar process, that is to mark that an
accreditation has been suspended or withdrawn.
I also consider the "WT seal" and "ETSI certification" very similar. A
WT seal is similar to an ETSI certificate because they state (emphasis
mine):
No, they are not at all similar. I don't think this is the thread to have
that discussion, however.
"An unqualified opinion from the practitioner indicates that such
principles *are being followed* in conformity with the WebTrust for
Certification Authorities Criteria. These principles and criteria
reflect fundamental standards for *the establishment and on-going
operation* of a Certification Authority organization or function."
So, if I check a WT seal today Oct 31, 2018, even though the CA has not
been audited between their last audit and today, the WT seal represents
that it is still valid and not withdrawn. They are both "forward
looking" in the eyes of Relying Parties.
This fundamentally misunderstands what WT audits are.
Perhaps, but in my understanding both schemes result to an Public
declaration that the CA/TSP has been audited over a particular period
according to specific standards, and can be reasonably trusted in
continuing to do what they do until they are evaluated again.
Dimitris.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
