Re: Consequences of mis-issuance under CNNIC

Hi Matt, On 01/04/15 23:44, Matt Palmer wrote: > I'd like to see discussion of what happens if things *don't* go according to > plan, though. The plan relies quite a bit on CNNIC's cooperation, both to > provide the list of existing certificates, as well as making (and abiding > by) the undertaki

Re: Consequences of mis-issuance under CNNIC

On 02/04/15 02:42, Reed Loden wrote: > From > http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html Indeed. It seems that Google have independently come to very similar conclusions to us. Gerv ___ dev-security-

Re: Consequences of mis-issuance under CNNIC

On 02/04/15 12:42, Sebastian Wiesinger wrote: > the plan would be to continue allowing current certificats (perhaps > with some sort of whitelist) while not accepting new certificates. > > Could you ask Google to share their whitelist? Until they announced, we were not aware that Google would be

Re: Consequences of mis-issuance under CNNIC

On 02/04/15 19:33, Daniel Micay wrote: > Is there really a way we could notice this? Other than a leak from an > employee at CNNIC... To be used, certs generally have to be public. Which means people can find them. And compare them to lists. We may end up coding the whitelist into Firefox, we may

Re: Consequences of mis-issuance under CNNIC

On 02/04/15 09:49, c.le...@gmail.com wrote: > China has a enormous internet population and enormous number of > websites. Yes CNNIC acted like a dangerous kid. But you really think > making all Chinese unable to do any online transaction is the > solution we want to push? Our plan will not have th

Re: Consequences of mis-issuance under CNNIC

On 03/04/15 01:46, Matt Palmer wrote: > On the other hand, CNNIC's blog post suggests that they haven't. There's > some serious cognitive dissonance going on here. Just to close this loop: CNNIC have now supplied us with a ZIP file of all their currently-valid issued certificates. Given that Goo

Re: Consequences of mis-issuance under CNNIC

On 05/04/15 13:12, Erwann Abalea wrote: > It would be very helpful if you could provide some evidence of this. > Qihoo 360 is a browser member of the CABForum, the product treats > certificate validation errors differently than other browsers, in a > non secure way. But having "additional certific

Re: Are CAs required to update their CPS annually

On 04/04/15 04:20, Eugene wrote: > According to the CA Baseline Requirements section 8.2.1, "The CA > SHALL develop, implement, enforce, and **annually update** a > Certificate Policy and/or Certification Practice Statement that > describes in detail how the CA implements the latest version of thes

Re: Requirements for CNNIC re-application

On 08/04/15 01:31, Richard Barnes wrote: > decides to require of them. The purpose of this thread is to discuss what > additional steps, if any, we should require. > > CNNIC has already provided Mozilla with a list of certificates issued > before 1 Apr 2015. We are working on publishing this lis

Re: DRAFT of next CA Communication

On 09/04/15 21:12, yuhongbao_...@hotmail.com wrote: > What about Mozilla's own aus3.mozilla.org certificate for which the SHA-1 > intermediate was pinned? I'm afraid I don't understand the question, or how it relates to the CA Communication. Can you clarify? Gerv ___

Re: Requirements for CNNIC re-application

On 11/04/15 01:05, Brian Smith wrote: > If a US-based CA were in a similar situation, would we consider name > constraining them to *.com, *.org, *.net, *.us? If it were a US government CA, we could certainly constrain to .gov and .mil. > No, because that's not > much of a constraint. For people

Re: Requirements for CNNIC re-application

On 14/04/15 01:19, Matt Palmer wrote: > I'm not a fan of browser-imposed name constraints on CAs, at a philosophical > level. An important principle of the Mozilla root program, IMO, is that it > works for the public good (insofar as "the public" is represented by "users > of Mozilla products").

Re: Requirements for CNNIC re-application

