Re: Disallowed company name

2018-06-01 Thread Peter Kurrasch via dev-security-policy
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

Re: On the value of EV

2017-12-17 Thread Peter Kurrasch via dev-security-policy
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

Re: Possible future re-application from WoSign (now WoTrus)

2017-12-01 Thread Peter Kurrasch via dev-security-policy
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

Re: Possible future re-application from WoSign (now WoTrus)

2017-11-28 Thread Peter Kurrasch via dev-security-policy
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

Re: Acquisition policy (was: Francisco Partners acquires Comodo certificate authority business)

2017-11-09 Thread Peter Kurrasch via dev-security-policy
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

Re: Francisco Partners acquires Comodo certificate authority business

2017-10-31 Thread Peter Kurrasch via dev-security-policy
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

Re: Francisco Partners acquires Comodo certificate authority business

2017-10-31 Thread Peter Kurrasch via dev-security-policy
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

Re: DigiCert-Symantec Announcement

2017-10-11 Thread Peter Kurrasch via dev-security-policy
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

Re: DigiCert-Symantec Announcement

2017-09-07 Thread Peter Kurrasch via dev-security-policy
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

Re: BR compliance of legacy certs at root inclusion time

2017-08-23 Thread Peter Kurrasch via dev-security-policy
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

Re: BR compliance of legacy certs at root inclusion time

2017-08-21 Thread Peter Kurrasch via dev-security-policy
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

Re: DigiCert-Symantec Announcement

2017-08-03 Thread Peter Kurrasch via dev-security-policy
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

Re: DigiCert-Symantec Announcement

2017-08-02 Thread Peter Kurrasch via dev-security-policy
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

Re: Symantec response to Google proposal

2017-06-16 Thread Peter Kurrasch via dev-security-policy
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

An alternate perspective on Symantec

2017-06-06 Thread Peter Kurrasch via dev-security-policy
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

Re: On remedies for CAs behaving badly

2017-06-05 Thread Peter Kurrasch via dev-security-policy
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,

Re: Symantec response to Google proposal

2017-06-05 Thread Peter Kurrasch via dev-security-policy
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

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

2017-06-01 Thread Peter Kurrasch via dev-security-policy
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

Re: Policy 2.5 Proposal: Require all CAs to have appropriate network security

2017-05-24 Thread Peter Kurrasch via dev-security-policy
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

Re: Policy 2.5 Proposal: Require all CAs to have appropriate network security

2017-05-24 Thread Peter Kurrasch via dev-security-policy
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

Re: Policy 2.5 Proposal: Require all CAs to have appropriate network security

2017-05-22 Thread Peter Kurrasch via dev-security-policy
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

Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

2017-05-03 Thread Peter Kurrasch via dev-security-policy
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.

Re: Policy 2.5 Proposal: Incorporate Root Transfer Policy

2017-05-01 Thread Peter Kurrasch via dev-security-policy
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,

Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

2017-05-01 Thread Peter Kurrasch via dev-security-policy
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

Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

2017-05-01 Thread Peter Kurrasch via dev-security-policy
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:

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

2017-04-28 Thread Peter Kurrasch via dev-security-policy
"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

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

2017-04-28 Thread Peter Kurrasch via dev-security-policy
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

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

2017-04-26 Thread Peter Kurrasch via dev-security-policy
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,

Re: Criticism of Google Re: Google Trust Services roots

2017-04-25 Thread Peter Kurrasch via dev-security-policy
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

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

2017-04-24 Thread Peter Kurrasch via dev-security-policy
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

Re: Criticism of Google Re: Google Trust Services roots

2017-04-24 Thread Peter Kurrasch via dev-security-policy
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

Re: Criticism of Google Re: Google Trust Services roots

2017-04-24 Thread Peter Kurrasch via dev-security-policy
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

Re: Criticism of Google Re: Google Trust Services roots

2017-04-11 Thread Peter Kurrasch via dev-security-policy
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

Re: Criticism of Google Re: Google Trust Services roots

2017-04-05 Thread Peter Kurrasch via dev-security-policy
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

Re: Criticism of Google Re: Google Trust Services roots

2017-04-03 Thread Peter Kurrasch via dev-security-policy
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

Re: Criticism of Google Re: Google Trust Services roots

2017-03-31 Thread Peter Kurrasch via dev-security-policy
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

Re: Criticism of Google Re: Google Trust Services roots

2017-03-30 Thread Peter Kurrasch via dev-security-policy
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

Re: Criticism of Google Re: Google Trust Services roots

2017-03-29 Thread Peter Kurrasch via dev-security-policy
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

Re: Google Trust Services roots

2017-03-23 Thread Peter Kurrasch via dev-security-policy
‎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

Criticism of GMO GlobalSign Re: Google Trust Services roots

2017-03-10 Thread Peter Kurrasch via dev-security-policy
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

Criticism of Mozilla Re: Google Trust Services roots

2017-03-09 Thread Peter Kurrasch via dev-security-policy
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

Re: Google Trust Services roots

2017-03-09 Thread Peter Kurrasch via dev-security-policy
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

Re: Google Trust Services roots

2017-03-07 Thread Peter Kurrasch via dev-security-policy
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

Re: Let's Encrypt appears to issue a certificate for a domain thatdoesn't exist

2017-03-01 Thread Peter Kurrasch via dev-security-policy
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

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

2017-03-01 Thread Peter Kurrasch via dev-security-policy
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,

Release and revoke (was: Let's Encrypt appears to issue a certificate for a domain that doesn't exist)

2017-02-23 Thread Peter Kurrasch via dev-security-policy
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