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. 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. > 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. > > 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. > 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. > 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. > 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. > As far as the non-disclosure of compliance certificate > suspension/withdrawals is concerned, CABs are only allowed to follow > their practices as described in ISO 17065 section 7.11.3. Root Programs > could possibly require that CAs MUST disclose any possible Certification > suspension or revocation that occurred during their audit period. > Yes. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