On 14/04/15 00:15, Peter Kurrasch wrote: > Let's use an example. Suppose CNNIC issues a cert for > whitehouse[dot]gov presumably without permission ;-)... > and let's further suppose that CNNIC includes this > cert in the CT data since they have agreed to do that. What happens > next? If no

Re: Policy about root cert transfers

On 24/04/15 08:17, Man Ho (Certizen) wrote: > The term "transfer" a root certificate is new to me. What are the > rationale of such transferal? Move from one location to another > location, or from one HSM to another HSM? Ownership of the CA had > changed from one organization to another organizati

Re: DRAFT of next CA Communication

On 29/04/15 17:23, Kathleen Wilson wrote: > I will appreciate your feedback on the email and the survey (use link > below). All looks good to me. Although it's a shame Salesforce seems not to be able to embed links. Gerv ___ dev-security-policy mailing

Re: DRAFT of next CA Communication

On 05/05/15 21:54, Kathleen Wilson wrote: > EXAMPLE/DRAFT Survey Link: > https://community-mozillacaprogram.cs21.force.com/Communications/TakeSurvey?id=a04q004jpXoAAI&cId=&caId=none LGTM. Gerv ___ dev-security-policy mailing list dev-security-polic

Name-constraining government CAs, or not

Hi everyone, The topic of name-constraining government CAs, probably to the TLD(s) of their territory(ies), has come up numerous times. I'd like to try and hash out, once and for all, whether we think this is actually a good idea, so we can decide to work towards doing it, or decide actively not t

Re: Name-constraining government CAs, or not

On 14/05/15 17:02, David E. Ross wrote: > There is an ongoing dispute between the U.S. and China whether the > government in China is behind attacks on both government and commercial > computer systems in the U.S. This is NOT to question the > trustworthiness of the government of China but to give

Re: Name-constraining government CAs, or not

On 15/05/15 00:01, Ryan Sleevi wrote: > On Thu, May 14, 2015 9:02 am, David E. Ross wrote: > >> With "cyberwarfare" constantly discussed in the news, U.S. Congress, and >> other venues, it appears to me that government CAs should indeed be >> restricted to the TLDs of their respective jurisdict

Re: Name-constraining government CAs, or not

On 17/05/15 02:12, Ryan Sleevi wrote: > I say this because knowing Gerv, and having participated with him on the > call, I suspect that in part this is motivated by > https://cabforum.org/2015/04/16/2015-04-16-minutes/ , in which Microsoft > has suggested they'll require "government CAs" (definitio

Re: Name-constraining government CAs, or not

On 17/05/15 23:28, Peter Bowen wrote: > I'll bite. > > What if Mozilla puts a simple rule in place? > > All CAs must either: > - Have a WebTrust for BR and ETSI TS 102 042 assessment conducted by a > assessor who meets the requirements of BR 8.2 or > - Be named constrained The result of that wou

Re: Name-constraining government CAs, or not

On 18/05/15 11:26, Kurt Roeckx wrote: > I think it only makes sense to name constrain a government CA if the > name constrained only covers government websites, and not all websites > in the country. Examples would be covering *.gov and *.go.jp. I think > that restricting them to *.jp, *.in, *.cn

Re: Name-constraining government CAs, or not

