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

[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 should give relying parties every opportunity to determine 
legitimate-or-fraud to the greatest extent possible. Granted the real world is 
not quite so simple but I think that's (part of?) the spirit of what we're here 
to do.


  Original Message  
From: Matt Palmer via dev-security-policy
Sent: Wednesday, February 22, 2017 10:32 PM
To: dev-security-policy@lists.mozilla.org
Reply To: Matt Palmer
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that 
doesn't exist

On Wed, Feb 22, 2017 at 10:00:45PM -0500, George Macon via dev-security-policy 
wrote:
> On 2/22/17 7:30 PM, Gervase Markham wrote:
> > On Hacker News, Josh Aas writes:
> > Update: Squarespace has confirmed that they did register the domain and
> > then released it after getting a certificate from us."
> 
> In this case, should Squarespace have requested that the certificate be
> revoked before releasing the domain?

No.

> Is there a way to automatically detect that the domain was released? (I
> suspect the answer to this question is "not easily".)

There have been feeds provided in the past (they may still exist, but I
haven't needed to look for them for some years) for registered domains, I
don't know if something exists for expiration, but it certainly seems like
it, given the speed with which squatters appear able to pick up expired
domains.

> Would it make sense to prohibit certificate issuance during the grace
> period?

No.

- Matt

___
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: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

[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, February 28, 2017 6:46 AM‎

...snip...
‎
> I also would like to have an official reply from GlobalSign saying that "on 
> the date they issue the certificate the domain exists".

On the date that the certificate was issued it was verified in accordance with 
the Domain Verification requirements in the BRs.

Doug Beattie
GlobalSign
___
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: Let's Encrypt appears to issue a certificate for a domain thatdoesn't exist

[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 around and say: "Oh by the way, if you 
encounter a situation in which something bad happens it's not our fault because 
we couldn't possibly ‎confirm that what we say is secure is in fact secure."

Let's Encrypt is not unique as I think most CA's express this viewpoint in one 
form or another. This may be acceptable from a legal or compliance standpoint 
but not in terms of reputation. As people find themselves in bad situations 
because of a malicious site that used one of their certs, they very well might 
blame the CA.

Certainly a CA does not want the reputation of being "the preferred cert vendor 
for malicious sites everywhere" so whatever principles they try to espouse, the 
reality will be more complicated.


  Original Message  
From: wuyi via dev-security-policy
Sent: Friday, February 24, 2017 1:57 AM
To: vtlynch; dev-security-policy
Reply To: wuyi
Subject: Re: Let's Encrypt appears to issue a certificate for a domain 
thatdoesn't exist

Exactly that’s the meaning of “entitle”.
Based on the interpretation, I understand that when a firefighter is on a 
vocation, even a fire breaks next to him, it’s of his choice to go hiking, fly 
kites whatever as he may only be entitled on weekdays rather than in a 
vocation. 
IMO, the point of the Let’s Encrypt’ CP 9.6.3 is to ensure that the CA has 
privilege to revoke certificate when certain issue happens as it describes. The 
deeper meaning of it is that it ensures the CA has ability to maintain online 
security anytime, but it’s enough. I am not going to debate here, I would 
rather go and teach my grandfather those green lock icons from some certain CA 
means anything but online security they states. 
Nio 
SZU


发自我的iPhone

-- Original --
From: Vincent Lynch via dev-security-policy 

Date: Fri,Feb 24,2017 15:10
To: dev-security-policy , wuyi 
<594346...@qq.com>
Subject: Re: Let's Encrypt appears to issue a certificate for a domain 
thatdoesn't exist



As you have quoted it, Let's Encrpyt's CPS says:

"the CA is *entitled* to revoke the certificate"

The key word is "entitled." Meaning that Let's Encrypt may revoke the
certificate if they chose, but are not required to. Therefore not revoking
the certificate is compatible with their CPS.

It's important to realize this is not an argument about what *should* be
done or what we think is right, but what *can* be done under the current
rules and regulations.

The fact is that the CAB/F BR's are so (intentionally) ambiguous about
"high risk" certificates that there is no real way meaning to that section
and no real way for a CA to violate said section.




As others have mentioned, please can we stop writing unrelated comments on
this thread. This thread is about a specific report about a DV cert being
issued to a non-existent domain. That report turned out to be false. Unless
comments are about that report, this is the wrong thread to post in.

I would also encourage anyone interested in the topic of high risk requests
and certs being issued to phishing sites to see Eric Mill's comment in this
thread. He has provided a link to past discussion on this topic, and I can
promise you that however displeasing and shocking this practice may be, it
has already been considered and debated.



On Fri, Feb 24, 2017 at 12:36 AM wuyi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> According to what I’ve known,
>
>
> “Acknowledgment and Acceptance: An acknowledgment and acceptance that the
> CA is entitled to revoke the certificate immediately if the Applicant were
> to violate the terms of the Subscriber or Terms of Use Agreement or if the
> CA discovers that the Certificate is being used to enable criminal
> activities such as phishing attacks, fraud, or the distribution of
> malware.” (Let’s Encrypt’ CP 9.6.3)
>
>
>
>
> Now that a phishing site has been detected with a valid certificate, but
> no immediate action was taken on it. I don’t think that this is what a CA,
> who states to “Support a more secure and privacy-respecting Web” is
> supposed to do.
>
>
>
>
> Quoted from Google’s Policy, “it would be no different than a firefighter
> who was not responding to fires in which people died.”
>
>
> It may be difficult to sort what types of domains are high risk, but when
> a certificate was used in this way without being revoked, it was no
> difference from the Google CP’s metaphor. As an Internet user I was
> disappointed about that, and those in the LE’ CP above can be treated as
> nonsense.
>
>
> Nio
> SZU
>
>
> On Fri, Feb 24, 2017 at 01:12:38AM +, Richard Wang via
> dev-security-policy wrote:
>
>
> > >I am sure this site: https://www.microsoftonline.us.com/ is a ph

Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

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 
for the various products and services they choose to offer.- No 
public announcement of the acquisition was made prior to January 26, 2017 via 
the Google security blog.- No disclosure has been made regarding what 
specific items were acquired, including such things as: "private key 
material" (HSM's and whatnot); computer equipment used as web 
servers, OCSP responders, etc.; domain names, IP addresses, and other 
infrastructure used in the operations and maintenance of the acquired roots; 
data such as subscriber lists, server logs, payment details and histories, 
certificate issuance activities and histories, etc.; and any access rights to 
physical space such as offices, data centers, development and test facilities, 
and so forth.- The scope of impact to existing GlobalSign customers 
is not known. Neither GMO GlobalSign nor Google have notified any existing 
clients of the acquisition.- The GlobalSign web site has no mention 
of this acquisition for reasons which are unknown. Further, the web site does 
not make their CP/CPS documents readily available limiting the ability for 
current subscribers and relying parties to decide if continued use of a cert 
chaining up to these roots is acceptable for them.- A relying party 
who actually takes the initiative to review a certificate chain will see that 
it is anchored (or "verified by") GlobalSign. No mention of Google 
will be made anywhere.- Google has acquired these roots in order to 
"better serve" their subscribers, which are organizations (not 
people) throughout the many Google companies. Relying parties are not affected 
positively or negatively by this acquisition. - Mozilla granted 
Google's request to keep the acquisition confidential based on statements 
made by Google and Google's auditor E&Y. GlobalSign nor their auditors 
offered any opinion on this matter.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 for the 
various products and services they choose to offer.

- No 
public announcement of the acquisition was made prior to January 26, 2017 via 
the Google security blog.

- No disclosure has been made 
regarding what specific items were acquired, including such things as: 
"private key material" (HSM's and whatnot); computer 
equipment used as web servers, OCSP responders, etc.; domain names, IP 
addresses, and other infrastructure used in the operations and maintenance of 
the acquired roots; data such as subscriber lists, server logs, payment details 
and histories, certificate issuance activities and histories, etc.; and any 
access rights to physical space such as offices, data centers, development and 
test facilities, and so forth.

- The scope of impact to 
existing GlobalSign customers is not known. Neither GMO GlobalSign nor Google 
have notified any existing clients of the acquisition.

- 
The GlobalSign web site has no mention of this acquisition for reasons which 
are unknown. Further, the web site does not make their CP/CPS documents readily 
available limiting the ability for current subscribers and relying parties to 
decide if continued use of a cert chaining up to these roots is acceptable for 
them.

- A relying party who actually takes the initiative 
to review a certificate chain will see that it is anchored (or 
"verified by") GlobalSign. No mention of Google will be made 
anywhere.

- Google has acquired these roots in order to 
"better serve" their subscribers, which are organizations 
(not people) throughout the many Google companies. Relying parties are not 
affected positively or negatively by this acquisition. 

- 
Mozilla granted Google's request to keep the acquisition confidential 
based on statements made by Google and Google's auditor E&Y. 
GlobalSign nor their auditors offered any opinion on this 
matter.



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

Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

  Previous attempt had a major formatting snafu. Resending.From: Peter KurraschSent: Tuesday, March 7, 2017 9:35 PM‎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 for the various products and services they choose to offer going forward. There is no affiliation or business relationship between GMO GlobalSign and Google after the completion of the acquisition. - No public announcement of the acquisition was made prior to January 26, 2017 via the Google security blog.- No disclosure has been made regarding what specific items were acquired, including such things as: "private key material" (HSM's and whatnot); computer equipment used as web servers, OCSP responders, etc.; domain names, IP addresses, and other infrastructure used in the operations and maintenance of the acquired roots; data such as subscriber lists, databases, server logs, payment details and histories, certificate issuance activities and histories, etc.; any access rights to physical space such as offices, data centers, development and test facilities, and so forth; and last, but not least, any personnel, documentation, training materials, or other knowledge products.- The scope of impact to existing GlobalSign customers is not known. Neither GMO GlobalSign nor Google have notified any existing clients of the acquisition.- The GlobalSign web site has no mention of this acquisition for reasons which are unknown. Further, the web site does not make their CP/CPS documents readily available limiting the ability for current subscribers and relying parties to decide if continued use of a cert chaining up to these roots is acceptable to them.- A relying party who takes the initiative to review a certificate chain that goes up to either of the acquired roots will see that it is anchored (or "verified by") GlobalSign. No mention of Google will be made anywhere in the user interface.- Google has acquired these roots in order to better serve their subscribers, which are organizations (not people) throughout the many Google companies. Relying parties (i.e. end users of the various Google products) are not affected positively or negatively by this acquisition.- Mozilla granted Google's request to keep the acquisition confidential based on statements made by Google and Google's auditor E&Y. Neither GlobalSign nor their auditors offered any opinion on this matter.Thank you.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[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 GlobalSign CPS is
sufficient to address the needs, concerns, questions, or myriad other
issues that are likely to come up in the minds of GlobalSign subscribers
and relying parties--and, for that matter, Google's own subscribers and
relying parties.  To that, I think the answer must be: "no, it's not
enough".  Most people on the internet have never heard of a CPS and of
those who have, few will have ever read one and fewer still will have read
the GlobalSign CPS.

It would be good if you could elaborate more on what steps Google will be
taking to communicate to the general public that GlobalSign means
GlobalSign except when it means Google and that sometimes Google will mean
GlobalSign as well.



On Wed, Mar 8, 2017 at 12:02 PM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > Jakob: An open question is how revocation and OCSP status for the
> > existing intermediaries issued by the acquired roots is handled.
>
> Google is responsible for producing CRLs for from these roots. We are also
> currently
> relying on the OCSP responder infrastructure of GlobalSign for this root
> but are
> In the process of migrating that inhouse.
>
> > Jakob: Does GTS sign regularly updated CRLs published at the
> (GlobalSign) URLs
> > listed in the CRL URL extensions in the GlobalSign operated non-expired
> > intermediaries?
>
> At this time Google produces CRLs and works with GlobalSign to publish
> those CRLs.
>
> > Jakob: Hopefully these things are answered somewhere in the GTS CP/CPS
> for the
> > acquired roots.
>
> This level of detail is not typically included in a CPS, for example, a
> service may change
> Which internet service provider or CDN service they use and not need
> update their CP/CPS.
>
>
> > Jakob: Any relying party seeing the existing root in a chain would see
> the
> > name GlobalSign in the Issuer DN and naturally look to GlobalSign's
> > website and CP/CPS for additional information in trying to decide if
> > the chain should be trusted.
>
> The GlobalSign CPS indicates that the R2 and R4 are no longer under their
> control.
>
> Additionally given the long term nature of CA keys, it is common for the
> DN not to accurately
> represent the organization that controls it. As I mentioned in an earlier
> response in the 90’s I
> created roots for a company called Valicert that has changed hands several
> times, additionally
> Verisign, now Symantec in this context has a long history of acquiring CAs
> and as such they
> have CA certificates with many different names within them.
>
> > Jakob: A relying party might assume, without detailed checks, that these
> roots
> > are operated exclusively by GlobalSign in accordance with GlobalSign's
> > good reputation.
>
> As the former CTO of GlobalSign I love hearing about their good reputation
> ;)
>
> However I would say the CP/CPS is the authoritative document here and since
>  GMO GlobalSign CP/CPS clearly states the keys are no longer in their
> control I believe this
> Should not be an issue.
>
> > Jakob: Thus a clear notice that these "GlobalSign roots" are no longer
> > operated by GlobalSign at any entrypoint where a casual relying party
> > might go to check who "GlobalSign R?" is would be appropriate.
>
> I would argue the CA’s CP/CPS’s are the authoritative documents here and
> would
> Satisfy this requirement.
>
> > Jakob: If possible, making Mozilla products present these as "Google",
> not
> > "GlobalSign" in short-form UIs (such as the certificate chain tree-like
> > display element).  Similarly for other root programs (for example, the
> > Microsoft root program could change the "friendly name" of these).
>
> I agree with Jakob here, given the frequency in which roots change hands,
> it would make
> sense to have an ability to do this. Microsoft maintains this capability
> that is made available
> to the owner.
>
> There are some limitations relative to where this domain information is
> used, for example
>  in the case of an EV certificate, if Google were to request Microsoft
> use this capability the
> EV badge would say verified by Google. This is because they display the
> root name for the
> EV badge. However, it is the subordinate CA in accordance with its CP/CPS
> that is responsible
> for vetting, as such the name displayed in this case should be GlobalSign.
>
> Despite these limitations, it may make sense in the case of Firefox to
> maintain a similar capability.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-poli

Criticism of Mozilla Re: Google Trust Services roots

[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
regarding confidential transactions such as this.  And while Mozilla's
actions seem perfectly reasonable, I can't help but think this transaction
is a train wreck in the making.  It would be good if Mozilla could prevent
train wrecks when possible and to do so probably requires updates to the
Root Transfer Policy.

To that end, here are some thoughts to get things going:

* Types of transfers:  I don't think the situation was envisioned where a
single root would be transferred between entities in such a way that
company names and branding would become intermingled.  My own personal
opinion is that such intermingling is not in the public interest and should
be prohibited.  That very likely could be too strong a stance for
Mozilla--which is fine--but it would be good to have Mozilla's position
clearly articulated should a situation like this arise again.

* Manner of transfer:  As we learned from Ryan H., a second HSM was
introduced for the transfer of the private key meaning that for a period of
time 2 copies of the private key were in existence.  Presumably one copy
was destroyed at some point, but I'm not familiar with any relevant
standards or requirements to know when/how that takes place.  Whatever the
case may be, this situation seems to fall outside of the Root Transfer
Policy as I now read it.  Also, did GlobalSign ever confirm to Mozilla that
they are no longer in possession of or otherwise have access to the private
key for those 2 roots?

* Conduct of the transfer:  I think an expectation should be set that the
"current holder of the trust" must be the one to drive the transfer.  Trust
can be handed to someone else; reaching in and taking trust doesn't sound
very...trustworthy?  To that end, I think the policy should state that the
current root holder must do more than merely notify Mozilla about the
change in ownership; the holder (and their auditor) must provide the
audits, attestations, and answers to questions that come up.  Only after
the transfer is complete would the "new holder" step in to perform those
duties.

* Public notification:  I appreciate that confidentiality is required when
business transactions are being discussed but at some point, in the
interest of transparency, the public must be notified of the transfer.  I
think this is implied (or assumed) in the current policy, but it might be
good to state explicitly that a public announcement must be made.  I would
add that making an announcement at a CABF meeting is all well and good, but
considering that most people on the Internet are not able to attend those
meetings it would be good if an announcement could be made in other forums
as well.


I 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  wrote:

> On 08/03/17 03:54, Peter Kurrasch wrote:
> > - Google has acquired 2 root certificates from GMO GlobalSign but not
> > the ‎company itself.
>
> Yes.
>
> > GMO GlobalSign will continue to own other roots and
> > will use only those other roots for the various products and services
> > they choose to offer going forward.
>
> Not quite. GMO GlobalSign continues to control some subCAs of the roots
> it sold to Google, and is using those (presumably) to wind down its
> interest in those roots over time or support customer migrations to
> other roots. This happens to include issuing EV certificates.
>
> > There is no affiliation or business
> > relationship between GMO GlobalSign and Google after the completion of
> > the acquisition.
>
> We don't have information on this; the terms of the deal, and indeed any
> other deals the two companies may have made, are not public.
>
> > - No public announcement of the acquisition was made prior to January
> > 26, 2017 via the Google security blog.
>
> Depends what you mean by announcement, but they applied in a public bug
> for inclusion in the Mozilla root program in December:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1325532
> and, I think, announced their intention in a publicly-minuted meeting of
> the CAB Forum in Redmond in mid-October 2016.
>
> > - No disclosure has been made regarding what specific items were
> > acquired, including such things as: "private key material" (HSM's and
> > whatnot); computer equipment used as web servers, OCSP responders, etc.;
> > domain names, IP addresses, and other infrastructure used in the
> > operations and maintenance of the acquired roots; data such as
> > subscriber lists, databases, server logs, payment details and histories,
> > certificate issuance activities and histories, etc.; any access rights
> > to physical space such as offices, data cente

Criticism of GMO GlobalSign Re: Google Trust Services roots

[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 warrants public discussion. In previous comments I've made, I've expressed disapproval at the fact that there is no mention of the transfer on GlobalSign's website. I did not find it under News‎ and Events nor under the SSL sales pages nor under the Resources page. I also could find no information about the existence of different roots that GlobalSign has and their intended use cases.The search result that Ryan H. mentions below is in fact a curious situation. A direct link to the CPS is listed, sure, but if you go to the ".../resources" page directly there is no mention of the CPS. I would assume that at some point a subscriber is required to accept the terms of the CPS and is then presented with an opportunity to obtain the actu‎al document, but what about the relying parties? Are relying parties allowed to obtain the document but only if they use a search engine to find it? Are we to expect that search engines will always and only return the correct version for the specific root in which I'm interested?To be fair, I don't know that any of this constitutes a violation of any BR requirement or Mozilla policy--I assume not.‎ I also assume that GlobalSign is not the only offender in this regard. Still, I expect better than this from any root CA participant; surely a CA can give me something rather than leave me with nothing?All that said, it is not even what causes me the most concern, which is the intermingling of the GlobalSign and ‎Google brands. Like it or not, there will always be questions like "Is this GlobalSign or is this Google?" and this creates a risk not only to GlobalSign but also the Internet community. (There is a risk to Google as well but I'll address that in a separate thread.)The risk is a result of the confusion and uncertainty that are introduced by the transfer of these 2 roots.‎ Consider that right now I could launch a phishing campaign targeting GlobalSign subscribers with a message along the lines of "Did you know that GlobalSign has sold your certificate to Google? Click here to learn what you can do to protect your website." Should the person click on a link I might put the person on a fake login screen or a malware distribution point or engage in any other nefarious act of my choosing. For that matter I might try to sell the person my own certificate service: "Leave GlobalSign and Google behind! Protect the privacy of your website visitors and buy my service instead!"The point here is that accuracy in my message is not needed. Instead, I can exploit the confusion and uncertainty (or, if you prefer, FUD) which can lead to damage to GlobalSign's reputation and possible loss of business. Conceivably this can also impact the global PKI if I'm able to gain unauthorized access to a subscriber's account and have certificates issued for my nefarious websites.All of this to say that it actually is important that GlobalSign put messaging on their website and generally be proactive in limiting the chances for misinformation, confusion, and so forth to propagate across the Internet. The last thing I'll mention is that I have questions as to whether GlobalSign has violated either their own CPS or privacy policy when it comes to their subscribers‎. Admittedly I haven't had a chance to review either document so it's quite possible I'm misinformed and I hope someone will correct me as appropriate.But the basic reasoning goes that there are some people who don't like Google and perhaps have chosen to use GlobalSign because they are not Google. Personally I think GlobalSign has an obligation to notify their subscribers with something to the effect that "after a certain date we will be sharing your payment information, certificate history, domain ownership, login activity to our Web portal, etc. with Google." However, if there are statements in either the doc that have been violated, that is a more serious issue.The exact information being shared with (or is now available to) Google has not been publicly disclosed so I couldn't say for sure what should be communicated. Still, I imagine there are subscribers who would be surprised to learn that information they thought was constrained to just GlobalSign is no longer so. ‎I think it's only fair that subscribers (and relying parties) be offered a chance to opt-out even if it means subscribers leaving GlobalSign for some other vendor. I don't know that such an offering has been made?‎I do hope that more can be publicly disclosed about what information is shared between GlobalSign and Google--including if the data sharing is related to only the 2 roots that were acquired or all GlobalSign roots. 

Re: Google Trust Services roots

[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 the matter is 
considered resolved.

Several of the comments I made regarding GlobalSign also apply to Google, 
especially the intermingling of the two brands. The implications of the 
confusion and uncertainty leading to an exploitable attack are just as 
applicable to Google as they are to GlobalSign. However, when you consider the 
stature of Google both on the Internet and in consumer products, the 
ramifications are more significant. Or, if you will, the attack surface is 
quite different than if GlobalSign were to purchase a root from, say, Symantec.

I do fault Google for what I consider to be inadequate communication of the 
acquisition. This is not to say there's been no communication, just that I 
don't think it's enough, especially if you are not a CABF participant or don't 
keep up with Internet security news generally. Why not publish a message last 
October that regular folks on the Internet can understand? Why wait 3 months?‎ 
Why expect people to dig through a CPS to find what should be readily available 
information? 

I would be interested in knowing why Google felt it necessary to purchase an 
existing root instead of, for example, pursuing a "new root" path along the 
lines of what Let's Encrypt did? All I could gather from the Google security 
blog is that they really want to be a root CA and to do it in a hurry. ‎Why the 
need to do it quickly, especially given the risks (attack surface)?

I also would like to know what the plan or expectation is regarding formal 
separation between the infrastructures of Google and GlobalSign. The overlap is 
an understandable necessity during the transition but nonetheless presents 
another opportunity for improper access, loss (leaking) of data, and perhaps 
other nefarious activities. And, does Google have a published policy regarding 
the information collected, stored, and analyzed when people access the CRL and 
OCSP distribution nodes?

I do want to say I appreciate that someone with Ryan H.'s level of experience 
is involved in a transaction like this. There are undoubtedly many details to 
address that ensure a secure and proper transfer. I hope that someone on the 
GlobalSign side was equally experienced? The next time someone wants to 
purchase existing roots, the people involved might not have that same level of 
experience, and that should give everyone pause.


  Original Message  
From: Ryan Hurst via dev-security-policy
Sent: Wednesday, March 8, 2017 12:02 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Ryan Hurst
Subject: Re: Google Trust Services roots

> Jakob: An open question is how revocation and OCSP status for the 
> existing intermediaries issued by the acquired roots is handled. 

Google is responsible for producing CRLs for from these roots. We are also 
currently
relying on the OCSP responder infrastructure of GlobalSign for this root but are
In the process of migrating that inhouse.

> Jakob: Does GTS sign regularly updated CRLs published at the (GlobalSign) 
> URLs 
> listed in the CRL URL extensions in the GlobalSign operated non-expired 
> intermediaries? 

At this time Google produces CRLs and works with GlobalSign to publish those 
CRLs.

> Jakob: Hopefully these things are answered somewhere in the GTS CP/CPS for 
> the 
> acquired roots. 

This level of detail is not typically included in a CPS, for example, a service 
may change 
Which internet service provider or CDN service they use and not need update 
their CP/CPS.


> Jakob: Any relying party seeing the existing root in a chain would see the 
> name GlobalSign in the Issuer DN and naturally look to GlobalSign's 
> website and CP/CPS for additional information in trying to decide if 
> the chain should be trusted. 

The GlobalSign CPS indicates that the R2 and R4 are no longer under their 
control.

Additionally given the long term nature of CA keys, it is common for the DN not 
to accurately 
represent the organization that controls it. As I mentioned in an earlier 
response in the 90’s I 
created roots for a company called Valicert that has changed hands several 
times, additionally
Verisign, now Symantec in this context has a long history of acquiring CAs and 
as such they 
have CA certificates with many different names within them.

> Jakob: A relying party might assume, without detailed checks, that these 
> roots 
> are operated exclusively by GlobalSign in accordance with GlobalSign's 
> good reputation. 

As the former CTO of GlobalSign I love hearing about their good reputation ;)

However I would say the CP/CPS is the authoritative document here and since
GMO GlobalSign CP/CPS clearly states the keys are no longer in their control I 
believe thi

Criticism of Google Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

  (Renaming the thread to fork this particular discussion from any others on this transaction.)You raise a fair point, Ryan‎: I'm not well versed in how Let's Encrypt went about establishing their roots. I thought I had a good understanding but perhaps I had missed something. When I went to the Let's Encrypt site I found a diagram that showed one of their intermediates as cross-signed by IdenTrust; no mention of a root acquisition. Again, perhaps I've missed something so please let me know if that's the case. In a ironic way, this very uncertainty demonstrates the kind of confusion I was trying to highlight with my is-it-Google-or-GlobalSign comments.I think Kurt and I are on the same page regarding the precedent being established in this and prior acquisitions. In fact, I probably incorporated some of his points in my own commentary.‎ I'm not sure if he'll agree with the what I view as the danger here: By purchasing a single root certificate, Google (and anyone else) is redefining the very concept of "trust anchor".Back in the early SSL days, one could look at the root cert, see the name on it, and decide right away if it's trustworthy ("oh yeah, I know VeriSign"). In other words, trust was contained entirely within the sequence of bytes that make up the root cert combined with one's own experience.A significant change to that model happened when CA companies began to be purchased by other companies. However, since they were complete acquisitions, it isn't so hard‎ to add that one tidbit of knowledge to the thought process ("oh yeah, Symantec and VeriSign are the same"). So during this period of time trust was contained within the root certificate itself in conjunction with one's own experience and knowledge of CA company acquisitions.As more roots entered the scene, it became more frequent for one to encounter a root CA company that was unfamiliar. However, one could decide to ignore it because it was in another jurisdiction (country, government institution, etc.) that was not pertinent. Or one could, in fairly short order, do some Internet research on the CA company and make a decision--including possibly reading their CP/CPS. So, in essence, the anchor of trust is contained within the root cert combined with one's own knowledge, experience, and some research.Now, however, we are faced with a entirely different situation wherein the root certificate itself contributes little to establishing trust for a certificate chain. Any information contained in the cert is merely a starting point to research that particular cert: one must first determine who currently owns that root, possibly research the CA company if it's unfamiliar ("I know Google but what is this GTS all about?"), and probably ‎find and read the CP/CPS to find the details about the new ownership ("so who is handling revocation now?").The kicker in all this is that one must perform these steps for every root one encounters, every time one encounters ‎it: Did GlobalSign sell any other roots since the last time I checked? Has Google transferred ownership of the GlobalSign roots they purchased on to someone else? What about this Amazon root or Comodo or...?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 a forensic context) in the first place. I hardly think this redefinition of trust anchor improves the state of the global PKI and I sincerely hope it does not become a trend.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, 2017 at 8:37 AM, Peter Kurrasch via dev-security-policy <> dev-security-policy@lists.mozilla.org> wrote:>>> ‎I would be interested in knowing why Google felt it necessary to purchase>> an existing root instead of, for example, pursuing a "new root" path along>> the lines of what Let's Encrypt did? All I could gather from the Google>> security blog is that they really want to be a root CA and to do it in a>> hurry. ‎Why the need to d

Re: Criticism of Google Re: Google Trust Services roots

[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 of it appears in the browser UI. 
The only way you can actually establish trust is to do frequent, possibly 
complicated research." It doesn't seem right that Google be allowed to 
unilaterally impose that change on the global PKI without any discussion from 
the security community.

But you bring up a good point that there seems to be much interest of late to 
speed up the cycle times for various activities within the global PKI but it's 
not entirely clear to me what's driving it. My impression is that Google was 
keen to become a CA in their own right as quickly as possible, so is this 
interest based on what Google wants? Or is there a Mozilla mandate that I 
haven't seen (or someone else's mandate?)?


  Original Message  
From: Gervase Markham via dev-security-policy
Sent: Wednesday, March 29, 2017 9:48 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase 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 a forensic context) in the first place. I
> hardly think this redefinition of trust anchor improves the state of the
> global PKI and I sincerely hope it does not become a trend.

The trouble is, you want to optimise the system for people who make
individual personal trust decisions about individual roots. We would
like to optimise it for ubiquitous minimum-DV encryption, which requires
mechanisms permitting new market entrants on a timescale less than 5+ years.

Gerv
___
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: Criticism of Google Re: Google Trust Services roots

[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 this practice going 
forward.

Has Mozilla received any notification that other companies ‎intend to acquire 
individual roots from another CA? I wouldn't ask Mozilla to violate any 
non-disclosures but surely it's possible to let the community know if we should 
expect more of this? Ryan H. implied as much in a previous post but I wasn't 
sure where he was coming from on that.

Also, does Mozilla have any policies (requirements?) regarding individual root 
acquisition? For example, how frequently should roots be allowed to change 
hands? What would Mozilla's response be if WoSign were to say that because of 
the tarnishing of their own brand they are acquiring the HARICA root? What if 
Vladimir Putin were to make such a purchase? Any requirements on companies 
notifying the public when the acquisition takes place?

Perhaps this is putting too much of a burden on Mozilla as a somewhat protector 
of the global PKI but I'm not sure who else is in a better position for that 
role?


  Original Message  
From: Gervase Markham via dev-security-policy
Sent: Thursday, March 30, 2017 1:06 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: 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 actually establish
> trust is to do frequent, possibly complicated research." It doesn't
> seem right that Google be allowed to unilaterally impose that change
> on the global PKI without any discussion from the security
> community.

As others in this thread have pointed out, this is not a new thing. I
wouldn't say that Google is "imposing" this need.

Gerv
___
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: Criticism of Google Re: Google Trust Services roots

[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 trying 
to purchase the root must be fully admitted into the root program before the 
transfer takes place?

Also, let me state that I did not intend to besmirch the names of either HARICA 
or WoSign and I appreciate their indulging my use of their names in what turned 
out to be a sloppy illustration. Based on my review of HARICA's CPS some months 
ago, I was left with the impression of them as a tightly-focused ‎organization 
that, by all appearances, is well-run. And that was the image I had mind and 
had hoped to convey in using their name. By mentioning WoSign I was really 
thinking of only the state of their reputation at the moment--and I think it's 
fair to say it's been tarnished? The reasons for WoSign being in the position 
they are in were totally irrelevant to what I had in mind.

So what was my point? In essence, I wanted to suggest that not every company 
seeking to purchase a root from another company will necessarily have good 
intentions and even if they do, their intentions might not be in the interest 
of the public good. I think it's important to at least acknowledge that 
possibility and try to have policies in place that encourage the good and limit 
the bad.

I don't know if people are on board with this notion or if some hypothetical 
scenarios are needed at this point? For now I'll just pause and let others 
either ask or comment away.


  Original Message  
From: Gervase Markham via dev-security-policy
Sent: Friday, March 31, 2017 12:28 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots

On 31/03/17 17:39, Peter Bowen wrote:
>>> For example, how frequently should roots
>>> be allowed to change hands? What would Mozilla's response be if
>>> GalaxyTrust (an operator not in the program)
>>> were to say that they are acquiring the HARICA root?
>>
>> From the above URL: "In addition, if the receiving company is new to the
>> Mozilla root program, there must also be a public discussion regarding
>> their admittance to the root program."
>>
>> Without completing the necessary steps, GalaxyTrust would not be admitted to
>> the root program.
> 
> I've modified the quoted text a little to try to make this example
> clearer, as I think the prior example conflated multiple things and
> used language that did not help clarify the situation.
> 
> Is the revised example accurate?

The revised example is accurate.

Gerv

___
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: Criticism of Google Re: Google Trust Services roots

[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 subordinates without 
having first demonstrated any competence at ‎running a CA organization.

I think we need to beef up this section of the policy but if you'd prefer to 
discuss that at a later time (separate from the Google acquisition thread), 
that will work for me.


  Original Message  
From: 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 (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 trying to purchase the root must be
> fully admitted into the root program before the transfer takes
> place?

No. As currently worded, it has to take place before issuance is permitted.

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

Re: Criticism of Google Re: Google Trust Services roots

[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 damage those bad behaviors might cause. It's in this latter category that I think the current policy falls short.Consider a situation in which I have a business called Easy Pete's Finishing School for Nigerian Princes. As the name might suggest, the nature of my business is to train potential scammer after potential scammer and set them free on the Internet to conduct whatever naughty things they like. It's a very lucrative business so when I see a root cert coming up for sale it's a no-brainer for me to go out and purchase it. Having access to a root will undoubtedly come in handy as I grow my business.Once I take possession of the root cert's private key and related assets, what will limit the bad actions that I intend to take? For the sake of appearances (to look like a good-guy CA) I'll apply to join the Mozilla root program but I'm only really going through the motions--even in a year's time I don't really expect to be any closer to completing the necessary steps to become an actual member.And it's true that I may be prohibited from issuing certs per Mozilla policy, but that actually is a bit of a squishy statement. For example, I'll still need to reissue certs to the existing customers ‎as their certs expire or if they need rekeying. Perhaps I'll also get those clients to provide me with their private key so I may hold it for "safe keeping". Sure, it's a violation of the BR's but I'm not concerned with that. Besides, it will take some time until anyone even figures out what I'm doing.The other recourse in the current policy is to distrust the root cert altogether. Even then it will take time to take full effect and who knows, maybe I can still use the root for code signing? And then there are the existing customers who are left holding a soon-to-be worthless certLeaving behind this land of hypotheticals‎, it seems to me the policy as written is weaker than it ought to be. My own opinion is that only a member CA should be allowed to purchase a root cert (and assets), regardless if it's only one cert or the whole company. If that's going too far, I think details are needed for what "regular business operations" are allowed during the period between acquisition of the root and acceptance into the Mozilla root program. And should there be a maximum time allowed to become such a member?From: Nick Lamb via dev-security-policySent: Tuesday, April 4, 2017 3:42 AMTo: mozilla-dev-security-pol...@lists.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 possession of the root cert private key and possibly the physical space, key personnel, networking infrastructure, revocation systems, and responsibility for subordinates without having first demonstrated any competence at ‎running a CA organization.This appears to me to simply be a fact, not a policy.Suppose Honest Achmed's used car business has got him into serious debt. Facing bankruptcy, Achmed is ordered by a court to immediately sell the CA to another company Rich & Dick LLC, which has never historically operated a CA but has made informal offers previously.Now, Mozilla could say, OK, if that happens we'll immediately distrust the root. But to what end? This massively inconveniences everybody, there's no upside except that in the hypothetical scenario where Rick & Dick are bad guys the end users are protected (eventually, as distrust trickles out into the wild) from bad issuances they might make. But a single such issuance would trigger that distrust already under the policy as written and we have no reason to suppose they're bad guys.On the other hand, if Rich & Dick are actually an honest outfit, the policy as written lets them talk to Mozilla, make representations to m.d.s.policy and get themselves trusted, leaving the existing Honest Achmed subscribers with working certificates while everything is straightened out, all Rich & Dick need to do is leave issuance switched off while they reach an agr

Re: Criticism of Google Re: Google Trust Services roots

[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 overlap, yes, but the general idea is to be more prescriptive in ownership than the current policy states.Is there room to expand Mozilla policy in regards to ownership issues?From: Gervase Markham via dev-security-policySent: Friday, April 7, 2017 4:50 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Gervase MarkhamSubject: Re: Criticism of Google Re: Google Trust Services rootsOn 06/04/17 18:42, Jakob Bohm wrote:> Here are some ideas for reasonable new/enhanced policies (rough> sketches to be discussed and honed before insertion into a future> Mozilla policy version):I'm not sure what's new or enhanced about them. Our current policies arenot this prescriptive so CAs have more flexibility in how they go aboutthings, but I believe they preserve the same security invariants.In general, I suggest that if others have policy problems they see, youlet them draft the solutions? :-)‎Gerv___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Criticism of Google Re: Google Trust Services roots

[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 public attestation must be given as to the intended management of the root upon completion of the transfer. "Intention" must be one of the following:A) The purchaser has been in compliance with Mozilla policies for more than 12 months and will continue to administer (operate? manage?) the root in accordance with those policies.B) The purchaser has not been in compliance with Mozilla policies for more than 12 months but will ‎do so before the transfer takes place. The purchaser will then continue to administer/operate/manage the root in accordance with Mozilla policies.C) The purchaser does not intend to operate the root in accordance with Mozilla policies. Mozilla should remove trust from the root upon completion of the transfer.The wording of the above needs some polish and perhaps clarification. The idea is that the purchaser must be able to demonstrate some level of competence at running a CA--perhaps by first cutting their teeth as a sub-CA? If a organization is "on probation" with Mozilla, I don't think it makes sense to let them assume more control or responsibility for cert issuance so there should be a mechanism to limit that.I also think we should allow for the possibility that someone may legitimately want to remove a cert from the Mozilla program. Given the disruption that such a move can cause, it is much better to learn that up front so that appropriate plans can be made.From: Gervase Markham via dev-security-policySent: Tuesday, April 11, 2017 11:36 AMTo: mozilla-dev-security-pol...@lists.mozilla.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 lot of right now, given that this is not myonly job) there's always room to reconsider policy. But what we need isa clearly-stated and compelling case that changing the way we thinkabout these things would have significant and realisable benefits, andthat any downsides are fairly enumerated and balanced against those gains.Gerv___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Criticism of Google Re: Google Trust Services roots

[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 staff, then I think it's reasonable ‎to make that accommodation.Using a word like "all" could be going too far but at the moment I'm not sure how to strike a softer tone and still have something that is precise and enforceable.From: Jakob Bohm via dev-security-policySent: Monday, April 24, 2017 8:42 PM‎On 25/04/2017 03:10, Peter Kurrasch wrote:> 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 public attestation must be given as to the intended> management of the root upon completion of the transfer. "Intention" must> be one of the following:>> A) The purchaser has been in compliance with Mozilla policies for more> than 12 months and will continue to administer (operate? manage?) the> root in accordance with those policies.>> B) The purchaser has not been in compliance with Mozilla policies for> more than 12 months but will ‎do so before the transfer takes place. The> purchaser will then continue to administer/operate/manage the root in> accordance with Mozilla policies.>How about:B2) The purchaser is not part of the Mozilla root program and has notbeen so in the recent past, but intends to continue the programmembership held by the seller.  The purchaser intends to completeapproval negotiations with the Mozilla root program before the transfertakes place.  The purchaser intends to retain most of the expertise, personnel, equipment etc. involved in the operation of the CA, as willbe detailed during such negotiations.This, or some other wording, would be for a complete purchase of thebusiness rather than a merge into an existing CA, similar to whathappened when Symantec purchased Verisign's original CA business yearsago, or (on a much smaller scale) when Nets purchased the TDC's CAbusiness unit and renamed it as DanID.> C) The purchaser does not intend to operate the root in accordance with> Mozilla policies. Mozilla should remove trust from the root upon> completion of the transfer.‎
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 clear way to extrapolate a successful validation for one domain into a plethora of FQDN's in a way that works for all scenarios. So the risk in this sense is that the issuer might allow a cert requester to over-subscribe a given domain's name space.2) Abuse: Once the wildcard cert has been issued there is no way to check that the host (or FQDN) to which I'm connecting is a legitimate part of the broader domain or if it has been taken over for nefarious purposes. This is in contrast to the non-wildcard case wherein I know it's a legitimate part because I see the FQDN listed explicitly in the SAN field. So the risk in this sense is to the relying party who is less able to protect himself or herself from connecting to bad servers.The use of "problematic" to describe wildcard certs is perhaps misleading. Perhaps the wildcard‎ certs themselves are not problematic but trying to manage or mitigate the risk they pose is. Either way, I don't think it would be wise to remove this from the problematic practices list.  ‎  From: Gervase Markham via dev-security-policySent: Monday, April 24, 2017 4:16 AM‎On 21/04/17 12:09, Nick Lamb wrote:> Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate> for verifying that the applicant controls the entire domain and thus> *.example.com, whereas say 3.2.2.4.6 proves only that the applicant> controls a web server, it seems quite likely they have neither the> legal authority nor the practical ability to control servers with> other names in that domain. I can see arguments either way for> 3.2.2.4.4, depending on how well email happens to be administrated in> a particular organisation.So your concern is that a subset of the 10 Blessed Methods might not besuitable for verifying the level of control necessary to safely issue awildcard cert?If that's true, we should look at it, but I don't see how that'sconnected with saying or not saying on our wiki page that wildcard certsare inherently problematic.So, to analyse: you are saying that demonstrating control overhttp://www.example.com/ and getting a cert for *.www.example.com isshaky? Or demonstrating control of http://example.com/ and getting acert for *.example.com? Or something else?Gerv___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Criticism of Google Re: Google Trust Services roots

[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 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 Kurrasch wrote:
> Fair enough. I propose the following for consideration:

As it happens, I have been working on encoding:
https://wiki.mozilla.org/CA:RootTransferPolicy
into our policy. A sneak preview first draft is here:

https://github.com/mozilla/pkipolicy/compare/issue-57

Would you be kind enough to review that and see if it addresses your
points and, if not, suggest how it might change and why?

I can see the value of a "definition of intention" and the choosing of a
category, as long as we are careful to make sure the categories do not
preclude operations that we would like to see occur. As Ryan Hurst
notes, there is potentially significant value to the ecosystem in root
transfers.

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

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

[Peter Kurrasch via dev-security-policy]

  Hi Ryan--To your first comment, I'm afraid I won't have the time to take a closer look at the discussion on 3.2.2.4. Hopefully a path from single domain to unlimited domains exists (or will). It makes sense to me (without fully considering the consequences) that a "special" validation path be used for wildcards. Perhaps it could be part of an existing validation method, I'm not sure. Bottom line though, I don't think it makes sense that anyone and everyone be allowed to obtain a wildcard cert.As for the subdomain stuff, I was hoping to avoid providing some examples because I couldn't come up with a simple one. However, I think it's necessary so let's try this out:Let's suppose we break up everyone with a server on the Internet into 3 categories based on the size of their Internet presence: substantial, intermediate, and tiny. A "substantial" presence almost certainly has a large enterprise behind it with staff and capital resources to maintain the service. If we can assume that such organizations have tighter controls over use of the domain name space, servers, certificates, and so forth, then I think some of the risks posed by wildcard certs are reduced. That being the case, I'm less concerned about this category.For an "intermediate" presence, I'm thinking of places like universities that have a large number of subdomains in use but might not have a good set of controls over use of the domain name space and certificates and so forth. In this type of setting I think the use of wildcards might be appealing because it simplifies management of the network but if the controls are not in place, there remains a certain level of risk that these certs pose. (And to be fair, this isn't to say that only academic environments face this situation or that all academic environments are not suitably managed.) This category can be of concern.The "tiny" category almost speaks for itself and probably applies to all individuals and small businesses--people who want some presence but might not be all that diligent about it. In other words, these are the systems that probably have the weakest security measures in place. These are the systems that are regularly compromised and used for spam campaigns, fake login screens, and such. This is also the category for whom wildcard certs pose the greatest risk‎ to everyone else.Consider a case where someone has a custom domain--let's say easypete.ninja--and perfectly reasonable subdomains. So: - easypete.ninja  ‎- www.easypete.ninja - email.easypete.ninjaClearly there is a slight advantage for a wildcard cert in this case--it's easier than listing those subdomains. However, a wildcard cert opens up the possibility for other things like: - com.easypete.ninja - paypal.com.easypete.ninja - google.com.easypete.ninja - .easypete.ninja - facebook.com.loginassistant.easypete.ninja...and all sorts of variants of the above.‎ Per the wildcard cert, all of the above domains are perfectly valid. Per the actual intent of th‎e domain holder, most of the above are surely not valid.So, the problem becomes how a relying party may determine if the site/domain is legitimate. If I have some indicator in the browser UI that says "secure" because the FQDN matching has been satisfied, I'll probably proceed to use the page that is presented. If the indicator is missing, there is a chance I'll think twice about proceeding any further. The trouble in this situation is that if the FQDN is nefarious but satisfies the wildcard contained in the cert, I will probably make the wrong decision and open myself up to who knows what.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, 2017 at 1:31 AM, Peter Kurrasch via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:  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 clear way to extrapol

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

[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 "system administrator" if you will. The ability of individual people to navigate the minefield of security practices and exploits is at least as important as the relative size of the Internet presence a given domain may have. There should also be some mention of attack vectors as they are an important consideration in evaluating the relative disadvantages of wildcard certs. (I think the advantages are widely understood and not disputed, so I'll skip that side of the debate.)I'll talk about an attack vector first:Suppose I want to set up a system to be used for spam, malware distribution, and phishing but, naturally, I want to operate undetected. First step is to find a (legitimate) server that is already set up and is not well secured. Without getting bogged down in the details, let's just assume I can find such a server and I'm able to obtain access to the admin panel or a command line/shell that controls it. With this access, let's also just assume I'm able to obtain the certificate and private key data that the legitimate site owner is using.If the cert is not a wildcard, my options are limited. I could use the server and its domain name to send out my spam. In practice, though, it's probably easier to just commandeer the domain name and find some spam-as-a-service provider in the underground market. I could probably copy my malware objects into some obscurely-named directory and serve them up to my victims from there. The benefit is that I don't need my own hardware somewhere else and worry about DNS settings but there is a much higher risk that someone will eventually figure out what I'm doing. Someone could be monitoring network bandwidth or server logs or the file system capacity or some other data point that prompts a closer look.If, instead, the cert is a wildcard, I have more freedom to ‎do what I want while reducing the chances of getting caught. I can exploit the domain and it's cert without tying myself to the server that is handling the legitimate traffic. I do need to manipulate DNS lookups in the right manner, but let's again just assume I can do that just fine. With DNS pointing my nefarious subdomains to my own nefarious server and with a wildcard cert and private key ready to validate with whatever names I choose, I am ready to go. I can send spam, offer up a variety of malware and ransomware, and host the phishing sites/pages all while keeping a very low profile--at least as far as the legitimate site owner is aware.Granted, there is a healthy amount of hand waving in this illustration and frankly there are situations where other attack methods are more advantageous for any number of reasons. That said, the point I am hoping to make is that a wildcard certificate opens up possibilities for me as the bad guy that I might not have otherwise.With that I'll (briefly) address the role of the system administrator's skill level:In order for my wildcard attack to work, I need to find the server. Perhaps I'll skulk around the Internet looking for servers with unpatched vulnerabilities. Perhaps then I'll look up ownership information on that domain and cross-reference that with lists of accounts/passwords that have been compromised. Since it's common for people to use the same password on multiple sites I might get lucky.From there, I'm mostly in the free and clear. In some situations I might want to tweak the DNS settings in the legit name servers so perhaps I will have direct access to it once I pop the server. Maybe the control panel also can modify the DNS records or maybe the same password will work on the name servers?The point here is that there are important security measures that a system administrator must take. I think we can all agree that a competent administrator will take those steps while a lesser administrator might not. When this lack of skill (or perhaps "diligence" is a better word?) are combined with wildcard certs, the consequences can be very bad for everyone else.Again, I'll be the first to admit this is perhaps not the best illustration of the risks posed by wildcard certs but hopefully it's at least good enough. I don't think the above is a major problem today but if the desire is make wildcard certs ubiquitous (?), I hope people will at least think twice.And, for the record, I don't think wildcard certs should be banned outright. I also think that Hans and his network situation represent a good example where actual need and skill of the administrator combine to give one confidence that the wildcard cert's risks are controlled, and perhaps minimized.And, finally, I'll just say CAA sounds like a good addition to the security toolbox but does have some shortcomings. The extent to w

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

[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 an encrypted channel. If I'm doing other bad things, encryption frustrates the efforts of security personnel to figure out that something bad is happening.As for the weak link, it isn't necessarily weak. True, I could get additional subdomain certs by exploiting the weak validation methods that CABF has endorsed. In many cases that will work just fine but I do still have to interact with the CA which leaves a paper trail--especially if the cert gets published via CT.In the wildcard scenario, there is no need for that interaction. Less interaction, low profile, few opportunities for detection, ability to operate unimpeded...this is the dream for any bad guy. Wildcard certs make it easier for me to get there. One can definitely reach that goal using non-wildcard tactics but it might not be as easy.Getting back to Gerv's original question, should the wildcard section be removed? My answer is: no, it should not be removed. It could stand to be updated though.   From: Ryan SleeviSent: Friday, April 28, 2017 9:51 AM‎On Fri, Apr 28, 2017 at 9:48 AM, Peter Kurrasch  wrote:Suppose I want to set up a system to be used for spam, malware distribution, and phishing but, naturally, I want to operate undetected. First step is to find a (legitimate) server that is already set up and is not well secured. Without getting bogged down in the details, let's just assume I can find such a server and I'm able to obtain access to the admin panel or a command line/shell that controls it. With this access, let's also just assume I'm able to obtain the certificate and private key data that the legitimate site owner is using.You can stop here. Once you've done that, it's game over for any subdomains as it stands. Wildcard certs are a red herring. If you've got file control on the server, or can demonstrate control of the base, you can get the subdomains.That's the weak link in your attack model, and for that to change, it will at least require some action on the CA/Browser Forum to restrict the file-based controls or 'practical demonstration of control'. If you just compromise the server/key, you've compromise every subdomain, as it stands today. That's not because of wildcards. That's because of the CA/Browser Forum. Granted, there is a healthy amount of hand waving in this illustration and frankly there are situations where other attack methods are more advantageous for any number of reasons. That said, the point I am hoping to make is that a wildcard certificate opens up possibilities for me as the bad guy that I might not have otherwise.Right, not really, because above :) Again, I'll be the first to admit this is perhaps not the best illustration of the risks posed by wildcard certs but hopefully it's at least good enough. I don't think the above is a major problem today but if the desire is make wildcard certs ubiquitous (?), I hope people will at least think twice.I appreciate your threat modelling of this space, but I think it's operating on incomplete understanding of what the reasonable security boundary is, but also tries to rely on certificates as a spam/phishing protection, of which they most certainly are not :)

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

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

[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: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

On 20/04/17 14:39, Gervase Markham wrote:
> So I propose removing it, and reformatting the section accordingly.

Edit made as proposed.

Gerv

___
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: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

[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 PKI itself is an important tool to fighting fraud on the Internet, it seems to me like it would be a missed opportunity if the policy doc made no mention of fraud.Some fraud scenarios that come to mind:- false representation as a requestor- payment for cert services using a stolen credit card number- malfeasance on the part of the cert issuer- requesting and obtaining certs for the furtherance of fraudulent activityRegarding that last item, I understand there is much controversy over the prevention and remediation of that behavior but I would hope there is widespread agreement that it does at least exist.From: Gervase MarkhamSent: Monday, May 1, 2017 10: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 PKI?What do you mean by "in"?Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Incorporate Root Transfer Policy

[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, whenever an organization notifies Mozilla about changes in ownership or operation, the organization must notify the public about any such changes? The idea here is transparency, and making sure that all parties (subscribers and relying parties alike) are made aware of the changes in case they wish to make changes of their own.For whatever it's worth, I gave the Personnel Changes section a bit of thought and wondered if further articulation of "changes" might be helpful. The example that came to mind is GTS and GlobalSign--specifically, that Google would continue to use GlobalSign's infrastructure until a transition is made in the future. Presumably, a change in personnel will take place when Google switches to its own infrastructure, so should Mozilla be notified at that time? As written, I think the answer could be yes, but is that necessarily what you want?(And, for the record, I'm not trying to rehash any past discussion of the acquisition. Rather, I thought it might be a good real-world example based on my understanding of events. If my facts are wrong, that hopefully will not nullify its value as a hypothetical example.)If you prefer to leave the personnel section as-is, I have no issue with that.From: Gervase Markham via dev-security-policySent: Monday, May 1, 2017 4:02 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Gervase MarkhamSubject: Policy 2.5 Proposal: Incorporate Root Transfer PolicyMozilla has a Root Transfer Policy which sets out our expectationsregarding how roots are transferred between organizations, or whathappens when one company buys another, based on a recognition that trustis not always transferable.https://wiki.mozilla.org/CA:RootTransferPolicyIt has been reasonably observed that it would be better if this policywere part of our official policy rather than a separate wiki page.So, I have attempted to take that wiki page, remove duplication and boilit down into a set of requirements to add to the existing policy.Here is a diff of the proposed changes:https://github.com/mozilla/pkipolicy/compare/issue-57This is: https://github.com/mozilla/pkipolicy/issues/57---This is a proposed update to Mozilla's root store policy for version2.5. Please keep discussion in this group rather than on Github. Silenceis consent.Policy 2.4.1 (current version):https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.mdUpdate process:https://wiki.mozilla.org/CA:CertPolicyUpdates___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

[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. Some examples:‎- Minimal expectation, meaning just satisfy whatever the BR's say but beyond that Mozilla won't care(?)- Passive involvement, meaning a CA is expected to do some investigation into fraudulent activity but only when prompted and even then, no action is necessarily expected- Active involvement, meaning the CA has implemented policies and procedures that identify and act on situations that appear fraudulentA question one might ask is "What is reasonable?" It is not reasonable for CA's to identify and prevent all cases of fraud so I wouldn't ask that. I wouldn't call CA's the anti-fraud police, either. What about the following:- When a CA is notified that a stolen credit card was used to purchase certs, should the CA investigate the subscriber who used it and any other certs that were purchased (perhaps using a different CC) and take appropriate action?- Is it reasonable for any subscriber to request more than 100 certs on a given day? What about 500? 1000? (The point is not to prohibit large requests but I would imagine there is a level which exceeds what anyone might consider a legitimate use case.)- Is is reasonable for a single CA to issue over 150 certs containing "paypal" in the domain name? (I am referring to the analysis Vincent Lynch did back in March.) There are undoubtedly cases where including "paypal" in the name is or could be legitimate, but 150 a day, every day?- Is it reasonable for a CA to issue a cert to the CIA for Yandex or to the Chinese government for Facebook, even if the requester does demonstrate "sufficient control" of the domain?The point I wish to make is that situations will come up that go beyond anything in the BR's and that reasonable people might agree go ‎beyond a reasonable level of reasonableness. The question becomes what will Mozilla do as those situations arise? Can Mozilla envision possibly asking a CA "don't you think you should have limited ?"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 "fraudulent use"On 02/05/17 01:55, Peter Kurrasch wrote:> 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> PKI itself is an important tool to fighting fraud on the Internet, it> seems to me like it would be a missed opportunity if the policy doc made> no mention of fraud.> > Some fraud scenarios that come to mind:> > - false representation as a requestor> - payment for cert services using a stolen credit card number> - malfeasance on the part of the cert issuerClearly, we have rules for vetting (in particular, EV) which try andavoid such things happening. It's not like we are indifferent. Butstolen CC numbers, for example, are a factor for which each CA has toput in place whatever measures they feel appropriate, just as anybusiness does. It's not really our concern.> - requesting and obtaining certs for the furtherance of fraudulent activity> > Regarding that last item, I understand there is much controversy over> the prevention and remediation of that behavior but I would hope there> is widespread agreement that it does at least exist.It exists, in the same way that cars are used for bank robbery getaways,but the Highway Code doesn't mention bank robberies.Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 the security of their 
networks and systems, is that correct? If so, I think we should have something 
with more meat to it. If not, the proposal as written is probably just fine 
(although, do you mean the CABF's "Network Security Requirements" spec or is 
there another guidelines doc?).

For consideration: ‎Mozilla can--and perhaps should--require that all CA's 
adopt and document a cybersecurity risk management framework for their networks 
and systems (perhaps this is already mandated somewhere?). I would expect that 
the best run CA's will already have something like this in place (or something 
better) but other CA's might not. There are pros and cons to such frameworks 
but at a minimum it can demonstrate that a particular CA has at least 
considered the cybersecurity risks that are endemic to their business.


  Original Message  
From: Gervase Markham via dev-security-policy
Sent: Friday, May 19, 2017 7:56 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Policy 2.5 Proposal: Require all CAs to have appropriate network 
security

At the moment, the CAB Forum's Network Security guidelines are audited
as part of an SSL BR audit. This means that CAs or sub-CAs which only do
email don't technically have to meet them. However, they also have a
number of deficiencies, and the CAB Forum is looking at replacing them
with something better, ideally maintained by another organization. So
just mandating that everyone follow them doesn't seem like the best thing.

Nevertheless, I think it's valuable to make it clear in our policy that
all CAs are expected to follow best practices for network security. I
suggest this could be done by adding a bullet to section 2.1:

"CAs whose certificates are included in Mozilla's root program MUST:

* follow industry best practice for securing their networks, for example
by conforming to the CAB Forum Network Security Guidelines or a
successor document;"

This provides flexibility in exactly what is done, while making it
reasonably clear that leaving systems unpatched for 5 years would not be
acceptable.

This is: https://github.com/mozilla/pkipolicy/issues/70

---

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
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: Policy 2.5 Proposal: Require all CAs to have appropriate network security

[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 going through some sort of update/revisory process.  ‎http://www.nist.gov/cyberframework/- ISO has 27032:2012 which looks to have some good stuff in it.    ‎https://www.iso.org/standard/44375.html‎- Perhaps surprisingly enough, the American Institute of CPA's has a variety of information that looks to be a good starting point for anyone.  http://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/pages/cyber-security-resource-center.aspxI would be interested in knowing if other people know of other frameworks and have experience using any of them. I'm certainly not advocating that any of the above be used here or that they are necessarily even good resources for folks in the CA space.Back to laughable security, my issue is that there are many ways an organization might experience a security breakdown in ways that cause severe face damage to security folks due to either excessive face palms or banging ones head against the wall or even laughing too hard. Examples include: ‎allowing week passwords (by employees), poor password management, inadequate access controls, weak network intrusion detection, insufficient protection from well-known web application vulnerabilities (e.g. SQL injection), and the list goes on.If you'd like to keep the policy to a sentence or so, perhaps we could use some "including but not limited to" verbiage? 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 appropriate network securityOn 23/05/17 04:18, Peter Kurrasch wrote:> 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'm not sure that "patching half my systems" would be generally acceptedas "industry best practice". But regardless, unless we are planning towrite our own network security document, which we aren't, can yousuggest more robust wording?> I assume the desire is to hold CA's to account for the security of> their networks and systems, is that correct? If so, I think we should> have something with more meat to it. If not, the proposal as written> is probably just fine (although, do you mean the CABF's "Network> Security Requirements" spec or is there another guidelines doc?).Yes, that's the doc I mean (for all its flaws).> For consideration: ‎Mozilla can--and perhaps should--require that all> CA's adopt and document a cybersecurity risk management framework for> their networks and systems (perhaps this is already mandated> somewhere?). I would expect that the best run CA's will already have> something like this in place (or something better) but other CA's> might not. There are pros and cons to such frameworks but at a> minimum it can demonstrate that a particular CA has at least> considered the cybersecurity risks that are endemic to their> business.If we are playing "too nebulous", I would point out that to meet thisrequirement, I could just write my own (very lax) cybersecurity riskmanagement framework and then adopt it.Any requirement which is only a few sentences is always going to betechnically gameable. I just want to write something which is not easilygameable without failing the "laugh test".Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 you just want the CA's to be reminded that cybersecurity issues are important despite the CABF docs on the matter being too weak?I have no qualms using "for example". I would like for more to be mentioned than just software updates but even there I don't feel too strongly about it.From: Gervase MarkhamSent: Wednesday, May 24, 2017 9:56 AMTo: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Policy 2.5 Proposal: Require all CAs to have appropriate network securityOn 24/05/17 15:31, Peter Kurrasch wrote:> 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:I think we would prefer to wait for the CAB Forum to adopt somethingrather than attempting to define and enforce our own. If for no otherreason than the CAB Forum thing is more likely to be audited andtherefore to have actual teeth.> If you'd like to keep the policy to a sentence or so, perhaps we could> use some "including but not limited to" verbiage? Well, the draft wording we started with used "for example"... :-)Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 use;- contains data that has been properly verified by the issuer, to the extent that the data is verifiable in the first place;- uses data that is recognized as legitimate for a certificate's intended use, per the relevant standards, specifications, recommendations, ‎and policies, as well as the software products that are likely to utilize the certificate;- is suitably constructed in accordance with the relevant standards, specifications, recommendations, and policies, as appropriate; and- is produced by equipment and systems whose integrity is assured by the issuer and verified by ‎the auditors.Thus, failing one or more of the above conditions will constitute a mis-issuance situation.From: Matthew Hardeman via dev-security-policySent: Thursday, June 1, 2017 1:35 PM‎On Thursday, June 1, 2017 at 8:03:33 AM UTC-5, Gervase Markham wrote:> > My point is not that we are entirely indifferent to such problems, but> that perhaps the category of "mis-issuance" is the wrong one for such> errors. I guess it depends what we mean by "mis-issuance" - which is the> entire point of this discussion!> > So, if mis-issuance means there is some sort of security problem, then> my original definition still seems like a good one to me. If> mis-issuance means any problem where the certificate is not as it should> be, then we need a wider definition.> It was in that spirit that I raised the questions that I did.‎ I wonder if the pedant can use these arguments to call any certificate "mis-issued" under the proposed definition.  If so, I wonder if we should care if such a tortured argument might be made.> I wonder whether we need a new word for certificates which are bogus for> a non-security-related reason. "Mis-constructed"?> ___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Symantec response to Google proposal

[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 obtain a satisfactory outcome without it.From: Gervase Markham via dev-security-policySent: Friday, June 2, 2017 9:54 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Gervase MarkhamSubject: Symantec response to Google proposalhttps://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposalSymantec have responded to the Google proposal (which Mozilla hasendorsed as the basis for further discussion) with a set of inlinecomments which raise some objections to what is proposed.Google will, no doubt, be evaluating these requests for change anddeciding to accept, or not, each of them. But Mozilla can make our ownindependent decisions on these points if we choose. If Google andMozilla accept a change, it is accepted. If Google accepts it but wedecline to accept, we can add it to our list of additional requirementsfor Symantec instead.Therefore, I would appreciate the community's careful consideration ofthe reasonableness of Symantec's requests for change to the proposal.Gerv___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: On remedies for CAs behaving badly

[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, figuring out how to impose, fairly, an explicit financial toll on bad CA's is likely to be as difficult as figuring out any of the other remedies ‎that are presently available. (For example, who gets to keep the money collected?)From: Matthew Hardeman via dev-security-policySent: Monday, June 5, 2017 10:52 AM‎Hi all,I thought it prudent in light of the recent response from Symantec regarding the Google Chrome proposal for remediation to raise the question of the possible remedies the community and the root programs have against a CA behaving badly (mis-issuances, etc.)Symantec makes a number of credible points in their responses.  It's hard to refute that the time frames required to stand up a third party managed CA environment at the scale that can handle Symantec's traffic could happen in reasonable time.In the end, it seems inevitable that everyone will agree that practical time frame to accomplish the plan laid out could take... maybe even a year.As soon as everyone buys into that, Symantec will no doubt come with the "Hmm.. By that time, we'll have the new roots in the browser stores, so how about we skip the third party and go straight to that?"Even if that's not the way it goes, this Symantec case is certainly a good example of cures (mistrust) being as bad as the disease (negligence, bad acting).Has there ever been an effort by the root programs to directly assess monetary penalties to the CAs -- never for inclusion -- but rather as part of a remediation program?Obviously there would be limits and caveats.  A shady commercial CA propped up by a clandestine government program such that the CA seems eager to pay out for gross misissuance -- even in amounts that exceed their anticipated revenue -- could not be allowed.I am curious however to know whether anyone has done any analysis on the introduction of economic sanctions in order to remain trusted -- combined with proper remediation -- as a mechanism for incentivizing compliance with the rules?Particularly in smaller organizations, it may be less necessary.  In larger (and especially publicly traded) companies, significant economic sanctions can get the attention and involvement of the highest levels of management in a way that few other things can.Thanks,Matt___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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

An alternate perspective on Symantec

[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 the impact would be catastrophic?I'd like to offer an alternate perspective on the situation in the hope that it might simplify the discussions of sanctions. The central point is this: Symantec is too big and too complicated to function properly.Consider:* Symantec has demonstrated an inability to exercise sufficient oversight and control over the totality of their PKI systems. Undoubtedly there are parts which have been and continue to be well-run, but there are parts for which management has been unacceptably poor.* No cases have been identified of a breach or other compromise of Symantec's PKI technology/infrastructure, nor of the infrastructure of a subordinate PKI organization for which Symantec is responsible. The possibility does exist, however, that compromises have occurred but might never be known because of management lapses.* Many of Symantec's customers play a critical role in the global economy and rely on the so-called "ubiquitous roots" to provide their services. Any disruption in those services can have global impacts. Symantec, therefore, plays a significant role in the global economy but only insofar as it is the gatekeeper to the "ubiquitous roots" upon which the global economy relies.* ‎Symantec has demonstrated admirable commitment to its customers but appear less so when it comes to the policies, recommendations, and openness of the global PKI community. Whether this indicates a willful disregard for the community‎ or difficulty in incorporating these viewpoints into a large organization (or something else?) is unclear.From this standpoint, the focus of sanctions would be on Symantec's size. Obviously Mozilla is in no position to mandate the breakup of a company but Mozilla (and others) can mandate a reduced role as gatekeeper to the "ubiquitous roots". In fact, Symantec has already agreed to do just that.In addition, this viewpoint would discourage increasing Symantec's size or adding to the complexity of their operations. I question Symantec's ability to do either one successfully. Symantec is certainly welcome to become bigger and more complex if that's what they should choose, but not as a result of some external mandate.Comments and corrections are welcome.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: An alternate perspective on Symantec

[Peter Kurrasch via dev-security-policy]

  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 addition to their regular business they have many marketing sites and various other consumer engagement portals--and, oftentimes, these microsites will be developed and operated by a outside firm.So in cases like these companies and brands, the notification can get complicated and possibly counter-productive. If I'm the outside firm ‎handling a special portal for some "super spicy cheesy puffs" marketing campaign (a hypothetical example), I might not care about Symantec or even website security because my livelihood depends on getting the portal up in time to launch the campaign at the next major sporting event. Assuming the portal even uses a certificate, the choice of CA to issue it might not even be mine to make. (And if the site should stop working for Firefox users because of an action taken against Symantec, you can bet it will make many people very angry.)I'm all for notifications and raising awareness but it's not necessarily easy or straight-forward to get the right message to the decision makers and the people who have to execute those decisions.From: Gervase Markham via dev-security-policySent: Thursday, June 8, 2017 4:07 AMTo: userwithuid; mozilla-dev-security-pol...@lists.mozilla.orgReply To: Gervase MarkhamSubject: Re: An alternate perspective on SymantecOn 07/06/17 06:14, userwithuid wrote:> 2. Having Symantec inform their subscribers, as David mentions, is a great idea.I believe Ryan has pointed out, here or elsewhere, why "must notifycustomers" requirements are problematic.Gerv___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Symantec response to Google proposal

[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 not think Symantec's customers can move quickly at all ‎given that a majority of them are large corporations that have to coordinate budgets, staff, outsourcing firms, and so forth. These customers also need time to familiarize themselves with the new rules and identify a course of action that makes sense for their business environments and their user base. Even though I understand the desire to move quickly, in this situation it seems imprudent to do so.Many will find this next bit unacceptable, but in the interest of providing an alternative, let me suggest a timeline of 6 different dates over the next 2 years (in case it really does take that long): the 21st day of February, May, and August of 2018 & 2019. Each of these dates represent a different milestone for changes in policy enforcement, certificate validation, software and systems, and whatever is identified as a deliverable in these ongoing discussions. The dates here are chosen specifically to acknowledge that many businesses operate on a quarterly system while avoiding complications that inevitably take place at the end of a quarter and the end of the year. And, yes, that would imply no action taken before Feb of next year.1) Scope of DistrustFirst a question: is removing the EV entitlements from the Symantec roots something that is still on the table for Mozilla products or has that been dismissed for some reason? I ask because it hardly ‎seems appropriate that a CA under sanction be entitled to all the benefits that are extended to CA's which are not under sanction. Doing so also inflicts some pain on Symantec (without breaking the global economy) until such time as they've resolved their issues to Mozilla's satisfaction.Regarding the expiration of certificates, I do not agree that CT logging engenders trust so I disagree with Symantec on that. Frankly I don't entirely agree with Google on the phased dis-trust and CT logging items. Those seem to increase complexity in the PKI ecosystem ‎(which carries its own risk) without necessarily improving the ecosystem, but it's very likely I've missed some important details.As to scope itself, my understanding is that Mozilla will eventually remove trust from all current Symantec roots (the "ubiquitous roots") and in its place use a set of "new roots", some of which will be under the purview of Symantec competitors. These new roots will be cross-signed to those ubiquitous roots so that new certs that chain up to these new roots will still validate properly on products that have not or cannot be updated to use the new roots.‎ (If my understanding is incorrect, I hope someone will correct me.)To put it another way, all existing certs that chain up to ‎the ubiquitous roots will eventually stop working--many before their date of normal expiration. As such, there needs to be a ramp up of new cert issuing capacity while at the same time a phasing out of the existing certs. Combining that with the above "alt-timeline" would look something like the following. The exact makeup of the root bundles and CA groups are TBD.Milestone 1 (Feb 21, 2018) - EV entitlement removed from the ubiquitous roots, new root cert bundle A ‎is ready to go, and CA group 1 is approved to begin issuing against the roots in bundle A. No new end entity certs have been issued yet.Milestone 2 (May 21, 2018) - New root bundle B is ready to go and CA group 2 is approved to begin issuing against bundle B, but has not yet done so.Milestone 3 (Aug 21, 2018) - New root bundle C is ready to go and CA group 3 is approved to begin issuing against bundle C, but has not yet done so.Milestone 4 (Feb 21, 2019) - New root bundle D is ready to go and CA group 4 is approved to begin issuing against bundle D, but has not yet done so. In addition, some analysis should be performed to evaluate the ‎overall health of the new root solution (for example, how many total certs have been issued, any reports of major disruptions to end users, etc.).Milestone 5 (May ‎21, 2019) - The fifth, and final, bundle E of new roots is ready to go and CA group 5 is approved to begin issuing against them but has not yet done so. This would also represent the earliest date that Symantec is allowed to be included in any of the CA groups.Milestone 6 (Aug 21, 2019) - Final removal of trust for the original Symantec roots.I know that some of this represents a significant departure from what Google and Symantec have previously discussed but I thought there might be some utility in having an alternate framework from which to draw.   

Re: DigiCert-Symantec Announcement

[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 shouldn't take this path but I am hoping we make smart, well-thought-out decisions along the way.Some thoughts:* Will there be other players in Symantec's SubCA plan or is DigiCert the only one?* ‎Is DigiCert prepared (yet?) to commit to a "first day of issuance" under the SubCA plan? That is, when is the earliest date that members of the general public may purchase certs that chain up through the new "DigiCert SubCA" to any of the Symantec roots? I hope that, for issues that may arise under the new system, there is sufficient time to identify and resolve them prior to the 2017-12-01 deadline.* I think the idea of a smart segregation plan for the roots and intermediates is a must-have. Such a plan should factor in the clientele who are using the different roots and the environments in which they operate. Given how important the "ubiquitous roots" are, I would hope to see community involvement and "sign-off", if you will.* I think it's appropriate to re-think some of the deadlines, given that we're talking less about a carrots-and-sticks model and more of one based on smart decision-making, good risk management, and sticks.Finally, when I went to read the DigiCert blog post, I noticed that John Merrill's link for the agreement announcement was a dud. I don't know why but I really don't care either. I think it serves as a reminder ‎that mistakes are going to be made during this process so it's best to make allowances for that in the plans going forward. That, and attention to detail is important.Thanks.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert-Symantec Announcement

[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 words!)Regarding the current Mozilla/Google plans, I don't necessarily have a problem with them but I do think we should give ourselves permission to make adjustments (if needed) because the circumstances have changed since those plans were developed. Consider:* Because the acquisition is now in the picture, legal issues might impede progress in certain areas. The most notable example is the fact that DigiCert will have limited authority over Symantec until the deal actually closes. For example, what will happen in the period between Dec 1 and the closing (assuming it's after the first)?* Once the deal does close, personnel and management issues could present various challenges in meeting certain deadlines. For example, if subject matter experts decide to leave Symantec prior to the closing, how might that hinder DigiCert?* A lot of churn is about to be introduced in the global PKI. Times of chaos create moments of opportunity for those who wish to do bad things. Should something happen, corrections may be necessary which can impact delivery dates, and so on.Let me be clear that these are just hypothetical situations and rhetorical questions. I don't expect answers and my only intention is to get people to start thinking about these matters (if they haven't already begun).Hopefully this better explains where I was coming from in my initial reply.From: Jeremy RowleySent: Thursday, August 3, 2017 8:13 PM‎ Hey Peter,  I think the Mozilla and Google plans both stand as-is, although probably need an updated based on this announcement.  I'm hoping that the high-level concepts remain unchanged:    - Migrate to a new infrastructure    - Audit the migration and performance to ensure compliance    - Improve operational transparency so the community has assurances on what is happening.  Jeremy  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 shouldn't take this path but I am hoping we make smart, well-thought-out decisions along the waysnip...* I think it's appropriate to re-think some of the deadlines, given that we're talking less about a carrots-and-sticks model and more of one based on smart decision-making, good risk management, and sticks.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[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 assurance in the cert chains that it allows. Having a cert chain successfully validated with a (perhaps?) hidden caveat of "by the way, we don't actually trust this cert because it doesn't comply with accepted policies" doesn't make much sense.The CA should decide what makes the most sense for their particular situation, but I think they‎ should be able to provide assurances that only BR-compliant certs will ever chain to any roots they submit to the Mozilla root inclusion program.From: Gervase Markham via dev-security-policySent: Friday, August 18, 2017 10:03 AM‎...What should our policy be regarding BR compliance for certificatesissued by a root requesting inclusion, which were issued before the dateof their request? Do we:A) Require all certs be BR-compliant going forward, but grandfather in   the old ones; orB) Require that any non-BR-compliant old certs be revoked; orC) Require that any seriously (TBD) non-BR-compliant old certs be   revoked; orD) something else?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[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 late would support such a statement. That said, I suppose situations may arise where the interests of the community and relying parties are better served by granting exceptions or waivers to that position. If a CA has a compelling argument for seeking such a waiver and would like to make their case, I suppose it doesn't hurt to hear them out.Perhaps some guidelines would be in order?* The non-compliant certs must not have the potential to cause harm. For example, maybe a compelling case could be made for allowing certs with faulty SAN data but I'm not sure a compelling case could be made for allowing SHA1 certs.* Mozilla has no obligation to create or maintain special functionality in its software to support non-compliant certs.‎ A CA requesting a waiver would need to accept the risk that some of their non-compliant certs could fail to validate in Mozilla products at some point in the future. * ‎In the spirit of transparency, a CA requesting a waiver should be prepared to provide documentation as to how many certs are to be covered by the waiver. For example: "As of (date) there are (number) certificates that do not comply with (specific requirements/policies) in the Not-before date range of (month/year) to (month/year)." Such documentation should be updated "regularly".* I think a CA should be made to explain why they are unable to bring their certs into compliance. There could be an understandable reason, so let's hear it. ("We don't want to" or "We can't afford it" are not acceptable reasons.)I think the bottom line has to be the trust relationship between Mozilla products and relying parties (end users specifically). If Mozilla says a connection is secure it has to mean that all elements of the connection meet the standards of technical excellence or, failing that, that Mozilla has deemed that the technical elements and special circumstances warrant the continued trust and use of that connection by the user.   From: Gervase 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> situation, but I think they‎ should be able to provide assurances that> only BR-compliant certs will ever chain to any roots they submit to the> Mozilla root inclusion program.So you are suggesting that we should state the goal, and let the CA workout how to achieve it? That makes sense.I agree with Nick that transparency is important.Is there room for an assessment of risk, or do we need a blanketstatement? If, say, a CA used short serials up until 2 years ago but hassince ceased the practice, we might say that's not sufficiently riskyfor them to have to stand up and migrate to a new cross-signed root. Iagree that becomes subjective.Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert-Symantec Announcement

[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 especially interested in learning how resilient the cert hierarchy will be should it become necessary to alter the hierarchy in response to an adversarial act or management mishap or PKI community sanction or perhaps even future standards work.I also wonder about the plan to allocate the "economically critical" customer base across the various intermediates. For example, should soda companies, banks, shipping companies, and media sites all be given the same consideration? What about main web sites vs static content servers (CDNs)? What about sites that are important to the economy but aren't necessarily the most popular?‎My hope is that there will be enough fault tolerance, redundancy, resiliency--call it whatever you like--built in to the system so that we know we have options available should we need them. The extent to which DigiCert can flesh out some of these details will be of benefit to the whole community.From: Jeremy Rowley via dev-security-policySent: Monday, August 21, 2017 12:48 AMTo: mozilla-dev-security-policyReply To: Jeremy RowleySubject: RE: DigiCert-Symantec AnnouncementHi everyone, We’re still progressing towards close and transition.  One of the items we are heavily evaluating is the root structure and cross-signings post close.  Although the plan is still being finalized, I wanted to provide a community update on the current proposal.Right now, Mozilla post stated that they plan to deprecate Symantec roots for TLS by the end of 2018.  We continue to work on a plan to transition all customers using the roots for TLS to another root, likely the DigiCert High Assurance root.  We will not cross-sign any Symantec roots, however we will continue using those roots for code signing and client/email certs post close (non-TLS use cases).  We also plan on using Symantec roots to cross-sign some of the DigiCert roots to provide ubiquity in non-Mozilla systems and processes.  However, this sign will only provide one-way trust, with the ultimate chain in Mozilla being EE-> Issuing CA -> DigiCert root in all cases.DigiCert currently has four operational roots in the Mozilla trust store: Baltimore, Global, Assured ID, and High Assurance. The other roots are some permutation of these four roots that were established for future use cases/rollover (ECC vs. RSA).  We already separate operations by Sub CA, with TLS, email, and code signing using different issuing CAs. As mentioned in my previous post, we plan on using multiple Sub CAs chained to the DigiCert roots to further control the population trusted by each Sub CA but have not decided on exact numbers. OV and EV will be limited  by Alexa distribution and/or number of customers.  DV isn’t readily identifiable by customer and will use a common sub CA.Root separation proves a difficult, yet achievable, task as there are only four operational roots: Baltimore, High Assurance, Global, and Assured ID. Global and High Assurance issue mostly OV/EV certs but do include code signing and client certificates. High Assurance is our EV root and used for both EV code signing certificates and TLS certs.   Baltimore is our cross-signed root and used primarily by older Verizon customers. Assured ID is used mostly for code signing and client.  However, Assured ID is also our FBCA root, meaning government-issued TLS certificates chain to it.  Of course, all TLS certs are issued in accordance with the BRs regardless of root. Looking at the current customer base, our current plan is to issue EV (code and TLS) from High Assurance, OV (code and TLS) from Global. Assured ID will continue as our client certificate and government root. We plan to continue using Symantec roots for code signing and client.  We’re still looking into this though. We’d love to separate out the roots more than this, but that’s not likely possible given the current root architecture. If there is a non-cross-signed Symantec root that the browsers are not planning to remove, we’d like to continue using the root to issue high volume DV and device certificates.  If this is not possible and Mozilla is still planning on distrusting all Symantec roots, we’ll likely migrate DV certs to a Sub C

Re: DigiCert-Symantec Announcement

[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 soon-to-be old Symantec infrastructure...? for the foreseeable future (i.e. post-Dec 1)?Also it's not totally clear to me what will be delivered on Dec 1, 2017 in terms of infrastructure as well as issuance policies.From: Jeremy Rowley via dev-security-policySent: Sunday, October 1, 2017 2:55 PM‎Is this a correct summary? There’s four categories of customers that require trust in existing Symantec roots being address:...4.	Those that pinned a specific intermediate’s keys, resulting in a failure unless the issuing CA had the same keys as used by Symantec. ...‎Category 4 is under discussion.  Sounds like Google would prefer not to see a reuse of keys. Pinning times are sufficiently short that customers could migrate to the new infrastructure prior to total distrust of the roots under certain circumstances. If the cert was issued prior to June 2016, and the key expires after March 2018, anyone using the pin could be locked out until the pin expires. If pins last up to a year, customers issuing a cert after June 2016 should have time to migrate prior to root removal. One issue is that these customers won’t be able to get a new cert that functions off the old intermediate post Dec 1, 2017, effectively meaning key compromises cannot be addressed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Francisco Partners acquires Comodo certificate authority business

[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 forum? I would expect any such announcement to provide details on the skills and experience that this new leadership team has in running a CA. ‎For example, are they aware of section 8 of the Mozilla Root Store Policy?From: Kyle Hamilton via dev-security-policySent: Tuesday, October 31, 2017 12:51 PMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Kyle HamiltonSubject: Re: Francisco Partners acquires Comodo certificate authority businessAnother article about this is http://www.securityweek.com/francisco-partners-acquires-comodo-ca .Notably, I'm not seeing anything in the official news announcements pages for either Francisco Partners or Comodo.  Is this an attempt at another StartCom (silent ownership transfer), or is it a case of "rumor mill reported as fact"?-Kyle HOn 2017-10-31 06:21, Kyle Hamilton wrote:> http://www.eweek.com/security/francisco-partners-acquires-comodo-s-certificate-authority-business >>>___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Francisco Partners acquires Comodo certificate authority business

[Peter Kurrasch via dev-security-policy]

  The timing and content of any announcement is undoubtedly complicated, caused, in no small part, by legitimate needs for confidentiality against the goals of transparency. I have every reason to trust in the good judgment of Gerv and Kathleen in navigating that path with the interests of this community in mind. If there is more they are able to say on this matter, I hope that they will; if not, I will understand.That said, I ‎hope someone will indeed say more about the reporting in these articles. There are 2 issues in particular that I think would be good to address at this time. The first is the use of the past tense (e.g. "has acquired") regarding the reported transaction. How much of the acquisition process has, in fact, transpired--if anything?The second is ‎the meager explanation of what has transpired or is expected to transpire--again, if anything. Based on my understanding, there is (or will be) a change of legal ownership and leadership. Accordingly, is a review of the new ownership warranted? Bringing together a CA with a Deep Packet Inspection business certainly is...uncomfortable.It is my sincere hope that someone will come forward and provide some clarity, even if just to say this is fake news.   From: Ryan SleeviSent: Tuesday, October 31, 2017 2:59 PM‎To: Peter KurraschReply 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.mozilla.org> wrote:  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? I would expect any such announcement to provide details on the skills and experience that this new leadership team has in running a CA. ‎For example, are they aware of section 8 of the Mozilla Root Store Policy?Such announcements are not part of the Mozilla Policy expectations. Could you clarify why you expect such an announcement? 

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

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

[Peter Kurrasch via dev-security-policy]

  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 end-entity certificates. Also as a sign of good faith, the acquirer would agree not to make changes to staff, infrastructure, keys, and so forth and will abstain from changing the interconnectedness of root and intermediate certs.The idea here being that if we should encounter something that is not acceptable, we need the ability to undo any actions taken during the probationary period. I was thinking 6 weeks would allow enough business days for people to investigate any issues that might arise and accommodate vacation schedules and such. I also think the probationary period would be granted under only certain circumstances--that is, not every acquirer will necessarily qualify.From: Gervase Markham via dev-security-policySent: Wednesday, November 1, 2017 6:04 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Gervase MarkhamSubject: Re: Francisco Partners acquires Comodo certificate authority businessOn 31/10/17 13:21, Kyle Hamilton wrote:> http://www.eweek.com/security/francisco-partners-acquires-comodo-s-certificate-authority-businessComodo notified Mozilla of this impending acquisition privately inadvance, and requested confidentiality, which we granted. Now that theacquisition is public, it is reasonable for the community to have adiscussion about the implications for Mozilla's trust of Comodo, if any.However, there is also another wrinkle to iron out. Our policy 2.5 says:"If the receiving or acquiring company is new to the Mozilla rootprogram, there MUST be a public discussion regarding their admittance tothe root program, which Mozilla must resolve with a positive conclusionbefore issuance is permitted."I personally feel that this is a bug, in that technically it says thatas soon as a deal closes and is announced, the CA has to stop issuanceentirely until the Mozilla community has had a discussion and given theOK. I believe that's not reasonable and would create massive businessdisruption if the letter of that rule were enforced strictly. I thinkthat when we wrote the policy, we didn't anticipate the situation wherethe buyer would be confidential until closing. (Compare Digimantec,where it's not.)So it would also be useful to have a discussion about what this sectionof the policy should actually say.Gerv___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Acquisition policy (was: Francisco Partners acquires Comodo certificate authority business)

[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 are free to raise concerns as they come up. I think we've had examples of exactly that in both StartCom and Symantec.‎ Perhaps one way to think of it is: Do we have reason to believe that the acquiring organization, leadership, etc. will probably make good decisions in the furtherance of public trust on the Internet? For a company that is a complete unknown, I would say that no evidence exists and therefore a public review prior to the acquisition is appropriate. If we do have sufficient evidence, perhaps it's OK to let the acquisition go through and have a public discussion afterwards.The Francisco Partners situation is more complicated, however. Francisco Partners itself does not strike me as the sort of company that should own a CA but only because they are investors and not a public trust firm of some sort. That said, they are smart enough to bring in a leadership team that does have knowledge and experience in this space. Unfortunately, though, they are also bringing in a Deep Packet Inspection business which is antithetical to public trust. So what is one to conclude?The reporting that I've seen seem to indicate that Francisco Partners will not (will never?) combine ‎PKI and DPI into a single business operation. They have to know that doing so would be ruinous to their CA investment. If we assume they know that and if we are willing to take them at their word, I suppose it's reasonable to "allow" the transfer as it relates to Mozilla policy. If we should learn later on that that trust was misplaced, I'm sure we will discuss it and take appropriate action at that time.From: westmail24--- via dev-security-policySent: Wednesday, November 8, 2017 7:50 PMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: westmai...@gmail.comSubject: Acquisition policy (was: Francisco Partners acquires Comodo certificate authority business)Hello Peter, But what prevents Francisco Partners making security nightmare after the probationary period? This is logical, I think.Regards,Andrew___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Possible future re-application from WoSign (now WoTrus)

[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 and Kathleen’s so kind consideration and so great 
arrangement for this pre-discussion.
Second, thanks for the community participants to help us know our problem 
clearly in the past year, we wish you can give us a chance to serve the 
Internet security.

Here is our response covered your questions that we don’t reply the emails one 
by one.

...snip...

Finally, as a CA, we fully understand that the mistakes we have made are 
significant. By the sanction, we learned the importance of maintaining trust 
and compliance, and we hope to provide excellent products and services as 
compensation for our mistakes, and to serve the Internet security to regain 
public trust.
We’d love to hear your feedback and we are trying to do better and better, 
thanks.

Best Regards,

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

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

[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 to seriously consider a CA which has Richard in any sort of management position, much less as CEO. I look at the depth and breadth of his deceptive acts, the technical/policy/compliance issues that were present at WoSign and StartCom under his leadership, the defiance of any expectation that CA's should exhibit reasonable levels of transparency and forthrightness, the amount of time and effort spent in this forum on the myriad WoSign and StartCom issuesOne is left to consider how much tolerance remains in the community for further mistakes and transgressions th‎at might arise from WoTrus? What incentive does Richard have to be forthcoming in the future knowing that the community might take harsh action against his company? How much time should WoTrus be allowed to consume knowing it might unfairly affect the inclusion requests of new CA's or the addressing of situations that arise at other CA's or the discussion of ideas for advancing security throughout the global PKI?When the initial sanction against WoSign and StartCom took place I think many in this forum would have been content to let both CA's fade away into the land of distrust and ultimate removal. That Mozilla allowed both to remain was, I think, an act of generosity with the expectation being(?) that, with a change in leadership and a new technology infrastructure, the global PKI will be better off for keeping WoSign/StartCom as trusted CA's‎. It's not (yet) clear that enough improvements have been made to the infrastructure and, obviously, there has been no change in leadership.With everything taken together I just don't see the benefit of including WoTrus in the trusted CA program. The costs to the community have been high--and probably will continue to be high. The risks have been many--and probably will continue to be many. And the benefits would appear to be too few.From: Danny 吴熠 via dev-security-policySent: Monday, November 27, 2017 2:39 AM‎Dear Gerv, Kethleen, other community friends,First, thanks for Gerv and Kathleen’s so kind consideration and so great arrangement for this pre-discussion.Second, thanks for the community participants to help us know our problem clearly in the past year, we wish you can give us a chance to serve the Internet security.Here is our response covered your questions that we don’t reply the emails one by one.Part One: What we have done in the past year since the sanction(1)After we knew the distrust sanction would be started from Oct. 20, 2016, we started to talk to some CAs to deal with the Managed Sub CA solution, and we signed agreement with Certum and started to resell their SSL certificates since Nov. 21, 2016. And we set up second Managed Sub CA from DigiCert since June 30, 2017.(2)We sent replacement notices to all charged customer and we have replaced more than 6000 certificates for customers for free.(3)We realized our big problem is the compliance with the Standard, so we set up a department: Risk Control & Compliance Department (RCC), which have 5 persons, the manager is from the bank IT risk control department, he leads team for the risk control management and internal audit. Two English major employees, they are responsible to translate all WebTrust documents and all CAB Forum documents into Chinese to let all employees learn the Standard more clearly. And one is responsible for checking CAB Forum mailing list to produce a weekly brief in Chinese for CAB Forum activity to all department managers, one is responsible for checking Mozilla D.S.P. mailing list to produce a weekly brief in Chinese. And they produce summary report if some CA have accident report to let us learn how to prevent the same mistakes and how to response to the Community. Another two employees are security test, one from PKI/CA RD team, one is from Buy/CMS RD team, they are responsible for the system test and security test to two RD team developed system. And this department setup many internal management regulations, it is the internal auditor to check and verify every CA operation is complaint with the Standard.(4)We started to develop new PKI/CA system including validation system, OCSP system, CT system an

Re: On the value of EV

[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 seems that Ryan and others at Google, others in this forum, and perhaps the authors of the reports he originally cited are advocating an answer of, Yes: forget about EV, it is possible to spoof therefore nobody is safe. There is certainly a seductive purity and ruthless simplicity to such an argument.The counter-argument being made is, No: there is some value to these measures and they should remain. There is value in a human readable, positive affirmation that ‎I am where I want to be even if there's a possibility I'm being tricked. Viewed in the context of a layered approach to security, the UI signals are one more layer and if this one layer should falter, the others might help prevent a bad outcome.I would add 2 points: First, we should acknowledge the possibility for users to do all the right things and still end up with a bad result. Sometimes the bad guys are smarter than the good guys. This is especially the case when malware infects a system and that malware is able to assert every positive security indicator while doing its dirty work behind the scenes.Second, the actual value in EV as far as I can see is in having that human readable name in addition to the domain name. A successful plan of attack will need convincing names for both, which does raise the bar on an attacker. If EV and the UI treatments were to go away, it would simplify the task for some attackers and that seems undesirable.    From: Ryan Sleevi via dev-security-policySent: Friday, December 15, 2017 4:24 PMIf the signal can be spoofed, it does not actually help keep you safe.‎
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CABF Recommendations (was: On the value of EV)

[Peter Kurrasch via dev-security-policy]

  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 tactics will surface when applying for an EV cert.With that in mind, it is in the CA's own best interest to improve the policies and requirements behind EV issuance. ‎The finance industry has regulations generally known as "Know Your Customer" (KYC) that are intended to stave off such things as money laundering, terrorist financing, and such. While not directly applicable to CA's and EV, KYC nonetheless might serve as a model whereby clients are scrutinized before certain actions are permitted by the CA.For example, it seems indefensible to me that a CA should issue a EV cert to a company that has no prior history and offers only the thinnest of evidence to its legitimacy, as was documented in the original reports. All CA's must do better in that regard. I don't think it's unreasonable for CA's to have a documented, pre-existing relationship with a EV requester prior to the actual EV issuance.Further, a EV requester must do more than offer its existence but be able to prove its legitimacy as an organization, institution, individual, and so forth. Such a requester should already have a presence on the Internet and, ideally, can demonstrate ‎a level of competency in operating a secure web server. There seems no justification in my mind for a company to go from nonexistent to EV cert holder in 24 hours' time, for instance.I also would discourage the use of statements such as "EV will prevent phishing attacks" as such claims are misleading. A phishing attack may take many forms, and setting up a fake website is but one of them. Likewise, my reasons for setting up a fake website are many and might have nothing to do with phishing. Instead, I would recommend a more direct approach: "EV certs allow you to associate your company name with your domain names". There is value in that alone.Again I will state that it's in the best interests of CA's to improve their EV issuing guidelines and practices. While CA's no doubt enjoy charging a premium for EV services there is no reason for browsers or the security community to recognize ‎any service that based on vapor. Indeed, the community seems to be saying right now that the status quo is not acceptable. The time for action is now.From: Tim Hollebeek via dev-security-policySent: Monday, December 11, 2017 1:33 PM‎Happy to share the details.We only had about 10 minutes on the agenda, so the discussion hasn’t been too detailed so far (there is still a lot of fallout from CAA that is dominating many validation discussions).  There was a general consensus that companies with intentionally misleading names, and companies that are recently created shell companies solely for the purpose of obtaining a certificate should not be able to get an EV certificate.Exactly what additional validation or rules might help with that problem, while not unnecessarily burdening legitimate businesses will require more time and discussion, which is why if anyone has good ideas, I’d love to hear them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Disallowed company name

[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 well as the real world. For example, not everyone in this forum trusts me (and perhaps shouldn't). 2. Bad actors will resort to trickery, lies, and deception to get what they want and sometimes they will be successful despite every effort to stop them.3. The onus is on CA's to prove that "additional validation" equals "more trustworthy". Their failure to do so will lead to the demise of EV.Security can be viewed as a series of AND's that must be satisfied in order to conclude "you are probably secure". For example, when you browse to an important website, make sure that "https" is used AND that the domain name looks right  AND that a "lock icon" appears in the UI AND, if the site uses EV certs, that the name of the organization seems correct. Failing any of those, stop immediately; if all of them hold true, you are probably fine.As the token bad guy in this forum, I have to make all of those steps happen if I expect to trick my victims. If I bother to get an EV cert but the name wildly mismatches for my particular objective, there's an increased chance my efforts at deception will fail. If any of those steps are taken away, my job is that much easier.From: Wayne Thayer via dev-security-policySent: Thursday, May 31, 2018 5:39 PM‎...> In my opinion, this is just a rehash of the same debate we've been havingover misleading information in certificates ever since James obtained the"Identity Verified" EV certificate. The options we have to address thisseem to be:1. Accept that some entities, based on somewhat arbitrary rules anddecisions, can't get OV or EV certs2. Accept that the organization information in certificates will sometimesbe misleading or at least uninformative3. Decide that organization information in certificates is irrelevant andignore it, or get rid of itWe currently have chosen "some parts of all of the above" :-)I am most interested in exploring the first option since that is thedirection CAs are headed with the recent proposal to limit EV certificatesto organizations that have existed for more than 18 months [1]. As long asanyone can obtain a DV certificate, are restrictions on who can obtain anOV or EV certificate a problem, and if so, why?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy