Re: Questions regarding the qualifications and competency of TUVIT

[Ryan Sleevi via dev-security-policy]

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 considered response on how we can meet you
> concerns.  Rather than saying what a particular individual person thinks,
> we would like to understand what your concerns are in as much detail as
> possible against what is specified as the current requirements for EU
> audits.We can then make a considered joint response to your concerns to
> ensure that ETSI audits meet your needs in a way works for the existing
> European environment.
>
> I note your concerns about transparency and ensuring that the requirements
> certificate profile are met.  If you can put these concerns down in detail,
> along with any other issue you have, as a joint document from the root
> stores, we can provide a coordinated response on how we can address your
> concerns.
>
> If you see this as "basics that are already required" rather than "wish
> list" fine, again just provide us with a clear set requirements so that we
> can properly respond.


I really don’t see how this is a productive response. It really is rather
simple - do you believe auditors should be assessing compliance with EN 319
412-* under the existing standards?

If yes, TUVIT has demonstrated a pattern of failing to do so, and it’s
appropriate to discuss what next steps are appropriate to minimize the risk
from such repeated failures - such as no longer accepting.

If not, then ETSI audits are quite literally missing one of the most basic
expectations, and their acceptance should be immediately stopped until such
a time as they do.

I fail to see how there’s any other possible response there; it really is
cut and dry like that.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How harsh (in general) should Mozilla be towards CAs?

[Eric Mill via dev-security-policy]

On Thu, Nov 8, 2018 at 8:51 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Over the years, there has been some variation among participants in how
> harshly individual mistakes by CAs should be judged, ranging from "just
> file a satisfactory incident report, and all will be fine" to "Any tiny
> mistake could legally be construed as violating a formal requirement
> that would be much more catastrophic under other circumstances,
> therefore the maximum penalty of immediate distrust must be imposed".
>

This doesn't seem like an accurate description of the debates within the
Mozilla CA program, or this list, at all. I've never heard anyone make an
assertion that sounds like either extreme.

The long-term participants here, including those who press CAs hard, have
all responded very positively to a timely, detailed incident reports that
properly demonstrate an understanding and addressing of root cause.

There have definitely been quite a few CAs who have had incident reports
dragged out of them, or filed incident reports that addressed surface level
issues without any seeming acknowledgment of the gravity of the issue.

Where incidents with little _immediate_ security impact have occurred (such
as certain kinds of spec non-conformity), they have typically become major
issues not on the depth of perceived impact, but when there is a failure to
acknowledge that poor responses to small issues are highly predictive of
future large issues, or a long-term pattern that demonstrates this
empirically.

The major distrust events of the last few years have all been preceded by
robust discussion and demonstration of long-term issues, and months or
years of poor communication with the community.

In other words, no one has been tossed on a technicality, and I've never
seen any regular member of the community advocate for tossing someone
solely on a technicality.


> Furthermore, people with some clout tend to shut down all
> counterarguments when taking either extreme position, creating situation
> there only their own position is heard, making the entire "community"
> aspect an illusion.
>

This isn't my experience at all. Contributions from community members are
certainly distributed unevenly, but that seems to correspond most closely
to folks for whom participation here is part of their day job. That would
particularly be true for those who have spent years engaging in oversight
of a shifting array of CAs. And since the Mozilla CA Program itself is a CA
oversight program, those members have a very credible claim to represent
the community, even if others don't always have the time or mandate to
devote time to articulating the same arguments.

In general, I don't believe this post is well-grounded in fact, and
presents an inaccurate view of the Mozilla CA program's history. As a
result, I don't think it's likely to produce a constructive discussion.

-- Eric

-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How harsh (in general) should Mozilla be towards CAs?

[Wayne Thayer via dev-security-policy]

I'm not convinced there is an answer here. It seems that most would agree
with the premise that we should consider the circumstances and context for
an issue and make a balanced assessment. That leaves the matter of what
this means in practice up for debate. Often, it appears to be a debate
between a strict application of the rules and the seemingly harmless effect
of the particular violation. Unfortunately the "no harm no foul" logic
leads to (takes us back to?) a situation where the rules are suggestions
and any CA can claim that any violation is okay, so long as they 'assessed
the risk'. So I view the 'balance' being between the 'moral hazard' of
excusing a violation and the belief that a violation is harmless in
practice.

As previously mentioned, a secondary consideration when assessing a
seemingly trivial violation is how it reflects on a CA's ability to follow
any rules. I agree that a single failure doesn't necessarily mean the CA is
incompetent, but when we see a pattern of "minor" violations occurring, we
have a problem. Another factor to consider is how 'new' a particular issue
is. The first CA to be called out for making a mistake is less culpable
than those who have ignored the warnings.

