Re: AC Camerfirma's CP & CPS disclosure
Camerfirma has delivered point-in-time audits as required by Mozilla in response to the annual audit statements we received in July containing multiple qualifications. The new audit statements along with the history of this issue can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=1478933 In my opinion, Camerfirma has completed their remediation of this issue. Please comment here or in the bug if you have any concerns. - Wayne On Thu, Sep 27, 2018 at 12:42 AM Ramiro Muñoz wrote: > Hi Wayne > > All problems have already been resolved from our side and we wait for the > PIT audit planned for the next week. > We will be able to provide the PIT before October 31th. > > Best regards > Ramiro Muñoz Muñoz > AC Camerfirma SA. > CTO, Exploitation Manager, CISA. > +34 619 746 291 · rami...@camerfirma.com. > https://www.linkedin.com/in/ramirom. > > Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede > contener > información CONFIDENCIAL, siendo para uso exclusivo del destinatario, > quedando prohibida su divulgación copia o distribución a terceros. Si Vd. > ha > recibido este mensaje erróneamente, se ruega lo notifique al remitente y > proceda a su borrado. > De conformidad con lo establecido en el Reglamento UE 2016/679 de 27 de > abril de 2016 General de Protección de Datos, se le informa que la empresa > AC CAMERFIRMA, S.A. tratará la información que nos facilita con el > exclusivo > fin de cumplir con las obligaciones derivadas de la relación comercial o > contractual adquirida con usted y que sus datos no podrán ser objeto de > otro > tratamiento ni de cesión a terceros salvo en los casos en que exista una > obligación legal. > Usted tiene derecho a obtener confirmación acerca del tratamiento de sus > datos personales, y a ejercer sus derechos de acceso, rectificación, > supresión, limitación y portabilidad en el tratamiento, dirigiéndose a AC > CAMERFIRMA, S.A., mediante comunicación escrita remitida a la dirección C/ > Ribera del Loira 12 (28042) Madrid, o a la dirección electrónica > jurid...@camerfirma.com o a través de la web de incidencias disponible en > la > página web http://webcrm.camerfirma.com/incidencias/incidencias.php > > [EN] > This message, and if applicable, any file attached to it, may contain > CONFIDENTIAL information for the exclusive use of the recipient, being > prohibited its disclosure copy or distribution to third parties. If you > have > received this message incorrectly, please notify the sender and proceed > with > its deletion. > In accordance with the provisions of the EU Regulation 2016/679 of April > 27, > 2016 General Data Protection, you are informed that the company AC > CAMERFIRMA, S.A. will treat the information you provide us with the sole > purpose of complying with the obligations derived from the commercial or > contractual relationship acquired with you and that your data will not be > subject to another treatment or assignment to third parties except in cases > where there is an legal obligation. > You have the right to obtain confirmation about your personal data > treatement, and to exercise your rights of access, rectification, deletion, > limitation and portability, contacting AC CAMERFIRMA, SA, by written > communication sent to the address C / Ribera del Loira 12 (28042) Madrid, > or > to the legal address jurid...@camerfirma.com or through the website > http://webcrm.camerfirma.com/incidencias/incidencias.php > > > -Mensaje original- > De: dev-security-policy > [mailto:dev-security-policy-boun...@lists.mozilla.org] En nombre de Wayne > Thayer via dev-security-policy > Enviado el: jueves, 27 de septiembre de 2018 0:38 > Para: Ramiro Muñoz Muñoz > CC: mozilla-dev-security-policy > > Asunto: Re: AC Camerfirma's CP & CPS disclosure > > Hello Ramiro, > > On Tue, Sep 4, 2018 at 3:13 PM Wayne Thayer wrote: > > > Thank you for this response Ramiro. I have copied this to the bug [1] > > and have described Mozilla's expectations for point-in-time audits > > that confirm that these issues have been resolved. > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1478933 > > > > On Tue, Sep 4, 2018 at 5:47 AM ramirommunoz--- via dev-security-policy > > < dev-security-policy@lists.mozilla.org> wrote: > > > >> > >> 7- List of steps your CA is taking to resolve the situation and > >> ensure such issuance will not be repeated in the future, accompanied > >> with a timeline of when your CA expects to accomplish these things. > >> > >> AC Camerfirma has made changes in the CP/CPS to fix the > >> inconsistences found by the auditor and will disseminate the > >> documents and the new procedures to avoid news problems in a future. > >> AC Camerfirma is working on correcting the imbalances detected and > >> the effective processes to ensure that the information offered by the > >> OCSP and the CRL is the same. > >> 2018-07-14 -> Qualified Audit Report > >> 2018-09-17 -> CPS & CP's new versions will
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
Clarifications on ETSI terminology and scheme
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. 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
Re: Questions regarding the qualifications and competency of TUVIT
On Wed, Oct 31, 2018 at 11:43 AM Wiedenhorst, Matthias via dev-security-policy wrote: > · Since January 2018, T-Systems issued EV certificates with an > incorrect qcStatement. T-Systems was made aware of the problem in October > 2018, i.e. for about 9 month the error was not detected/reported > https://bugzilla.mozilla.org/show_bug.cgi?id=1498463#c3 > T-Systems fixed the error in a timely manner so that certificates now > contain the correct qcStatement. > T-Systems identified a deficiency within their systems, made a change on October 5, but did not notify their CAB and SB until October 16. Under the requirements provided by EN 319 401, 7.9, that does not seem consistent with meeting those requirements. > · TUVIT performed an audit of T-Systems according to ETSI policies > EVCP and QCP-w in the beginning of 2018. During the audit the incorrect > coding of the qcStatement was not detected. > Yes. I believe this is a significant issue, given the assessment report. > · In several emails, we answered to his complaint, explained our > procedures and justified the classification of the encoding error as minor > (non-critical) non-conformity. > For non-critical non-conformities, our certification requirements foresee > a maximum period of 3 month for remediation before the certification shall > be withdrawn. (see also ETSI EN 319 403, section 7.6 b) Based on the > classification as minor, we do not see a necessity for revocation. > That’s about the relevant facts. > Let me now reply in detail to Ryans private contribution: > > >I would like to suggest that consideration be given to rejecting future > >audits from TUVIT and from that of Matthias Wiedenhorst and Dr. Anja > >Widermann, for some period of time. I would suggest this period be at > least > >one year long; however, given the technical details of ETSI accreditation, > >believe a period of three years may be more appropriate. > > Dr. Anja Wiedemann (please mind the correct spelling) was not part of the > audit team. We do not understand why her name is mentioned here. > One / three years exclusion from audit sounds like a punishment. We do not > understand where this time frame comes from and why such a time frame is > needed. > Auditor and Reviewer, as stated on https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018072001_Audit_Attestation_E_Deutsche-Telekom-Root-CA-2_20180718_s.pdf - the parties tasked with ensuring that the audit is meaningfully able to ensure the criteria were met and the testing procedures were able to meet those requirements. The time frame selected is one that has been consistently used in the past regarding questions about audits. Unfortunately, there lacks suitable means to objectively determine whether or not the auditor is sufficiently competent in remediation of problematic audits. Past procedures have resulted in indefinite suspensions for some auditors, or temporary suspensions of their recognition. The choice of three years, rather than one year, is based on the fact that we have now seen auditors who were not accredited perform audits against the frameworks, later become accredited, and retroactively issue reports covering their activities prior to accreditation. This does not instill confidence in the ETSI approach to auditor supervision, and thus the longer period is to ensure that no in-process audits are retroactively certified upon the expiration of the period. Three years thus aligns with both the 1 year (CA/B Forum) and 2 year (eIDAS) time periods in ensuring that such a possibility is not technically achievable. > >If there is a belief that a TSP has failed to meet the requirements of > >their accreditation, EN 319 403 describes a process for which complaints > >may be made to either the TSP or to the CAB. This complaint process is > >further expanded upon in ISO/IEC 17065, which 319 403 incorporates. This > >same process also applies when there have been mistakes by the CAB to > >adhere to its scheme requirements under EN 319 403 - a complaint may be > >made with either the CAB or the NAB regarding the CAB's accreditation. > > TSPs are not accredited but certified, ETSI EN 319 403 §7.13 does not make > any additional requirements on complaint procedures but just reference > ISO/IEC 17065. (The requirements from ISO/IEC 17065 [1], clause 7.13 shall > apply.) In particular, no procedures for complaints to TSPs or NABs are > defined (only to CABs). > 4.1.2.2 (j) provides for the client (the TSP) to inform the CAB any complaints made known to it. You're correct that procedures for complaints directly to the TSP are not normatively specified by ISO/IEC 17065 or that of EN 319 403; however, the countenance is made that a client (the TSP) may have knowledge of and records of complaints outside the scope and purview of the CAB's complaints. With respect to the NAB process, https://www.dakks.de/sites/default/files/71_sd_0_009_e_beschwerdeverfahren_2018_v1.0_0.pdf
Re: Questions regarding the qualifications and competency of TUVIT
On 2018-10-31 16:42, Wiedenhorst, Matthias wrote: In several emails, we answered to his complaint, explained our procedures and justified the classification of the encoding error as minor (non-critical) non-conformity. I think we never consider encoding errors as a minor error. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Questions regarding the qualifications and competency of TUVIT
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 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): >
Re: Questions regarding the qualifications and competency of TUVIT
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). 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". 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. The closest that it comes is that if they're accredited according to EN 319 411-2 (Qualified Certificates), the suspension/withdrawing will be reported to the Supervisory Body, which will them update the Qualified Trust List for that country and that will flow into the EU Qualified Trust List. If they're accredited against EN 319 411-1, the Supervisory Body will be informed by the CAB (in theory, although note my complaint about TSP informing the CAB was not followed, and the same can exist with CAB to SB), but no further notification may be made. Furthermore, if certification is later reissued, after a full audit, the certification history will not reflect that there was a period of 'failed' certification. This similarly exists with respect to CABs - if a CAB has their accreditation suspended, on the advice of or decision of the NAB based on feedback from the SB - the community will not necessarily be informed. In theory, because certification is 'forward' looking rather than 'past' looking, a suspension or withdraw of a CAB by a NAB may not affect its past certification of TSPs; this is an area of process that has not been well-specified or determined. 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. Similarly with TSPs losing their Certification, if a CAB loses their Accreditation it will be displayed on the NAB's web site. 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): "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. 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. Hope this helps. Dimitris. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
