Re: Clarifications on ETSI terminology and scheme
On Fri, Nov 2, 2018 at 1:31 PM clemens.wanko--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > II. Assessment and certification statements: > - ETSI requires the auditing of the past period as well as of the current > operations status: > o In chapter 7.9 of the ETSI EN 319 403, it is clearly stated that the > operation records shall be audited (that will be detailed within a future > updated version of ETSI EN 319 403. On top of that it is planned to make > the ETSI TS 319 403-2 binding in order to have an even better definition > what is required to be audits for the past period). > However, as has been privately noted in the past, a CAB may achieve this requirement by examining a single operational record or issued certificate, without regard to any other actions. Or they may not consider any certificates at all, and merely consider other operational aspects; for example, that the policy management authority met to review the policy documentation. While you may argue that a well-behaved CAB would not undertake such a limited examination, I hope you can provide a citation if this is, in fact, not permitted within the scheme. I do not believe that having 119 403-2 binding will, in and of itself, improve this situation. This is perhaps a difference in fundamental approach with regards to the framework used by ISO/IEC 17065 and the necessary and desired output. More work would be needed to resolve this in a satisfactory way. However, independent of whatever normative requirements may existing within the framing of 119 403-2, 319 403, or more broadly, ISO/IEC 17065, we must separately assess whether or not the result is meeting that of community expectations. As we've seen, there are auditors who have found ways to achieve the necessary transparency and assurance despite 319 403 not formally requiring this. Similarly, in the context of WebTrust, we've seen there are auditors who meet not just the letter, but the spirit, and there are auditors that ostensibly fail to meet both. With regards to past activities - or those of assessing for future - I hope we can agree that repeated failures by a TSP demonstrate a failure of the CAB to appropriately review and supervise. As the CAB and Supervisory Body (in the context of qualified services, as that is the only place it operates ex ante) both serve to review those changes, output which is non-conforming demonstrates not just a failure by the TSP, but also that of the CAB. > Let’s keep in mind - please! - we are all pulling the same rope for more > security more confidence and reliability. We should take extra care to pull > in the same direction - all together - and invest our precious energy in > improving the ecosystem rather than blaming each other with the high risk > of damaging it. While this is a compelling call, within the context of CABs, a CAB that does not "pull their weight" is in fact a CAB that "drags everyone down"; whether you prefer to think of that, in the context of this metaphor, as pulling in the opposite direction or, perhaps more clearly compared, 'getting in the way,' the role of CABs in the CA ecosystem is not one of receiving participation stickers for showing up. They perform a necessary and critical function, and the failure to adhere to those expectations is reason to have meaningful discussion and take steps to correct the issue. In the CA and auditor ecosystem, those steps include matters like distrusting CAs or disqualifying auditors. It is not acceptable, nor has it ever been, to suggest that there are no consequences for misissuance or dereliction of duty, whether on behalf of the CA or the auditor. When an entity poses or introduces risk to the ecosystem, the ecosystem appropriately responds by cutting that risk out. That is not to say there are not opportunities to improve, but it would be irresponsible to suggest that we ignore the active damage being caused in the name of comity and camaraderie - to do so is foolishness. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Clarifications on ETSI terminology and scheme
Dear all, on behalf of ACAB’c we like to comment on that as follows: We would like to clarify the following normative points defined by the EA and by the ISO/IEC 17065/ETSI/eIDAS: I. Accreditation of CAB: - The eIDAS/ETSI accredited CAB in Europe are in general all accredited according ISO/IEC 17065 in conjunction with ETSI EN 319 403. It is not possible to be purely accredited according to ETSI EN 319 403 as that is a supplementary standard refining the ISO/IEC 17065 especially for the conformity assessment of trust services. This is clearly indicated in the introduction of the ETSI EN 319 403. The CAB is accredited against ISO/IEC 17065. The ETSI EN 319 403 however is incorporated in the accreditation to address the specific requirements for assessment of trust services – even if it might not be explicitly listed in a accreditation certificate. - In general NAB can accredit organizations against the ISO norms as listed here: http://www.european-accreditation.org/what-is-accreditation#2 - The EA statement where ETSI EN 319 403 is defined as supporting norm for accreditation according ISO/IEC 17065 of CAB assessing TSP can be found here: http://www.european-accreditation.org/information/etsistandard-en-319-403-published-to-provide-requirements-for-conformity-assessmentbodies-assessing-trust-service-providers-tsps II. Assessment and certification statements: - ETSI requires the auditing of the past period as well as of the current operations status: o In chapter 7.9 of the ETSI EN 319 403, it is clearly stated that the operation records shall be audited (that will be detailed within a future updated version of ETSI EN 319 403. On top of that it is planned to make the ETSI TS 319 403-2 binding in order to have an even better definition what is required to be audits for the past period). - ETSI covers aspects of the future operations of the TSP as there are obligations for TSP to inform the CAB (according ETSI EN 319 403, chapter 7.10) in case of any planned changes of the operations before implementation is done and the supervisory body accordingly (see eIDAS Article 24, Para 2 a). - If the TSP is performing changes without informing the CAB, the CAB may withdraw the certificate according to chapter 7.11 of ISO/IEC 17065. Looking at the discussion in general we see that there is a lot of energy invested by the different players in the ecosystem. This results in threats and postings and answers to those and answers to the answers… That high attention in general is definitely to be judged positive. We need that! We however urgently like to advertise for a discussion leading to - balanced judgements (the world is NOT black and white!), - an improvement of processes (like incident detection and processing), - more security and assurance for all players in the ecosystem. Let’s keep in mind - please! - we are all pulling the same rope for more security more confidence and reliability. We should take extra care to pull in the same direction - all together - and invest our precious energy in improving the ecosystem rather than blaming each other with the high risk of damaging it. We - the ETSI and WebTrust auditors - will sit together in December in Berlin to take up that point for further improvements and as discussed in Shanghai we certainly should interface in a dedicated CA/B-Forum workinggroup to the browsers and the CAs. Best regards Clemens, ACAB'c ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Clarifications on ETSI terminology and scheme
On Wed, Oct 31, 2018 at 4:05 PM Dimitris Zacharopoulos wrote: > > For example, when we talk about expectations of CAs, we don't talk about > > what they 'could' do, we talk about what they MUST do, because at the end > > of the day, that's the bar they're being held to. It's certainly true > that > > a given TSP may go above and beyond some bar, but that doesn't mean we > can > > say "CAs do X", because they aren't required to. The same logic applies > in > > the discussion of CABs - it does not make sense to discuss how they > 'could' > > interpret it, but rather, what they MUST do. > > ISO 17065 and ETSI EN 319 403 include normative requirements for CABs > just as the Baseline Requirements and ETSI EN 319 411-1 do for TSPs. I > don't understand why you think it is any different for CABs. For > example, the baseline requirements mandate that "The CA SHALL maintain a > continuous 24x7 ability to respond internally to a high-priority > Certificate Problem Report, and where appropriate, forward such a > complaint to law enforcement authorities, and/or revoke a Certificate > that is the subject of such a complaint". > > It doesn't specify exactly how a CA shall respond internally to such a > request. It must have a process and the CAB will evaluate it. > > Similarly for CABs, under 7.13.1 of 17065 "The certification body shall > have a documented process to receive, evaluate and make decisions on > complaints and appeals. The certification body shall record and track > complaints and appeals, as well as actions undertaken to resolve them". > > It doesn't specify exactly how the CAB shall fulfill this requirement > but each competent CAB must demonstrate to their NAB that they have a > documented process that fulfills this criteria, is effective and efficient. > > Even in the introduction section of 17065, you see the same use of words > SHALL, SHOULD, MAY, CAN as described in RFC2119. > We've now so fully drifted from the original discussion that it's clear to see we're talking about very different things, and thus confusion is understandable. For context, this particular discussion began in https://groups.google.com/d/msg/mozilla.dev.security.policy/Q9whve-HJfM/niS5Y2f0AQAJ , and in particular, the discussion about "If the CAB" does X. The point of my criticism to this statement has been that the CAB is not required to do X, they may do X, but they aren't mandated to do X. I believe you interpreted my remark of "no notification will be made to relying parties" is that it's impossible to notify RPs, and so you raised an example of how a CAB might hypothetically do so. I was not trying to state that - merely, that CABs do not have a normative requirement to notify RPs of this change, and so as a matter of "Can you rely on this", the answer is "No". Yes, some CABs may, but if a CAB doesn't, or if they make mistakes, they've not violated any requirements. And that's just as equally applicable to CAs. When a CA MUST "have a process", we cannot make assumptions or rely on what that process does or how it might result. When a CAB MUST "have a process", we cannot make assumptions or rely on what they do in that process. I would hope we're in violent agreement there. > It's the same way that when we talk about the BRs, it's pointless to talk > > about how some CAs may go above and beyond in their CPS, when discussing > > the CA ecosystem or a particular (different) CA's misissuance. What > matters > > is the baseline expectations here. > > Some baseline expectations are not overly prescriptive in the BRs for > CAs nor in the "BRs for CABs" (i.e. ISO 17065 and ETSI EN 319 403). > Information Security Management Systems can have significantly different > implementations but must maintain specific principles. This is where > illustrative controls and recommended practices come in so that the > auditors can evaluate if the principles are met but it's always subject > to the opinion of the CAB (when auditing TSPs), and to the NAB (when > assessing CABs). > My attempt to explain-by-analogy, to hopefully get us talking about the same thing, has unfortunately lead to even more divergence. I hope that, with the above clarifications to what we're originally talking about, we can get back on the same page. That said, because it contains some confusion, it at least bears highlighting. As mentioned during the recent CABForum, illustrative controls do not serve the purpose you are describing, neither do recommended practices. They have no 'force' to ensure that things must be 'equivalent-or-better'. They're not even hints. They're just that - illustrative. One cannot and should not make any assumptions that the existence of illustrative examples means that you will get the same results. It's entirely valid to wholly ignore those illustrative controls and recommended practices, end up with something completely opposite, and yet have fully fulfilled the requirements. This is why prescriptive controls are more
Re: Clarifications on ETSI terminology and scheme
On 31/10/2018 8:00 μμ, Ryan Sleevi via dev-security-policy wrote: [...] 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. I'm afraid you're still misunderstanding, and I believe, mistating. It is not ISO/IEC 17065 AND EN 319 403 that a CAB is assessed against. They're assessed against EN 319 403, which *incorporates* ISO/IEC 17065. This is the same way that when a TSP is assessed against ETSI EN 319 411-2, they're not also (as in, separate audit report) assessed against EN 319 411-1; EN 319 411-2 *incorporates* EN 319 411-1. Now, the CAB may ALSO be accredited for ISO/IEC 17065 (e.g. in the context of application of other schemes), but I can't find supporting evidence to support your claim that *both* are required in the context of EN 319 403. Could you provide further details that you believe would demonstrate this? I would prefer to let some auditor reply to this but I quickly went through https://ec.europa.eu/futurium/en/system/files/ged/list_of_eidas_accredited_cabs-2018-07-27.pdf and checked out some CAB accreditation letters and it looks like they are accredited to both "(ISO/IEC 17065 + ETSI EN 319 493 + eIDAS Art.3.18 scope of accreditation)". I think it is also clearly stated in ETSI EN 319 403 that lists ISO 17065 as a Normative reference and also: "ISO/IEC 17065 [1] is an international standard which specifies general requirements for conformity assessment bodies (CABs) performing certification of products, processes, or services. These requirements are not focussed on any specific application domain where CABs work. In the present document the general requirements are *supplemented* to provide additional dedicated requirements for CABs performing certification of Trust Service Providers (TSPs) and the trust services they provide towards defined criteria against which they claim conformance." "The present document also *incorporates* many requirements relating to the audit of a TSP's management system, as defined in ISO/IEC 17021 [i.12] and in ISO/IEC 27006 [i.11]. These requirements are incorporated by including text to derived from these documents in the present document, as well indirectly through references to requirements of ISO/IEC 17021 [i.12]." So, in my understanding, ISO 17065 must be fully covered and some elements if ISO 17021 are incorporated. ETSI EN 319 403 supplements 17065. 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. Yes, which does not mean it provides any baseline assurance for relying parties, which matters. For example, when we talk about expectations of CAs, we don't talk about what they 'could' do, we talk about what they MUST do,
Re: Clarifications on ETSI terminology and scheme
On Wed, Oct 31, 2018 at 12:55 PM Dimitris Zacharopoulos via dev-security-policy wrote: > > > 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 > > > 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. > I'm afraid you're still misunderstanding, and I believe, mistating. It is not ISO/IEC 17065 AND EN 319 403 that a CAB is assessed against. They're assessed against EN 319 403, which *incorporates* ISO/IEC 17065. This is the same way that when a TSP is assessed against ETSI EN 319 411-2, they're not also (as in, separate audit report) assessed against EN 319 411-1; EN 319 411-2 *incorporates* EN 319 411-1. Now, the CAB may ALSO be accredited for ISO/IEC 17065 (e.g. in the context of application of other schemes), but I can't find supporting evidence to support your claim that *both* are required in the context of EN 319 403. Could you provide further details that you believe would demonstrate this? > > 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
