Wayne,
We have discussed your concerns with EU stakeholders and offer the following
responses. These concerns have been discussed with Webtrust and we believe
that the proposals below are in line with existing accepted practices.
Comment 1) We need standards that require consistent
Wayne,
We will work on how to address this within the EU audit framework based on EN
319 403.
TS 119 403-2 already includes some additional requirements specifically for PTC
to cover the CABF concerns for yearly audit and period of time audit review of
events since the previous audit. An
Hi Nick,
I had been thinking that 119 403-2 was just intended as an attestation
statement template, similar to the WebTrust reporting guidance [1]. Now I
understand that it can include more substantial requirements.
This is certainly not a complete list, but specific to this discussion I
would
Restating my earlier offer we would welcome a clear statement of any concerns
or wishes resulting from the discussions, on this or other related threads,
against the measures already proposed in TS 119 403-2 and its parent standard.
We can then discuss this with the European stakeholders and
On Thu, Nov 15, 2018 at 1:51 PM Ryan Sleevi wrote:
>
> On Wed, Nov 14, 2018 at 10:39 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> While I see some small steps being made toward a common understanding of
>> the issue, there is still fundamental
On Wed, Nov 14, 2018 at 10:39 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> While I see some small steps being made toward a common understanding of
> the issue, there is still fundamental and subjective disagreement on the
> severity, and it's not
It should come as no big surprise that I have documented this issue as our
first auditor compliance bug[1]:
https://bugzilla.mozilla.org/show_bug.cgi?id=1507376
I only included a brief summary of this discussion (and a link to it).
Others are welcome to comment if you feel that I have omitted
Once again, you snipped most of what I wrote.
Also not sure why your post has double reply marking.
On 13/11/2018 18:20, Ryan Sleevi wrote:
>>
>>
>>
>> On Tue, Nov 13, 2018 at 11:26 AM Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> Furthermore the
>
>
>
> On Tue, Nov 13, 2018 at 11:26 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Furthermore the start of the thread was off-list. Also neither I, nor
>> some other participants have access to the audit reports etc. in CCADB.
>>
>
> Sure you do.
Unfortunately, you seem to be be ignoring what I wrote and talking about
something else.
On 13/11/2018 14:31, Ryan Sleevi wrote:
> I suppose I had unreasonably hoped it would be self-evident, particularly
> for someone who claims to follow the issues, to understand how directly
> that issue was
On Tue, Nov 13, 2018 at 9:46 AM things things
wrote:
> >> I hope you can see that this is actively damaging the community by
> promoting magniloquent indictments instead of discussing
> >> clear facts. It would be far more productive to provide a concrete and
> structured list of TUVITs
I suppose I had unreasonably hoped it would be self-evident, particularly
for someone who claims to follow the issues, to understand how directly
that issue was related. Unfortunately, whether for intent or otherwise, it
appears not.
While I do not believe nor agree with your approach to framing
On Tue, Nov 13, 2018 at 5:30 AM things things via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Ryan,
>
> I feel you are trying to derail the discussion and are muddying the waters.
>
> I hope you can see that this is actively damaging the community by
> promoting
On 13/11/2018 04:08, Ryan Sleevi wrote:
> Jakob,
>
In the following, I have added a new subject category:
Subject U: [T-Systems local] Issues at T-Systems, rather than issues
in TUVIT's auditing of T-Systems.
I will use the following number:
U1: T-Systems misencoded the qc-statement
Jakob,
Please see
https://groups.google.com/d/msg/mozilla.dev.security.policy/Q9whve-HJfM/lpwKQXOfAgAJ
, which was already provided previously.
It includes details regarding T-Systems areas of non-compliance that were
1) Demonstrably not identified by the auditor
2) Covered by existing audit
Ryan,
Could you please provide, in a single message, a list of all the
supposedly multiple failures by TUVIT, clearly marking each if it is:
Subject O: [Other] A failure outside the specific subjects below.
Subject D: [Discussion] A failure by TUVIT to satisfactorily answer your
questions
Nick,
I find your continued suggestions to be actively harmful - to the
discussion, for sure, but also to the reputation of ETSI.
You've attempted to frame this, again, as an either/or approach - that is,
that we can only have one of these discussions. You've attempted to
"thread-jack" the
Ryan,
I see the main question is what is the most productive way ahead. We can
continue discussing a specific concern in the context of just 1 of the European
auditor, or work in the EU on a considered approach to all the concerns which
can be applied to all European based audits. The first
Ryan,
The difference in opinion seems to be which approach is most productive.
Targeting particular concerns at an individual auditor or clearly stating all
your concerns on European based audits for PTC so that we can come back come
back with a common decision how, through ETSI standards and
On Fri, Nov 9, 2018 at 7:05 AM Nick Pope via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I am asking that we get a clear statement of what you would like to see
> from EU audits based on ETSI standards and so that we (European Auditors
> and ETSI) can come back with a
I am asking that we get a clear statement of what you would like to see from EU
audits based on ETSI standards and so that we (European Auditors and ETSI) can
come back with a considered response on how we can meet you concerns. Rather
than saying what a particular individual person thinks, we
On Thu, Nov 8, 2018 at 6:24 AM Nick Pope via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Following on from Waynes earlier positive statement:
>
> "I look forward to more open and constructive discussions aimed at
> improving
> the quality and transparency of CA audits,
Following on from Waynes earlier positive statement:
"I look forward to more open and constructive discussions aimed at improving
the quality and transparency of CA audits, regardless of the audit scheme."
I believe centring discussion on one particular auditor is not progressing
things with
On Tue, Nov 6, 2018 at 4:48 AM Wiedenhorst, Matthias via
dev-security-policy wrote:
> Section 4.5 of ISO/IEC 17065 states that in general all non-public
> information shall be regarded as confidential. However, that section also
> allows that CAB and TSP can agree between each other about
In addition, I take exception to the statement that open criticism is a bad
approach and the implication that private discussions are the best way to
make improvements. This is clearly not Mozilla's philosophy.
I do believe that we all need to be careful to follow Mozilla forum
etiquette [1] and
On Mon, Nov 5, 2018 at 3:28 PM Nick Pope via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> It is very unfortunate that at this time the owners of root store programs
> openly criticise one of the main auditors working on improvements to
> European based audits. After a
It is very unfortunate that at this time the owners of root store programs
openly criticise one of the main auditors working on improvements to European
based audits. After a number of years of audits of European CAs based on ETSI
EN 319 403 being recognised as meeting the requirements of
I am particularly disturbed by three points made by TUVIT during this
discussion:
1. A malformed qcStatement extension is a minor non-conformity because
there is no known security risk - This argument is incredibly dangerous and
harmful. It implies that all sorts of well-defined requirements can
On Fri, Nov 2, 2018 at 10:24 AM Wiedenhorst, Matthias via
dev-security-policy wrote:
> 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
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
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
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
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
Le mardi 30 octobre 2018 22:23:10 UTC+1, Ryan Sleevi a écrit :
> On Tue, Oct 30, 2018 at 4:37 PM Erwann Abalea via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > > On what basis do you believe this claim is to be made? By virtue of
> > > asserting qcStatement-1? If
On Tue, Oct 30, 2018 at 5:08 PM Erwann Abalea wrote:
> Not seeing this on Google Groups :/
>
> Le mar. 30 oct. 2018 à 18:28, Ryan Sleevi a
> écrit :
>
>>
>>
>> On Tue, Oct 30, 2018 at 1:20 PM Erwann Abalea via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> Le
On Tue, Oct 30, 2018 at 4:37 PM Erwann Abalea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > On what basis do you believe this claim is to be made? By virtue of
> > asserting qcStatement-1? If qcStatement was mis-encoded, or qcStatement-1
> > was absent, do you
Not seeing this on Google Groups :/
Le mar. 30 oct. 2018 à 18:28, Ryan Sleevi a écrit :
>
>
> On Tue, Oct 30, 2018 at 1:20 PM Erwann Abalea via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Le mardi 30 octobre 2018 17:29:14 UTC+1, Ryan Sleevi a écrit :
>> [...]
>> >
Le mardi 30 octobre 2018 18:30:11 UTC+1, Moudrick M. Dadashov a écrit :
> Thanks for good overview.
> I'd like to add some more.
> Actually the most questionalble part of the chain is so called Supervisory
> bodies.
> Of course, root programs do not rely on SB assessment, but under eIDAS they
>
Le mardi 30 octobre 2018 18:28:50 UTC+1, Ryan Sleevi a écrit :
> On Tue, Oct 30, 2018 at 1:10 PM Erwann Abalea via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > In fact, for the Relying Party, these certificates are definitely
> > considered as Qualified certificates
Thanks for good overview.
I'd like to add some more.
Actually the most questionalble part of the chain is so called Supervisory
bodies.
Of course, root programs do not rely on SB assessment, but under eIDAS they are
authorised to audit TSPs and then publish National trust lists (as Scheme
On Tue, Oct 30, 2018 at 1:10 PM Erwann Abalea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> In fact, for the Relying Party, these certificates are definitely
> considered as Qualified certificates for website authentication, regardless
> of the content of the
Le mardi 30 octobre 2018 17:29:14 UTC+1, Ryan Sleevi a écrit :
[...]
> Note that if either the TSP is suspended of their certification or
> withdrawn, no notification will be made to relying parties. The closest
> that it comes is that if they're accredited according to EN 319 411-2
> (Qualified
Bonjour,
Le mardi 30 octobre 2018 16:20:31 UTC+1, Ryan Sleevi a écrit :
> (Writing with an individual hat)
>
> 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
On Tue, Oct 30, 2018 at 11:59 AM Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 2018-10-30 16:20, Ryan Sleevi wrote:
> > Given that the Supervisory Body and National Accreditation bodies exist
> to
> > protect the legal value of this scheme, the failure
On 2018-10-30 16:20, Ryan Sleevi wrote:
Given that the Supervisory Body and National Accreditation bodies exist to
protect the legal value of this scheme, the failure by TUVIT to uphold the
safety and security of the eIDAS regime represents an ongoing threat to the
ecosystem.
Do we have a way
45 matches
Mail list logo