On 17/05/15 00:45, Eric Mill wrote: > Governments are not subject to the same kind of leverage, accountability or > market forces that corporations are. The legal constraints they operate > under are different, your likelihood of prevailing in a legal action > against them is different (and highly

Re: Name-constraining government CAs, or not

On 18/05/15 14:45, Gervase Markham wrote: > On 17/05/15 23:28, Peter Bowen wrote: >> I'll bite. >> >> What if Mozilla puts a simple rule in place? >> >> All CAs must either: >> - Have a WebTrust for BR and ETSI TS 102 042 assessment conducted by a >

Re: Name-constraining government CAs, or not

Before I reply, can I say that this level of informed and considered debate is _exactly_ what I was looking for? Thanks to everyone who has participated so far. On 15/05/15 19:49, Ryan Sleevi wrote: > - By introducing a demarcation of power/privilege by "government" or not > (which still suffers f

Re: Name-constraining government CAs, or not

On 19/05/15 02:15, Matt Palmer wrote: > I disagree that "we, the browsers and standards bodies of the Internet" have > very different leverage. In either case, if a CA misbehaves, their root > certs can be pulled from the trust store (or otherwise neutered). That > doesn't change because the CA i

Re: Name-constraining government CAs, or not

On 18/05/15 17:39, Kurt Roeckx wrote: > On the other hand, if it covers the whole country, they can abuse > it for domains in that country, but not for other domains. I'm > not sure why you would find it acceptable that they can abuse it > in their own country. Some countries, AIUI, do not have a

Re: Name-constraining government CAs, or not

On 19/05/15 12:14, Matt Palmer wrote: > The *leverage* that can be applied to any particular CA doesn't change based > on who operates it. Regardless of the operator, the only leverage we have > is removal of the CA's root certs from the trust store (or otherwise > neutering them). That certain C

Re: Name-constraining government CAs, or not

On 19/05/15 13:14, Kurt Roeckx wrote: > On 2015-05-14 17:25, Gervase Markham wrote: >> CAs currently in Mozilla's program which may fit one or more definitions >> of "government CA" are: > > It might be a little out of scope of your question, but maybe we

Re: Name-constraining government CAs, or not

On 21/05/15 13:56, Peter Kurrasch wrote: > ‎‎Returning to your original post, Gerv Thank you :-) > So here is where the difference really lies between government and > commercial CAs: control. Governments and, therefore, government CAs > wield a level of control that commercial entities norma

Re: Requirements for CNNIC re-application

Hi Percy, On 24/05/15 06:19, percyal...@gmail.com wrote: > This is Percy from GreatFire.org. We have long advocated for the > revoking of CNNIC. > https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=site%3Agreatfire.org%20cnnic > > If CNNIC were to re-included, CT MUST be

Re: Requirements for CNNIC re-application

On 26/05/15 22:26, Kathleen Wilson wrote: > But this raises the question of whether their re-application can be for > the same (currently-included) root certificates, or if it has to be for > a new root certificate. In other words, should we consider taking the > stance that we will require a new r

Re: Requirements for CNNIC re-application

On 28/05/15 00:32, Peter Kurrasch wrote: > I think this is the crux of the problem: how do we want to treat all > the existing certs which chain to this root? That's not the only problem. Requiring CNNIC to apply with a new root would also require them to go through the inclusion process again in

Re: Requirements for CNNIC re-application

On 30/05/15 20:20, Brian Smith wrote: > By the way, what is Firefox's market share in China and other places that > commonly use CNNIC-issued certificates? My understanding is that it is > close to 0%. That's why it was relatively easy to remove them in the first > place. It also means that there's

Re: Requirements for CNNIC re-application

On 28/05/15 23:07, Richard Barnes wrote: > I agree that if CNNIC is to reapply, it should be with a new root. It > creates a clean break between the past and the future. It clarifies that > the new audits that are required apply to the new thing, and that the old > thing is dead. It's marginally

Re: Name-constraining government CAs, or not

On 31/05/15 23:43, Ryan Sleevi wrote: > I agree, this is the strongest argument against government CAs presented > in this thread, and I wish this, rather than the musings of secret courts > and "maybe impossibles", was the core of your argument. > > These arguments apply not just to government CA

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

On 06/06/15 02:12, Brian Smith wrote: > Richard Barnes wrote: > >> Small CAs are a bad risk/reward trade-off. > > Why do CAs with small scope even get added to Mozilla's root program in the > first place? Why not just say "your scope is too limited to be worthwhile > for us to include"? There's

Re: Publicly disclosed and audited policy

On 16/06/15 02:54, Peter Bowen wrote: > First, the policy says "All disclosure MUST be made freely available and > without additional requirements, including, but not limited to, > registration, legal agreements, or restrictions on redistribution of the > certificates in whole or in part." > > If

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

On 17/06/15 22:50, Brian Smith wrote: > By "small scope," I'm referring to CAs who limit their scope to a certain > geographical region, language, or type of institution. I'm not sure how that neuters my objection. CAs who do more than DV will need to have local infrastructure in place for identit

Re: Letter from US House of Representatives

On 06/07/15 15:34, Ben Wilson wrote: > =P7-TA-2014-0282> &language=EN&reference=P7-TA-2014-0282, I was asked (by > someone in the audience and not by anyone specifically representing EU > governments) to relay a message that some European supervisory bodies would > like browsers and OS providers to

Re: Letter from US House of Representatives

On 06/07/15 17:44, Ben Wilson wrote: > Thanks. I realize/think that this would require a separate root > program. If you think of it as a Venn diagram there would be Set A > and Set B. The user would then select A, B, A U B or A ∩ B. The trouble with this is that, while it makes sense to you

Re: Expired Servers Certificates

On 24/07/15 06:45, David E. Ross wrote: > In Certificate Manager, on the Servers tab, I see a number of > certificates that were apparently placed there to force distrust. Most > of them have expired. Are they still needed? Yes, because the UI treatment of an expired certificate is different to

Re: May 2015 CA Communication

On 03/08/15 19:40, Kathleen Wilson wrote: > 1) Responses to Action #3 -- SHA-1 Deprecation Plans Several large CAs have significant outstanding inventory of SHA-1 certs which are valid beyond 2017 and have no plans to revoke them. This is fine in that there is no requirement to revoke them (AIUI),

