Regarding the options listed, I would agree with the first 2 but disagree with the third.My characterization of this situation is as follows:1. Trust is not granted to everyone. This is true in virtual realms as
I think we've finally reached the essence of this debate: if there is a chance a security feature will fail, should we abandon that security feature?When it comes to EV certs and the UI treatments thereof, it
While it is to the benefit of everyone that Richard Wang and other employees at WoSign/WoTrus have learned valuable lessons over the past year, it seems to me that far too much damage has been done for Mozilla
Danny, can you please clarify your role? Are you a WoTrus employee and are you
speaking on behalf of Richard Wang?
Thanks.
Original Message
From: Danny 吴熠 via dev-security-policy
Sent: Monday, November 27, 2017 2:39 AM
Dear Gerv, Kethleen, other community friends,
First, thanks for Gerv
There's always a risk that a CA owner will create a security nightmare when we aren't looking, probationary period or not. In theory regular audits help to prevent it, but even in cases where they don't, people
raschReply To: r...@sleevi.comCc: mozilla-dev-security-policySubject: Re: Francisco Partners acquires Comodo certificate authority businessOn Tue, Oct 31, 2017 at 3:44 PM, Peter Kurrasch via dev-security-policy <dev-security-policy@lists.mozil
Both articles are long on names, short on dates. I don't fault the authors for that but it is troubling that better information wasn't made available to them.When can we expect a proper announcement in this
Clearly there has to be a way for key compromises to be remedied. If I've been following this pinning discussion correctly it seems unavoidable that we will have cases requiring certs to be issued on the
I think the plan at the root level makes sense and is reasonable, at least as far as I think I understand it. (A diagram would be nice.) At the intermediate level, however, I think more detail is needed. I'm
se MarkhamSent: Tuesday, August 22, 2017 11:01 AMTo: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: BR compliance of legacy certs at root inclusion timeOn 21/08/17 06:20, Peter Kurrasch wrote:> The CA should decide what makes the most sense for their particular&g
I don't think Mozilla can tolerate having certs that successfully chain to a root contained in its trust store that are not BR compliant.The end user trusts Mozilla products to provide a certain level of
I agree with the high-level concepts, although I would probably like to add something about "being good stewards of technologies that play a critical role in the global economy." (Feel free to use your own
This certainly shakes things up! I've had my concerns that Symantec's plan was complicated and risky, but now I'm wondering if this new path will be somewhat simpler--yet even more risky? I'm not suggesting we
My thoughts:2) Timeline.I agree with Symantec that Google's original deadlines are far too aggressive, for 2 reasons. First, I do not think Symantec can move quickly without causing further damage. Second, I do
Over the past months there has been much consternation over Symantec and the idea of "too big to fail". That is a reasonable idea but makes difficult the discussion of remedies for Symantec's past behavior: How does one impose a meaningful sanction without causing Symantec to fail outright since
Consider, too, that removing trust from a CA has an economic sanction built-in: loss of business. For many CA's I imagine that serves as motivation enough for good behavior but others...possibly not.Either way,
Hi Gerv--Is Mozilla willing to consider a simpler approach in this matter? For example, it seems that much of the complexity of the Google/Symantec proposal stems from this new PKI idea. I think Mozilla could
So how about this:A proper certificate is one that...- contains the data as provided by the requester that the requester intended to use;- contains the data as provided by the issuer that the issuer intended to
From: Gervase MarkhamSent: Wednesday, May 24, 2017 9:56 AMTo: Pete
From: Gervase MarkhamSent: Tuesday, May 23, 2017 5:23 AMTo: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Policy 2.5 Proposal: Require all CAs to have
I think the term "industry best practices" is too nebulous. For example, if I
patch some of my systems but not all of them I could still make a claim that I
am following best practices even though my network has plenty of other holes in
it.
I assume the desire is to hold CA's to account for
From: Gervase MarkhamSent: Tuesday, May 2, 2017 5:46 AMTo: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Policy 2.5 Proposal: Remove the bullet about "fra
Hi Gerv,Your updates look good! One small quibble: The bottom of the Physical Relocation section mentions the code signing trust bit, but I think that is irrelevant now?Would you feel comfortable mandating that,
:49 AMTo: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"On 01/05/17 16:28, Peter Kurrasch wrote:> Gerv, does this leave the Mozilla policy with no position statement regarding fraud in the global PK
Gerv, does this leave the Mozilla policy with no position statement regarding
fraud in the global PKI?
Original Message
From: Gervase Markham via dev-security-policy
Sent: Monday, May 1, 2017 3:36 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re:
ted though. From: Ryan SleeviSent: Friday, April 28, 2017 9:51 AMOn Fri, Apr 28, 2017 at 9:48 AM, Peter Kurrasch <fhw
.comCc: Ryan Sleevi; mozilla-dev-security-policySubject: Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices listOn Wed, Apr 26, 2017 at 3:17 PM, Peter Kurrasch <fhw...@gmail.com> wrote:
From: Ryan SleeviSent: Tuesday, April 25, 2017 12:44 AMTo: Peter KurraschReply To: r...@sleevi.comCc: mozilla-dev-security-policySubject: Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices listOn Tue, Apr 25,
of encouraging
the good and preventing the bad.
Original Message
From: Gervase Markham
Sent: Tuesday, April 25, 2017 4:28 AM
To: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots
Hi Peter,
On 25/04/17 02:10, Peter
Wildcard certs present a level of risk that is different (higher?) than for other end-entity certs. The risk as I see it is two-fold:1) Issuance: Setting aside the merits of the 10 Blessed Methods, there is no
From: Jakob Bohm via dev-security-policySent: Monday, April 24, 2017 8:42 PMOn 25/04/2017 03:10, Peter Kurrasch wrote:> F
orgReply To: Gervase MarkhamSubject: Re: Criticism of Google Re: Google Trust Services rootsOn 11/04/17 14:05, Peter Kurrasch wrote:> Is there room to expand Mozilla policy in regards to ownership issues?Subject to available time (which, as you might guess by the traffic inthis group, there's not a
I think Jacob was merely attempting to provide a more thought out alternative to my proposal basically requiring potential CA owners to first be "accepted" into the Mozilla trusted root program. There is some
sts.mozilla.orgReply To: Nick LambSubject: Re: Criticism of Google Re: Google Trust Services rootsOn Monday, 3 April 2017 23:34:44 UTC+1, Peter Kurrasch wrote:> I must be missing something still? The implication here is that a purchaser who is not yet part of the root program is permitted to take poss
: Gervase Markham
Sent: Saturday, April 1, 2017 6:02 AM
To: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots
On 31/03/17 20:26, Peter Kurrasch wrote:
> The revised example is not entirely what I had in mind (m
The revised example is not entirely what I had in mind (more on that in a
minute) but as written now is mostly OK by me. I do have a question as to
whether the public discussion as mentioned must take place before the actual
transfer? In other words, will Mozilla require that whatever entity is
Criticism of Google Re: Google Trust Services roots
On 29/03/17 20:46, Peter Kurrasch wrote:
> It's not inconsequential for Google to say: "From now on, nobody can
> trust what you see in the root certificate, even if some of it
> appears in the browser UI. The only way you can ac
se Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots
On 29/03/17 15:35, Peter Kurrasch wrote:
> In other words, what used to be a trust anchor is now no better at
> establishing trust than the end-entity cert one is trying to validate or
> investigate (for example, in
So this is the third of my 3 sets of criticisms regarding the acquisition of
the GlobalSign roots by Google Trust Services. I apologize for the significant
delay between the first 2 sets and this one. Hopefully people in the forum
still feel this discussion relevant going forward even though
This is my second of three forks of this discussion on the transfer of 2 GlobalSign roots. This thread focuses on GMO GlobalSign because in my estimation they have put themselves in a precarious position that
imagine there are more things we'll want to discuss but hopefully this is
enough to start the discussion.
On Wed, Mar 8, 2017 at 9:54 AM, Gervase Markham <g...@mozilla.org> wrote:
> On 08/03/17 03:54, Peter Kurrasch wrote:
> > - Google has acquired 2 root certificates from GMO Global
By definition, a CPS is the authoritative document on what root
certificates a CA operates and how they go about that operation. If the
GlobalSign CPS has been updated to reflect the loss of their 2 roots,
that's fine. Nobody is questioning that.
What is being questioned is whether updating the
Im trying to keep score here but am having difficulties. Can someone
confirm if the following statements are correct:- Google has acquired
2 root certificates from GMO GlobalSign but not the company itself. GMO
GlobalSign will continue to own other roots and will use only those other roots
What you've stumbled into is the unspoken truth that CA's want to have their
cake and eat it too.
Specifically, they market themselves and their products under the umbrella of
security: "You want to be secure on the Internet, right? We can help you do
that!" Then, most all CA's will turn
Would it be possible to get a more precise answer other than "in accordance
with"? I am left to assume that in fact no verification was performed because
the previous verification was in the 39 month window.
Original Message
From: douglas.beattie--- via dev-security-policy
Sent: Tuesday,
By and large I'd say that Matt's no's should instead be yes's. If we adopt the
standpoint that releasing a domain is equivalent to saying "I no longer use
that name" then a revocation is equivalent to adding "...and anyone who does
use that name must surely be an imposter."
In other words, we
. I think it would be useful to have some ideas in place in
advance of any such scenarios.
Original Message
From: Kristian Fiskerstrand
Sent: Wednesday, November 2, 2016 5:41 PM
To: Peter Kurrasch; gerhard.tin...@gmail.com;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re
This raises an interesting point and I'd be interested in any comments that Comodo or other CA's might have.It appears we have a situation where a cert is being issued to what is presumably an authorized party
I think these are both good points and my recommendation is that Mozilla deny GDCA's request for inclusion.We should not have to explain something as basic as document versioning and version control. If GDCA can
I agree that it probably is not worth dwelling on the "Andy Ligg question" in
particular but I think there is a broader issue at play which is worth
addressing: deception.
I think there is ample evidence that WoSign engaged in a deliberate,
persistent, and extensive campaign of deception
Don't sell your namesake domain short! Sure, the Google domains are subject to
different types of attacks than most others but any domain with a cert has
value. For example, I'd be happy to use gerv.net as a landing page for my spam
campaign or as a phishing site or, even better, as a host for
I think we're well past the point where a "do-over" can be considered a
reasonable remedy. The problem is not simply one in which certs were issued
improperly nor is it simply one in which there were mistakes in the CA
infrastructure. Such problems, I think, could fall under a category where
So if WoSign will not be present to discuss possible sanctions against WoSign,
what are we to infer from that? Is Qihoo 360 acting in a capacity that is more
than just an investor in WoSign?
I'm trying not to get too far ahead of things, but this seems to be a very
curious turn of events.
, Peter Kurrasch wrote:
> * Revocation: If a particular cert has been revoked for any reason, I should
> be able to find that out so that I will know not to use it. Ideally this is
> handled automatically in software but for various reasons it doesn't always
> work out that way.
Well, well. Here we are again, Ryan, with you launching into a bullying, personal attack on me instead of seeking to understand where I'm coming from and why I say the things I say. You may have noticed that I do
I have a hard time seeing how any sort of white list solution will actually mitigate any of the bad behavior exhibited by WoSign. From my perspective, I think we can make a pretty clear case that WoSign is a
-security-pol...@lists.mozilla.org
Subject: Re: Cerificate Concern about Cloudflare's DNS
Bonjour,
Le lundi 12 septembre 2016 14:30:56 UTC+2, Peter Kurrasch a écrit :
> I noticed there a several other domains listed on that cert besides Han's
> (and wildcard versions for each). Unle
I noticed there a several other domains listed on that cert besides Han's (and
wildcard versions for each). Unless Han is the registrar or has some other
affiliation with those domains it seems to me there is a risk of some private
key compromise situation.
Also, if I want to add a new domain
From: Patrick FigelSent: Friday, July 8, 2016 4:43 PMBefore getting into specifics, I should say that you're likely to get abetter answer to most of these question on the IETF ACME WG mailing list[1].On 08/07/16 16:36, Peter Kurrasch wrote:> I see on the gitub site for
be abused and lead to certificate mis-issuance?
Original Message
From: Matt Palmer
Sent: Friday, July 1, 2016 12:16 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: StartEncrypt considered harmful today
On Thu, Jun 30, 2016 at 11:10:45AM -0500, Peter Kurrasch wrote:
> V
8, 2016 at 7:56:44 AM UTC-5, Peter Kurrasch wrote:
> I have comments as well. I made it to only Section 3.2.1 before I decided I
> have too many concerns about Let's Encrypt to include in a review of the CPS.
> I'll raise them in a separate thread, so here are my comments on just th
Let's be even more pointed: How do we know that *any* of the certs issued
through this interface were issued to the right person for the right domain?
How can StartCom make that determination?
Original Message
From: Daniel Veditz
Sent: Thursday, June 30, 2016 12:04 PM
...
How many
Very interesting. This is exactly the sort of thing I'm concerned about with
respect to Let's Encrypt and ACME.
I would think that all CA's should issue some sort of statement regarding the
security testing of any similar, Internet-facing API interface they might be
using. I would actually
I have comments as well. I made it to only Section 3.2.1 before I decided I have too many concerns about Let's Encrypt to include in a review of the CPS. I'll raise them in a separate thread, so here are my
?
Original Message
From: Ryan Sleevi
Sent: Saturday, May 28, 2016 11:29 PM
To: Peter Kurrasch
Reply To: r...@sleevi.com
Cc: Kathleen Wilson; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Job: Is it OK to post a job listing in this forum?
Reposing from the right email address
I'm opposed to allowing job postings in this forum. The focus should be policy
as that is the reason we have gathered here.
Job postings generally are intended for people in a particular country with a
particular level of experience who are actively seeking or receptive to a new
job. Sending
ut I think
it's worth fleshing out if people are interested.
Original Message
From: Nick Lamb
Sent: Thursday, May 26, 2016 1:25 PM
On Thursday, 26 May 2016 15:40:35 UTC+1, Peter Kurrasch wrote:
> I might use a perfectly good cert in a "bad" way:
Maybe it's worthwhile to consid
It strikes me that some people might not have a good idea how people use certs to do bad things. As the token bad guy in this forum I'll take it upon myself to share some examples of how I might use a perfectly good cert in a "bad" way:* Create a phishing site to harvest login credentials from
Hi Kathleen,
My recommendation is for Mozilla to reject this request from Symantec on the
grounds that it is unnecessary. As others have pointed out recently, the chief
function of a CA is to certify identity. That certification should be ably met
with the regular cert issuance procedures
Hi Dimitris, You certainly echo the sentiment of others in this forum by directing me to the CABF but my concerns are particular to HARICA at this point. Simply put, the CABF BR has security gaps in section
I've reviewed the ComSign CPS and while it has a lot of legal language in it, it lacks a certain legal and technical precision that is needed in this case. For example, there is frequent use of the term
FYI, the RFC URL in BR 1.3.1 section 1.6.1 for CAA is malformed.
Original Message
From: Phillip Hallam-Baker
Sent: Tuesday, December 8, 2015 11:37 AM
People are using CAA.
Cool!
___
dev-security-policy mailing list
From: Kathleen WilsonSent: Wednesday, December 2, 2015 2:18 PMOn 12/2/15 11:13 AM, Peter Kurrasch wrote
I don't so much have a problem with the change but I would like to know if this
is fairly common across other cert issuers?
Personally I'm of the opinion that email is inherently insecure which makes it
a bad mechanism to use in the course of trying to establish trust. However, my
concern at
: Gervase MarkhamSent: Monday, October 12, 2015 10:56 AMOn 08/10/15 14:27, Peter Kurrasch wrote:> 2. Loss of visibility/consistency/input: If Mozilla decides to exit the> code signing
: Matt PalmerSent: Wednesday, October 7, 2015 12:40 AMOn Tue, Oct 06, 2015 at 01:05:52PM -0500, Peter
ally, what is the plan for Linux after the code signing trust bit is
dropped?
Original Message
From: Erwann Abalea
Sent: Monday, October 5, 2015 3:17 PM
Le lundi 5 octobre 2015 19:36:03 UTC+2, Peter Kurrasch a écrit :
> TL;DR... [...Peter and Ryan more than disagree...]
Please, stay cool, ki
TL;DR...that is until I saw you calling me a concern troll. You make it abundantly clear you believe I am far too ignorant to participate meaningfully in this discussion but I wish you had the humility to ask
Hi Kirk--Would it be possible to provide some specific examples of the applications you have in mind? Or maybe some use cases that would be relevant here (in the context of code signing)? My contention has been a
Hi Kathleen,
This summary looks pretty good. I think you could add the point raised by Man
Ho which essentially asks the question of who should/can/will evaluate the
trustworthiness of root certs. There are pros and cons either way on that one.
One last comment I'll make is that, among other
lla-dev-security-pol...@lists.mozilla.orgSubject: Re: Policy Update Proposal: Remove Code Signing Trust BitOn 9/15/15 5:42 AM, Peter Kurrasch wrote:> So is Mozilla becoming, in effect, just a browser company? If email is de-prioritized and code signing is on life support, that would be good to
So is Mozilla becoming, in effect, just a browser company? If email is
de-prioritized and code signing is on life support, that would be good to know
before getting too bogged down with issues that aren't necessarily important to
Mozilla. I'm just trying to understand where the boundaries are.
It seems to me that the benefits of this proposed change are minimal while the negative impacts to embedded systems are significant. Perhaps I've missed something? It should be understood that code signing is
Thanks for sharing this correspondence, Richard. I'm not sure the committee
fully appreciates the scope of the problem but it's good to see them make an
effort. I was actually surprised that the committee seems to understand as much
as they do so perhaps this will be just a first step in a
to worry about CT because, as it turns out, I can get away
with quite a lot.
Original Message
From: Chris Palmer
Sent: Monday, June 8, 2015 1:38 PM
On Fri, Jun 5, 2015 at 8:04 AM, Peter Kurrasch fhw...@gmail.com wrote:
Certificate Transparency gets us what we want, I think. CT works
globally
You have a lot of ideas in here, Richard!
Asking the question what is the increased risk we face by introducing new CA's
and new roots into the trust store? is a good idea. How we go about answering
that gets tricky. It might be helpful to articulate some threat models facing
CA's, both
Further to David's points, I'm wondering how far Mozilla would be willing to
go when a controversial transfer is proposed. Is removal from the trust store
on the table?
For example suppose DigiNotar wants to get back in the cert business and buys
up GoDaddy, what would we do then?
guys--just looking to use some real examples.)
Original Message
From: Rob Stradling
Sent: Tuesday, April 14, 2015 8:14 AM
To: Peter Kurrasch; dev-security-policy@lists.mozilla.org
Subject: Re: What is the security benefit of certificate transparency?
Peter, CT is a detection mechanism, so I'd
, Peter Kurrasch wrote:
Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov
and let's further suppose that CNNIC includes this cert in the CT data
since they have agreed to do that. What happens next?
Where I'm going with this is that I'm trying to figure out if agreeing
that nobody will figure it out.
Follow-up question: how much time must transpire from the time a cert is issued
to when a browser is expected to start accepting it?
Original Message
From: Chris Palmer
Sent: Tuesday, April 14, 2015 1:09 PM
To: Peter Kurrasch
Cc: Rob Stradling; dev-security-policy
Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and
let's further suppose that CNNIC includes this cert in the CT data since they
have agreed to do that. What happens next?
Where I'm going with this is that I'm trying to figure out if agreeing to
support CT is a
Perhaps there is a middle ground of remedies. For consideration:
1) Mozilla could refuse to validate any intermediate cert which CNNIC has
issued to a subordinate CA. (Note: I'm not sure that's the technically precise
term here.) Basically, CNNIC may issue intermediates for itself but those
Someone correct me if I'm wrong, but my understanding of the Superfish debacle
is that sites that have EV certs would get the green bar treatment on other
devices but not on the Lenovo devices where Superfish was installed. The
implication, then, is that the green bar provides no improvement
could get every CA
to just agree to that much.
Original Message
From: Gervase Markham
Sent: Wednesday, March 25, 2015 6:54 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Name Constraints
On 24/03/15 21:12, Peter Kurrasch wrote:
As to who should be forced to constrain
I'm confused because it sounds like you're advocating for the status quo but I
didn't think that was your position?
Original Message
From: Gervase Markham
Sent: Tuesday, March 24, 2015 4:25 AM
To: Peter Kurrasch; Richard Barnes;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re
explains where I'm coming from. From: Gervase MarkhamSent: Tuesday, March 24, 2015 12:37 PMOn 24/03/15 17:26, Peter Kurrasch wrote: Be car
From: Gervase MarkhamSent: Thursday, March 19, 2015 8:53 AMTo: Peter Kurrasch; Richard Barnes; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Name ConstraintsOn 12/03/15 22:54, Peter Kurrasch wrote: This backwar
AMTo: ryan-mozdevsecpol...@sleevi.comCc: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.org; Kathleen WilsonSubject: Re: Propose Removal of E-Guven rootOn Fri, Mar 20, 2015 at 10:37 AM, Ryan Sleevi ryan-mozdevsecpol...@sleevi.com wrote:On Thu, March 19, 2015 3:53 pm, Peter Kurr
Hi Volkan,
Thanks for your response. I think it addresses my concerns though I would like
one final clarification: The OSC intermediate cert is, as I understand it, to
be used exclusively for OSC end certs. Will this intermediate chain directly to
the H5 root or will there be other
As suggested by others, I submitted comments to CABF questions email address
regarding the code signing cert requirements.
I'm including them below in the event there is any interest in the wider
Mozilla community in discussing the issues further in a public forum.
Thanks.
== Submitted
1 - 100 of 104 matches
Mail list logo
