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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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,
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
"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
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
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
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
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,
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.
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
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
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
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
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
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
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:
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
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,
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
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
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
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
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
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
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
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
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
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
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
46 matches
Mail list logo