Re: May 2015 CA Communication

On 06/08/15 17:39, Kathleen Wilson wrote: > Suggestions? I'll defer to Ryan on that; this is his pony at the moment :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-pol

Re: Updating Mozilla's CA Certificate Policy

Hi Kathleen, On 20/08/15 19:12, Kathleen Wilson wrote: > It's time to begin discussions about updating Mozilla's CA Certificate > Policy. Great :-) > A list of the things to consider changing is here: > https://wiki.mozilla.org/CA:CertPolicyUpdates#Consider_for_Version_2.3 How do you want to de

Re: Updating Mozilla's CA Certificate Policy

On 24/08/15 16:02, Kathleen Wilson wrote: > I will open a separate discussion thread for each item, beginning with > "1. Clean up the "Other considerations when updating the CA Certificate > Policy" section of the Potentially Problematic Practices page. i.e. > figure out which items should be put d

Re: Remove Roots used for only Email and CodeSigning?

On 03/09/15 19:22, Kathleen Wilson wrote: > 2) Remove included root certs that only have the Code Signing trust bit > enabled. To our knowledge, no one is using such root certs via the NSS > root store. This seems like a half-way house. If no-one is using our root store as a code-signing root stor

Re: Remove Roots used for only Email and CodeSigning?

On 04/09/15 14:09, Phillip Hallam-Baker wrote: > Has Mozilla stopped supporting Thunderbird? No. Mozilla-the-project still develops and supports Thunderbird. I had thought this was about code signing only, but reading back, I was wrong. I would certainly oppose deprecating the email bit in our ro

Re: Remove Roots used for only Email and CodeSigning?

Hi Ryan, Thank you for your thought-provoking critique :-) Much appreciated. On 07/09/15 17:54, Ryan Sleevi wrote: > Once included, what criteria do they need to abide by? Only Item 7 from > the Inclusion policy - > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/poli

Re: Remove Roots used for only Email and CodeSigning?

On 08/09/15 10:54, Rob Stradling wrote: > Assuming this is still Mozilla's plan, please would you clarify which > versions of Firefox and Thunderbird will be (or were?) the first > versions that won't accept "normal CA-issued object-signing certificates" ? Extension signing was historically very r

Re: Remove Roots used for only Email and CodeSigning?