I also believe that violations in the context of a new inclusion request
should be treated more seriously because the costs to the ecosystem are
much lower if problems are addressed before a root is included.

- Wayne

On Fri, Nov 9, 2018 at 7:10 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 09/11/2018 15:52, Hanno Böck wrote:
> > On Fri, 9 Nov 2018 14:56:41 +0100
> > Jakob Bohm via dev-security-policy
> >  wrote:
> >
> >> However there are also some very harsh punishments handed out, such as
> >> distrusting some CAs (most notably happened to Symantec and WoSign,
> >> but others are also teetering), and distrusting auditors (most notably
> >> happened to the branch of Ernst & Young that audited the bad parts of
> >> those two).
> >>
> >> A line of arguments often seen is that someone failed once to do
> >>  completely right, therefore they cannot be trusted to do
> >> anything similar to  right at all, therefore they should no
> >> longer be trusted.
> >
> > I don't think anyone ever said something like that. Particularly
> > I'm not aware of any recent incident where a CA failed *once* and got
> > distrusted.
> >
>
> All 3 lines of reasoning I mentioned (with variations from case to case)
> can be found in two of the most recent threads on this list.
>
> > In the cases you mention - Symantec and Wosign - there were multiple
> > issues. In both cases there was also plenty of opportunity for the
> > affected CAs to explain and improve things before a distrust was
> > even considered. It was repeated failures and a long list of issues
> > that led to the distrust.
> >
>
> I am not saying those two didn't deserve it.  I was just replying to a
> claim that only mild punishments have been used.  I also noted that some
> other CAs are currently being removed or pressured to remove themselves
> for various reasons.
>
> However since the successful distrust of WoSign and Symantec, some here
> seem to have gotten "the taste for blood" and are threatening the same
> punishments for much smaller issues.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Identrust Commercial Root CA 1 EV Request

[Wayne Thayer via dev-security-policy]

It might be helpful for me to provide a better explanation of the thinking
that went into my recommendation:

The timeline of the Internal Name incident is as follows:
* Identrust appears to have stopped issuing certificates containing .INT
names prior to the BR deadline.
* They then failed to revoke existing certificates prior to the BR
deadline. This is reasonably explained as a mistake - a number of CAs
missed this deadline.
* Any CA following this list at the time should have seen the discussion
about this and taken the initiative to ensure they were in compliance.
Mozilla policy didn't require CAs to follow this list at that time, but
doing so was certainly recognized as a wise thing to do. For unknown
reasons, Identrust didn't get the message.
* In Feb 2018, an unexpired certificate containing a .INT name was reported
to Identrust. They revoked the certificate, but didn't report the incident,
and didn't revoke the other two non-expired certificates.
* In October, that one certificate was reported to this list, and Identrust
provided an incident report and disclosed two other certificates that
should have been revoked in February.

My conclusion from this chain of events is that Identrust plausibly made
two mistakes back in 2016 that left these certificates unrevoked, but was
made aware of the problem in February. At that point, Identrust failed to
investigate further and to disclose the problem. My recommendation stems
primarily from Identrust's actions in Feb which concealed the problem from
the community. I can't speak to their intentions, but I have difficulty
viewing this as a(nother) mistake. I think we've been very clear on our
expectations for CAs to disclose and remediate problems [1] and there have
been abundant examples on this list to learn from. If a CA fails to
disclose a problem and then later gets caught, a strong(er) reaction is
warranted because the CA has violated our trust, regardless of the severity
of the problem.

[1] https://wiki.mozilla.org/CA/Responding_To_An_Incident


