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 w
As the token bad guy in this forum, I can promise you that I will resort to trickery, deception, lies, fraud, and even theft in order to get what I want. It should, perhaps, come as no surprise that those same tac
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 seem
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 to
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 a
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 ar
I could see introducing something of a probationary period of, say, 6 weeks for a public review and discussion, post-acquisition. As a sign of good faith, Mozilla would allow the new entity to continue to issue en
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 forum?
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 soon-to-b
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 espe
Yes, I think it's fair for Mozilla to stake out the position that only those certs which comply with the relevant standards, policies, etc. will be accepted. Indeed, much of the other discussion on this list of la
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 assuranc
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 words!)
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 sho
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 no
Let's also consider some of the companies that use the ubiquitous roots: Coca Cola, Pepsico, Nike, the CIA, all major US banks, and probably most major US companies and consumer brands. Consider, too, that in addi
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 t
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, fi
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 obta
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 us
Fair enough. This is absolutely the sort of stuff that needs to be part of regular auditing. I was wondering what sort of checking or enforcement you had in mind by including it in the Mozilla policy now? Perhaps
It might be fair to characterize my position as "vague but comprehensive"...if that's even possible? There are some standard-ish frameworks that could be adopted:- NIST has an existing framework that is currently
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 the
Perhaps a different way to pose the questions here is whether Mozilla wants to place any expectations on the CA's regarding fraud and the prevention thereof. Expectations beyond what the BR's address, that is. Som
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, w
I was thinking that fraud takes many forms generally speaking and that the PKI space is no different. Given that Mozilla (and everyone else) work very hard to preserve the integrity of the global PKI and that the
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: Pol
"Incomplete understanding"? That's rich.There is no reliance on certs as a protection mechanism. Rather, the use of certs/encryption help to facilitate my bad acts. If I'm doing malvertising I basically must use a
I'll be the first to admit that the example I put together is far from ideal. Perhaps a shortcoming is the lack of any explicit mention regarding the knowledge, skill, competence, etc. of the cert requester--or "s
From: Ryan SleeviSent: Tuesday, April 25, 2017 12:44 AMTo: Peter KurraschReply To: r...@sleevi.comCc: mozilla-dev-security-policySubject: Re: Removing "Wildcard
Sure, happy to take a look. I think Ryan H. makes some good points and I'm not
entirely opposed to acquisitions or transfers. My standpoint is that when a
transfer is to take place, can we be sure that the right things do happen
instead of leaving things to chance? It's the age old problem of en
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 cl
I see what you're saying and there should be some consideration for that scenario. If the acquiring company will keep all the same infrastructure and staff and if decision making authority will remain with that st
Fair enough. I propose the following for consideration:Prior to transferring ownership of a root cert contained in the trusted store (either on an individual root basis or as part of a company acquisition), a pub
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 over
I have no issue with the situations you describe below. Mozilla should act to encourage the good behaviors that we would want a new, acquiring CA to exhibit while prohibiting the bad--or at least limiting the dama
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 possession of the root
cert private key and possibly the physical space, key personnel, networking
infrastructure, revocation systems, and responsibility for s
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
By "not new", are you referring to Google being the second(?) instance where a
company has purchased an individual root cert from another company? It's fair
enough to say that Google isn't the first but I'm not aware of any commentary
or airing of opposing viewpoints as to the suitability of thi
I'm not so sure I want to optimize the system in that way, but I am concerned
about the (un)intended consequences of rapidly changing root ownership on the
global PKI.
It's not inconsequential for Google to say: "From now on, nobody can trust what
you see in the root certificate, even if some o
From: Kurt Roeckx via dev-security-policySent: Thursday, March 23, 2017 11:24 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Kurt RoeckxSubject: Re: Google Trust Services rootsOn 2017-03-23 16:39, Ryan Sleevi wrote:> On Thu, Mar 23
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 th
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 warr
I've changed the subject of this thread because I have criticisms of all 3
parties involved in this transaction and will be bringing them up
separately.
That said, "criticism" may be too strong a word in this case because I
think I do understand and appreciate the position that Mozilla is in
regar
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
Previous attempt had a major formatting snafu. Resending.
I'm 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
fo
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 aroun
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, Fe
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 s
51 matches
Mail list logo