On 11/09/15 22:06, Rob Stradling wrote: > On 11/09/15 13:05, Gervase Markham wrote: >> On 08/09/15 10:54, Rob Stradling wrote: >>> Assuming this is still Mozilla's plan, please would you clarify which >>> versions of Firefox and Thunderbird will be (or were?) t

Re: Firefox security too strict (HSTS?)?

On 15/09/15 01:12, Anil Gulati wrote: > To remove unnecessary impediments to Firefox use and adoption wouldn't it > make sense to configure Firefox to use the OS cert store by default, and > allow an option to use internal cert database? We would love it if the OS would give us a list of _just_ t

Re: Remove Roots used for only Email and CodeSigning?

On 18/09/15 09:55, Rob Stradling wrote: > But since there are no current plans to change Thunderbird... > Does this mean that Thunderbird still has a use for code signing > certificates from commercial CAs and, consequently, the NSS code signing > trust bit? That would be a question for the Thunde

Pre-cert misissuance

Symantec just fired people for mis-issuing a google.com 1-day pre-cert: http://www.symantec.com/connect/blogs/tough-day-leaders http://googleonlinesecurity.blogspot.co.uk/2015/09/improved-digital-certificate-security.html Google: "Our primary consideration in these situations is always the secur

Re: Pre-cert misissuance

On 19/09/15 19:12, Brian Smith wrote: > On Sat, Sep 19, 2015 at 7:20 AM, Gervase Markham wrote: > >> Symantec just fired people for mis-issuing a google.com 1-day pre-cert: > > By the way, Symantec didn't say "pre-cert," they said "certificates". >

Let's Encrypt issues first cert

Surprisingly, this development has not been commented upon here: http://www.zdnet.com/article/lets-encrypt-issues-first-free-digital-certificate/ This happened 9 days ago, but I only found out about it today, in a random email from LinkedIn... Gerv ___

Re: Policy Update Proposal: Remove Code Signing Trust Bit

On 24/09/15 02:58, Peter Kurrasch wrote: > I suppose my comment was not as clear as I intended but, yes, I think > Mozilla's commitment to openness is a reason to keep the code sign bit > and continue to review CA inclusion requests for their code signing > roots. I'm not aware of another organizat

Re: Remove Roots used for only Email and CodeSigning?

On 24/09/15 17:50, Kai Engert wrote: > A Java runtime can include its own root store. > > For OpenJDK on Fedora Linux, my understanding is, we configure it to use the > system's trust store, which contains the Mozilla trust bits. Do we know how different that makes the behaviour from a JDK which

Re: Policy Update Proposal: Remove Code Signing Trust Bit

On 24/09/15 16:53, Richard Wang wrote: > I think FireFox plugin XPI need to be signed, this is the usage. That is no longer the case. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev

Re: Remove Roots used for only Email and CodeSigning?

On 24/09/15 17:24, Kai Engert wrote: > In past versions of Firefox, there was code that checked for a signature in > the > Add-On, and the user interface that asked for permission to install displayed > information found in the signature (the name of the owner of the code signing > certificate).

Re: Policy Update Proposal: Remove Code Signing Trust Bit

On 01/10/15 02:43, Brian Smith wrote: > Perhaps nobody's is, and the whole idea of using publicly-trusted CAs for > code signing and email certs is flawed and so nobody should do this. I think we should divide code-signing and email here. I can see how one might make an argument that using Mozilla

Re: Policy Update Proposal: Remove Code Signing Trust Bit

On 04/10/15 13:18, kirk_h...@trendmicro.com wrote: > As to whether or not to remove the trust bits for code signing and > email, I guess I would ask: Why did Mozilla include/create the trust > bits in the first place? You would need to ask Netscape :-) > Was it only to support Mozilla application

Re: Policy Update Proposal: Remove Code Signing Trust Bit

On 04/10/15 23:02, R Kent James wrote: > You seem to be implying that Thunderbird is no longer a Mozilla > application. Where do you get this idea? No need to get upset, Kent - Kirk's head is in the CA world, not the Mozilla world. Your points about Thunderbird's role are reasonable ones, but let'

Re: Policy Update Proposal -- Specify audit criteria according to trust bit

On 22/09/15 05:07, Kathleen Wilson wrote: > First, we need to determine if the Email trust bit should remain part of > Mozilla's CA Certificate Policy. One perhaps somewhat relevant piece of information in this discussion is whether anyone is using S/MIME. After all, if no-one is using it, maintai

Re: Policy Update Proposal -- Specify audit criteria according to trust bit

On 08/10/15 09:56, Gervase Markham wrote: > A major CA was kind enough to share their numbers with me. They said: > > "We issued 275,000 client/smime certificates in the last year as soft > certificates – i.e. not on smart-cards/tokens. And another one (not a root CA, but a su

Re: Policy Update Proposal: Remove Code Signing Trust Bit

On 08/10/15 14:27, Peter Kurrasch wrote: > 2. Loss of visibility/consistency/input: If Mozilla decides to exit the > code signing world, the security community loses a place to share > experiences, establish policies, discuss and evaluate bad acts and bad > actors, and so forth I've never seen th

Re: Policy Update Proposal: Remove Code Signing Trust Bit

On 08/10/15 17:20, Peter Bowen wrote: > going forward, so there would be no impact to Mozilla products. That > leaves OpenJDK on Red Hat. It was indicated in an earlier part of > the thread that Red Hat may be basing their trust store on Mozilla’s > trust store. This is the one defined place wher

Re: Policy Update Proposal -- Remove Email Trust Bit

On 13/10/15 19:39, R Kent James wrote: > Obviously have a "resource" implies that there is funding needed to > support this. My understanding is that in many cases, there is a cost to > certificate providers to have their certificates included in a root > store, that is applied to the expense of ma

Re: Symantec Test Cert Misissuance Incident

On 13/10/15 23:58, Michael Colburn wrote: > Symantec's gone and updated [2] and [4] and both of those links are > 404ing now. Updated links: > > [2] > https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf > [4] > https://www-secure.s

Re: Symantec Test Cert Misissuance Incident

On 14/10/15 01:15, Charles Reiss wrote: > As of this writing, there appears to be a functional server at that > www.icns.com.au which presents that (expired and revoked) cert and to which > openssl s_client can successfully connect. > > Is this entry an error? Thank you for doing this investigat

Re: Symantec Test Cert Misissuance Incident

On 14/10/15 13:47, Rob Stradling wrote: > (There are actually 187 rows, but 3 certs are counted twice) And that's not perhaps because one copy is with a CT poison extension, and the other is with an SCT? Gerv ___ dev-security-policy mailing list dev-se

Re: Symantec Test Cert Misissuance Incident

On 15/10/15 10:54, Rob Stradling wrote: > Rick, your report [1] states that... > >"...the certificates never left Symantec's secure test labs or the A charitable reading of this might be "the private keys never left...". But yes, it might help to have more details on what exactly is being cla

Re: Let's Encrypt Root

On 26/10/15 23:46, Richard Barnes wrote: > https://bugzilla.mozilla.org/show_bug.cgi?id=1204656 I'm surprised it's taken LE as long as a month to review whether the info-gathering document has been correctly transcribed... Gerv ___ dev-security-policy

Re: Symantec Test Cert Misissuance Incident

On 29/10/15 13:17, Kurt Roeckx wrote: > I know this is directly copied from their blog about this, but I wonder > what it means for a certificate to support CT. Is the requirement > really that all certificates need to published in CT? That's a good question. I suspect they mean "be published in

Re: Let's Encrypt Root

On 28/10/15 16:37, Kathleen Wilson wrote: > I doubt that's what is taking the time. I suspect they are working on > the audits. But we can include them based on a PITRA, right? And they have that... Gerv ___ dev-security-policy mailing list dev-securit