On Wed, Nov 7, 2018 at 4:30 PM identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Friday, November 2, 2018 at 10:41:34 AM UTC-6, Wayne Thayer wrote:
> > I am recommending denial of this request.
> >
> > It was not uncommon for CAs to treat the .int TLD as an Internal Name, so
> > I'm not going to argue this point and claim that these certificates were
> > misissued because 'identrust.int' and 'identrus.int' were not registered
> > domain names.
> >
> > Under the assumption that these are Internal Names, none of these
> > certificates were issued after the BR deadline of 1-November 2015. From
> > this I would infer that Identrust was aware of the requirements. Three of
> > the disclosed certificates were not expired or revoked prior to the BR
> > Internal Name deadline of 1-October 2016:
> > https://crt.sh/?id=7852280
> > https://crt.sh/?id=882509134
> > https://crt.sh/?id=882509077
> >
> > This happened in spite of well documented incidents in which other CAs
> > failed to revoke certificates containing Internal Names [1]. One of these
> > three certificates was revoked on 22-February 2018, corresponding with
> the
> > date Nick Hatch reported it to Identrust. Identrust did not disclose the
> > incident, nor - given that the other two were never revoked - did they
> > apparently perform a scan of their certificates to identify any others.
> > This calls into question Identrust's ability to adhere to the BRs, their
> > remediation practices, and their willingness to publicly disclose
> incidents.
> >
> > Identrust has requested that Mozilla grant EV indication to the
> Commercial
> > Root CA 1 - the same root involved in this incident. Identrust's actions
> in
> > this incident are troubling and provide justification for denying the
> > higher level of trust implied by EV.
> >
> > - Wayne
> >
> > [1]
> >
> https://groups.google.com/d/msg/mozilla.dev.security.policy/00gci6NII9Y/AsQHXkltDgAJ
> >
> > On Mon, Oct 22, 2018 at 2:14 PM identrust--- via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > On Wednesday, October 17, 2018 at 9:08:41 PM UTC-4, Matt Palmer wrote:
> > > > On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via
> > > dev-security-policy wrote:
> > > > > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, Matt Palmer
> wrote:
> > > > > > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via
> > > dev-security-policy wrote:
> > > > > > > 5.Explanation about how and why the mistakes were made, and not
> > > caught and
> > > > > > > fixed earlier.
> > > > > > >
> > > > > > > IdenTrust:
> > > The certificate was generated for a server within IdenTrust.
> > > > > > > The certificate contained internal domain names which were not
> > > reachable
> > > > > > > externally.  Two domain names in the SAN (
> > > Autodiscover.identrus.int and
> > > > > > > Mercury.identrus.int) were included at that time.  When the
> > > 

Re: How harsh (in general) should Mozilla be towards CAs?

[Jakob Bohm via dev-security-policy]

On 09/11/2018 15:52, Hanno Böck wrote:

On Fri, 9 Nov 2018 14:56:41 +0100
Jakob Bohm via dev-security-policy
 wrote:


However there are also some very harsh punishments handed out, such as
distrusting some CAs (most notably happened to Symantec and WoSign,
but others are also teetering), and distrusting auditors (most notably
happened to the branch of Ernst & Young that audited the bad parts of
those two).

A line of arguments often seen is that someone failed once to do
 completely right, therefore they cannot be trusted to do
anything similar to  right at all, therefore they should no
longer be trusted.


I don't think anyone ever said something like that. Particularly
I'm not aware of any recent incident where a CA failed *once* and got
distrusted.



All 3 lines of reasoning I mentioned (with variations from case to case)
can be found in two of the most recent threads on this list.


In the cases you mention - Symantec and Wosign - there were multiple
issues. In both cases there was also plenty of opportunity for the
affected CAs to explain and improve things before a distrust was
even considered. It was repeated failures and a long list of issues
that led to the distrust.



I am not saying those two didn't deserve it.  I was just replying to a
claim that only mild punishments have been used.  I also noted that some
other CAs are currently being removed or pressured to remove themselves
for various reasons.

However since the successful distrust of WoSign and Symantec, some here
seem to have gotten "the taste for blood" and are threatening the same
punishments for much smaller issues.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
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

[Nick Pope via dev-security-policy]

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 would like to 
understand what your concerns are in as much detail as possible against what is 
specified as the current requirements for EU audits.We can then make a 
considered joint response to your concerns to ensure that ETSI audits meet your 
needs in a way works for the existing European environment.

I note your concerns about transparency and ensuring that the requirements 
certificate profile are met.  If you can put these concerns down in detail, 
along with any other issue you have, as a joint document from the root stores, 
we can provide a coordinated response on how we can address your concerns.

If you see this as "basics that are already required" rather than "wish list" 
fine, again just provide us with a clear set requirements so that we can 
properly respond.  

Nick