Re: Clarify that a ccTLD is not acceptable in permittedSubtrees

On 10/11/15 23:44, Ryan Sleevi wrote: > If a CA has issued such a cert to an applicant that they didn't vet as > being the authorized representative of the relevant national > administrator, then that's arguably no different than issuing a cert to > someone who isn't the authorized domain holder -

Re: Policy Update Proposal: Timeline for Disclosing SubCAs

On 19/11/15 23:09, Kathleen Wilson wrote: > “10. … The CA with a certificate included in Mozilla’s CA Certificate > Program MUST disclose this information *in the CA Community in > Salesforce* https://wiki.mozilla.org/CA:SalesforceCommunity> > before any such subordinate CA is allowed to issue cert

Re: New wiki page on certificate revocation plans

On 30/11/15 22:37, Jakob Bohm wrote: > 1.1. Certificates that are used on servers that don't implement > OCSP stapling. No-one is suggesting dropping support for non-stapling web servers. But the revocation options will not be as good. > 1.2. Certificates that are moved from a server software imp

Re: Policy Update Proposal: Timeline for Disclosing SubCAs

On 23/11/15 15:57, Peter Bowen wrote: > I realize that Mozilla carved out allowance for not disclosing, but > the CA/Browser Forum did not adopt this, instead only exempting > technically constrained CAs from the audit requirement. Maybe this is > a place where the Mozilla policy can aligned with

Re: Nation State MITM CA's ?

On 07/01/16 19:15, Peter Bowen wrote: > The information in the bug is incomplete by Mozilla's policy. They > indicate that they plan to get a WebTrust audit but have not done so > at this time. They should be informed that they need both a WebTrust > for CA and a WebTrust for BR audit before the

Re: New requirement: certlint testing

On 16/02/16 04:05, rafa...@gmail.com wrote: >>> Maybe a Mozilla's representative at CAB Forum may supply >>> additional information about it. >> >> Or maybe you may, since you're the one arguing for the exception. > > You'll agree that if this subject has already been notified and > discussed (we

Re: NEW Certificate Manager Add-on

On 12/02/16 14:34, Kathleen Wilson wrote: > Thanks to a group of students at Rose-Hulman Institute of Technology for > creating a Certificate Manager Add-on for their senior project! This is great - well done :-) Gerv ___ dev-security-policy mailing li

Proposed limited exception to SHA-1 issuance

Mozilla and other browsers have been approached by Worldpay, a large payment processor, via Symantec, their CA. They have been transitioning to SHA-2 but due to an oversight have failed to do so in time for a portion of their infrastructure, and failed to renew some SHA-1 server certificates before

Re: Proposed limited exception to SHA-1 issuance

On 24/02/16 02:26, Eric Mill wrote: > It would also be worth learning what segment of the market these 10,000 > terminals would affect. I've seen these terminals before: > > https://www.google.com/search?q=worldpay&espv=2&biw=1168&bih=783&site=webhp&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj91arSqo_LA

Re: Proposed limited exception to SHA-1 issuance

On 24/02/16 02:38, Peter Gutmann wrote: > I'm curious about what's going on here, as you say this is a private PKI, so > why do they need certs from a public CA? Presumably Worldpay is doing this > for B2B comms, so why don't they issue their own certs, and they can keep > using SHA-1 for as long

Re: Proposed limited exception to SHA-1 issuance

On 23/02/16 20:05, Andrew Ayer wrote: > Multiple mistakes were made by Worldpay (using public roots, leaving > the transition to the last minute, and then forgetting to renew before > the sunset) and Symantec (failing to make sure their customer was > prepared). I think it's unreasonable to blame

Re: Proposed limited exception to SHA-1 issuance

On 24/02/16 15:45, Jeremy Rowley wrote: > I think Rob's questions are great and should be answered before deciding. > Many CAs have roots and can issue certs that browsers will simply reject. > There may be a simple way to provide them certs without issuing a ton of > SHA1s that are placed on OneCR

Re: Proposed limited exception to SHA-1 issuance

On 24/02/16 16:03, Eric Mill wrote: > Clearly, Mozilla is making a value judgment that this SHA-1 exception is > more merited than other public and private requests for exceptions. It > doesn't sound like Mozilla is potentially supporting this exception based > on a calculation of economic impact,

Re: Proposed limited exception to SHA-1 issuance

On 24/02/16 19:27, Jeremy Rowley wrote: > I believe the concern is that Worldpay is asking for an exception by saying, > "We've tried 'things' and they didn't work - can we please have a SHA1 > cert?" We don't know what these 'things' they've tried are or whether there > is an alternative. Lots of

Re: Proposed limited exception to SHA-1 issuance

On 23/02/16 18:57, Gervase Markham wrote: > Mozilla and other browsers have been approached by Worldpay, a large > payment processor, via Symantec, their CA. They have been transitioning > to SHA-2 but due to an oversight have failed to do so in time for a > portion of their infrast

Re: Proposed limited exception to SHA-1 issuance

On 27/02/16 23:50, David E. Ross wrote: > According to Softpedia, Mozilla is the only organization that agreed to > Symantec's request. Microsoft, Google, and others are holding firm on > rejecting SHA-1 certificates. See >

Re: Drafting Q1 2016 CA Communication

All this seems fine :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

On 16/05/16 01:13, Kathleen Wilson wrote: > 3) If a website is using its SSL certificate to mask injection of malware and > evidence of that is presented to the issuing CA, is that sufficient misuse > for the CA to be required to revoke the certificate? Counter-question to many of these: who def

Re: CSV Format of CA Program reports

On 17/05/16 00:40, Kathleen Wilson wrote: > So, old intermediate certs like that should not be marked technically > constrained. New intermediate certs that have the SGC EKU and not > id-kp-serverAuthentication will not validate in Firefox 49 or later, > so those may be treated as technically const

Re: SSL Certs for Malicious Websites

On 17/05/16 22:41, Kathleen Wilson wrote: > On Monday, May 16, 2016 at 9:20:56 AM UTC-7, Kathleen Wilson wrote: >> I am wondering if the BRs need to be updated to: >> + Define what is meant by "Certificate misuse, or other types of fraud". >> (e.g. being used for a purpose outside of that containe

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

On 19/05/16 20:26, Peter Kurrasch wrote: > My recommendation is for Mozilla to reject this request from Symantec > on the grounds that it is unnecessary. As others have pointed out > recently, the chief function of a CA is to certify identity. That > certification should be ably met with the regula

Re: SSL Certs for Malicious Websites

On 18/05/16 17:35, Ben Wilson wrote: > Looking at the threat from a defense-in-depth/orthogonal perspective, > doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does > something to combat malicious websites for the public? Not necessarily, if what they do ends up damaging inno

Re: SSL Certs for Malicious Websites

On 19/05/16 00:45, Matt Palmer wrote: > How so? It could be a site providing information from a third party on how > to make and receive payments via PayPal. It could also be a site operated > by a third party on behalf of PayPal. Inferring nefarious intent from a > domain name seems like a real

Re: Job: Is it OK to post a job listing in this forum?

On 27/05/16 04:09, David E. Ross wrote: > I would have several concerns, mostly about Mozilla's ability to verify > the criteria are met and the effort to do that verification. For > example, how would anyone here verify the following? This is partly why there is an important criterion that jobs

Re: [FORGED] Re: SSL Certs for Malicious Websites

On 27/05/16 13:20, Peter Gutmann wrote: > Apart from the lucky CAs who have been given government- > mandated monopolies, would any CA still exist today if there weren't a need to > pay someone to turn off the browser warnings? It depends what alternative configuration-free idiot-proof secure comm

<    1   2   3   4   5   6   7   8   9   10   >