On Thursday, November 8, 2018 at 3:34:27 PM UTC, Ryan Sleevi wrote:
> 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, regardless of the audit scheme."
> >
> > I believe centring discussion on one particular auditor is not progressing
> > things with regards generally improving audits.
> 
> 
> That sounds very much like you don’t believe in either accountability or in
> trustworthiness being necessary for auditors. Statements like this, which
> actively promote overlooking fundamentally defective application of the
> existing requirements, calls the ETSI model itself into disrepute. I
> realize the opposite is your goal, but I hope you can understand how such
> an approach is fundamentally and deeply offensive to the trust ecosystem.
> 
> Perhaps put differently: Do you believe that the audit criteria under ETSI
> are sufficiently clear to set forward an expectation that certificates
> conform to a profile?
> 
> If no, we should not use or accept ETSI audits until such a time as the
> issues are resolved.
> If yes, then it is absolutely appropriate and necessary to discuss why
> specific auditors are failing to deliver on that.
> 
> There is no middle ground, and this is not about wishlists. This is about
> fundamentally not meeting base level expectations.
> 
> 
> >
> > I understood from my EU colleagues that Ryan and Wayne had undertaken to
> > produce a "wish list" covering requirements that they had on audits.  We
> > can then we can then discuss this with the European stakeholders and see
> > how we could best answer the wish list.  This wish list would be most
> > helpful if it builds on the measures already proposed in TS 119 403-2 and
> > its parent standards which provide specific requirements on all European
> > audits for PTC.  I understand also that we undertook to meet with WebTrust
> > in December to get an understand of each other schemes which could lead to
> > resolution of any alignment issues.
> 
> 
> This is entirely unrelated and unproductive to even suggest. Yes, ETSI
> should and must improve overall. But with regards to the current
> requirements and auditors such as TUVIT failing to appropriately apply
> them, that’s an issue that needs discussion and resolution now, and in
> public. I am glad the ESI TC recognizes there is room for improvement, just
> as there is room for improvement with WebTrust, but it is inaccurate to
> conflate that room for improvement with current failures in the
> application. This is not about not having things that are wanted - this is
> about not having the basics that are already required.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: How harsh (in general) should Mozilla be towards CAs?

[Ben Wilson via dev-security-policy]

Jakob Bohm wrote "Each of these arguments for maximum punishment and/or
maximum inconvenience for innocent bystanders is backed by a formal/legal
interpretation of existing rules as making this the only possible outcome."

I'd agree -  heavy-handed, strict enforcement of some rules unnecessarily 
punishes the
larger community and harms the Internet environment. I might be wrong, but I 
don't
believe that Mozilla or Google has an established set of "Sentencing 
Guidelines" or even
a set of procedural rights, but maybe these are needed?  And maybe we need 
additional
criteria on whether a proposed punishment is not just balanced, but also
whether it considers all of the effects (privacy, security, social, economic, 
etc.)
on subscribers and relying parties.




smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How harsh (in general) should Mozilla be towards CAs?

[Hanno Böck via dev-security-policy]

On Fri, 9 Nov 2018 14:56:41 +0100
Jakob Bohm via dev-security-policy
 wrote:

> However there are also some very harsh punishments handed out, such as
> distrusting some CAs (most notably happened to Symantec and WoSign,
> but others are also teetering), and distrusting auditors (most notably
> happened to the branch of Ernst & Young that audited the bad parts of
> those two).
> 
> A line of arguments often seen is that someone failed once to do
>  completely right, therefore they cannot be trusted to do
> anything similar to  right at all, therefore they should no
> longer be trusted.

I don't think anyone ever said something like that. Particularly
I'm not aware of any recent incident where a CA failed *once* and got
distrusted.

In the cases you mention - Symantec and Wosign - there were multiple
issues. In both cases there was also plenty of opportunity for the
affected CAs to explain and improve things before a distrust was
even considered. It was repeated failures and a long list of issues
that led to the distrust.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How harsh (in general) should Mozilla be towards CAs?

[westmail24--- via dev-security-policy]

If Google had not started the process of Symantec distrust, Mozilla would never 
have come to this step, I think.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How harsh (in general) should Mozilla be towards CAs?

[Jakob Bohm via dev-security-policy]

On 09/11/2018 12:44, westmai...@gmail.com wrote:

I think that punishments of the CAs for already exists in Mozilla Root Store 
are very mild, and some CAs often do not pay any attention to this...



However there are also some very harsh punishments handed out, such as
distrusting some CAs (most notably happened to Symantec and WoSign, but
others are also teetering), and distrusting auditors (most notably
happened to the branch of Ernst & Young that audited the bad parts of
those two).

A line of arguments often seen is that someone failed once to do
 completely right, therefore they cannot be trusted to do
anything similar to  right at all, therefore they should no
longer be trusted.

Another line of arguments is that if a CA says that the  they
did wrong was not that dangerous (because some specific argument for
why it can't be exploited against users), they are accused of not taking
security of the users seriously and should no longer be trusted.

A third line of arguments is that if a certificate was issued in a 
slightly wrong way (misspelling some mandatory part etc.), then this 
should be subject to the 24 hour revocation deadline for certificates 
that were truly misissued to the wrong person.


Each of these arguments for maximum punishment and/or maximum
inconvenience for innocent bystanders is backed by a formal/legal
interpretation of existing rules as making this the only possible
outcome.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How harsh (in general) should Mozilla be towards CAs?

[westmail24--- via dev-security-policy]

I think that punishments of the CAs for already exists in Mozilla Root Store 
are very mild, and some CAs often do not pay any attention to this...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy