Re: GlobalSign Request to Include ECC Roots

OK, let's dive into the CPS dissection game... On Tue, Jul 29, 2014 at 03:26:08PM -0700, Kathleen Wilson wrote: ** CPS section 3.2.2.3, Extended Validation Certificates (SSL and Code Signing): For Extended Validation Certificates, the EV Guidelines are followed. I'm new to this, so perhaps

Re: Dynamic Path Resolution in AIA CA Issuers

On Wed, Jul 30, 2014 at 12:17:27PM -0700, Kathleen Wilson wrote: On 7/28/14, 11:00 AM, Brian Smith wrote: I suggest that, instead of including the cross-signing certificates in the NSS certificate database, the mozilla::pkix code should be changed to look up those certificates when attempting

Re: Proposal: Switch generic icon to negative feedback for non-https sites

On Sat, Aug 09, 2014 at 04:53:46PM -0700, David E. Ross wrote: Anyone wishing to argue this issue further -- to argue in favor of implementing a scheme to encourage all Web sites to be HTTPS with site certificates -- should first read

Re: Proposal: Switch generic icon to negative feedback for non-https sites

On Sun, Aug 10, 2014 at 08:16:42PM -0700, David E. Ross wrote: On 8/10/2014 4:09 PM, Matt Palmer wrote: On Sat, Aug 09, 2014 at 04:53:46PM -0700, David E. Ross wrote: Anyone wishing to argue this issue further -- to argue in favor of implementing a scheme to encourage all Web sites

Re: Allow Redaction of issues detailed in BR Audit statements?

Hi Kathleen, My take on this is that any information that is relevant to a CA's conformance (or lack thereof) with the BRs (or any other part of Mozilla's inclusion criteria) needs to be disclosed to those who are passing judgment on the suitability of the CA for inclusion in the Mozilla trust

Re: Allow Redaction of issues detailed in BR Audit statements?

On Thu, Aug 28, 2014 at 09:42:13AM +0800, Man Ho (Certizen) wrote: Concerning about a list of BRs that the CA is still working to conform with, I don't think CAs will agree to publish in public for security reason and also because of business sensitivity. I think some CAs don't even want to

Re: Allow Redaction of issues detailed in BR Audit statements?

On Thu, Aug 28, 2014 at 02:40:08PM +0800, Man Ho (Certizen) wrote: On 8/28/2014 9:42 AM, Man Ho (Certizen) wrote: I think some CAs don't even want to claim they are CAB/Forum BR compliant, but just want to be included in all root certificate programs. What I mean is that some CAs don't

Re: Indicators for high-security features

On Tue, Sep 23, 2014 at 01:08:13PM -0500, fhw...@gmail.com wrote: So what is the reason to use HSTS over a server initiated redirect? Seems to me the latter would provide greater security whereas the former is easy to bypass.  On the contrary, HSTS is much harder to bypass, because the browser

Re: KIR S.A. Root Inclusion Request

One thing leaps out at me immediately: these test certificates. They appear to be issued from the same CA as the regular certificates, but s3.2 states, In case of test certificates they may be issued remotely *without the necessity to verify the subscriber's identity. That seems... bad.

Re: KIR S.A. Root Inclusion Request

On Fri, Sep 26, 2014 at 02:42:05PM +0200, Certificates wrote: I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). KIR's answer: To get a SSL certificate client has to provide(CSP s.3.2): That's

Re: ODP: Re: KIR S.A. Root Inclusion Request

On Mon, Sep 29, 2014 at 03:41:07PM +0200, Certificates wrote: On Fri, Sep 26, 2014 at 02:42:05PM +0200, Certificates wrote: -agreement, -order, -document confirming rights to the domain . What valid forms can this document take? What steps are taken to verify or validate that

Re: ODP: Re: ODP: Re: KIR S.A. Root Inclusion Request

On Tue, Sep 30, 2014 at 01:17:22PM +0200, Certificates wrote: We are able to add some additional information to our CPS. In our opinion they should be more general than those in our explanations sent to you. More detailed information are placed in our internal procedures, which are checked

Re: Cert spam, or certs with huge numbers of hosts.

On Thu, Oct 23, 2014 at 01:08:25PM -0700, John Nagle wrote: Examine the cert of https://www.sevendays.co;. Here's one of those certs with a huge number of unrelated hosts. This seems to be a Cloudflare legacy setup from the pre-TLS era. Unfortunately, this cert became valid on 10/09/2014.

Re: Cert spam, or certs with huge numbers of hosts.

On Thu, Oct 23, 2014 at 02:30:59PM -0700, John Nagle wrote: On 10/23/2014 02:00 PM, Richard Barnes wrote: You're probably right. What Cloudflare provides by default is Flexible SSL, in which Cloudflare acts as a MITM: Cloudflare acts as a MITM for *all* SSL modes -- because it needs to see

Re: multi-SAN certificates [was: dev-security-policy Digest, Vol 70, Issue 19]

On Sat, Oct 25, 2014 at 12:11:15PM -0700, John Nagle wrote: The popup Firefox gives when the user clicks on the lock icon expresses more confidence than the cert indicates. It says that you are securely connected to [destination domain name]. There's no mention of the fact that the cert

Re: New free TLS CA coming

On Thu, Nov 20, 2014 at 08:27:37PM +1300, Peter Gutmann wrote: Mark Atwood m...@mark.atwood.name writes: On Tue, Nov 18, 2014, at 11:25, Salz, Rich wrote: Initial drop of code and specs available here: https://github.com/letsencrypt From

Re: Certinomis Request to Include Renewed Root

On Thu, Dec 18, 2014 at 04:18:27PM -0800, Kathleen Wilson wrote: Certinomis is a commercial CA serving a global client base, active [...] * The primary documents are in French. Some sections have been translated into English and attached to the bug. While the sections translated into English

Re: Censorship implications of mandatory centralized add-on signing

On Fri, Feb 13, 2015 at 09:54:25AM +0100, Kurt Roeckx wrote: On 2015-02-13 01:14, Botond Ballo wrote: One concern which I don't feel has been sufficiently emphasized, is the way in which this proposal would make our users vulnerable to censorship. What I've been wondering is who can sign?

Re: Question about BR Commitment to Comply

Hi Kathleen, On Wed, Jan 28, 2015 at 02:49:22PM -0800, Kathleen Wilson wrote: https://wiki.mozilla.org/CA:BaselineRequirements Currently says: The CA's CP or CPS documents must include a commitment to comply with the BRs, as described in BR section 8.3. I have been asked if a CA can have

Re: Propose Removal of E-Guven root

On Wed, Mar 18, 2015 at 12:40:11PM -0700, Kathleen Wilson wrote: I propose removing the following root cert from NSS, due to inadequate audit statements. If they can't follow the rules, they need to go. - Matt ___ dev-security-policy mailing list

Re: LuxTrust Root Inclusion Request

On Thu, Mar 19, 2015 at 09:35:20AM +0100, LuxTrust CA wrote: Regarding issue #2 : OCSP responds good to a non-issued certificate (serials and 00) (BR Section 13.2.6) : LuxTrust’s OCSP application currently does not support this feature (technical

Re: Consequences of mis-issuance under CNNIC

On Mon, Mar 30, 2015 at 11:34:40AM -0400, Richard Barnes wrote: The underlying issue here is that CNNIC, apparently deliberately, violated the BRs, Mozilla policy, and its own CPS by issuing an intermediate without proper vetting. For me, the most troubling aspect of this is that CNNIC

Re: 答复: 答复: Consequences of mis-issuance under CNNIC

On Fri, Mar 27, 2015 at 02:41:03PM +0800, Man Ho (Certizen) wrote: On 3/27/2015 1:29 AM, Charles Reiss wrote: Although it's rather irrelevant to whether CNNIC has complied with Mozilla's policies: This device designed to issue certs without verifying domain control. Does CNNIC not

Re: Consequences of mis-issuance under CNNIC

On Fri, Mar 27, 2015 at 02:09:41PM -0500, Peter Kurrasch wrote: Perhaps there is a middle ground of remedies. For consideration: 1) Mozilla could refuse to validate any intermediate cert which CNNIC has issued to a subordinate CA. (Note: I'm not sure that's the technically precise term

Re: 答复: 答复: Consequences of mis-issuance under CNNIC

On Thu, Mar 26, 2015 at 05:02:16PM +0800, Anyin wrote: We apply Mozilla do not remove CNNIC root from trust store as this is absolutely not a intension mis-issuance. That it was accidental is, in some ways, *worse*. Intentional mis-issuance would mean that someone worked to subvert the

Re: address prefixes allowed for domain control validation

On Mon, Mar 23, 2015 at 09:40:08AM +0100, Kurt Roeckx wrote: On 2015-03-23 00:18, Kathleen Wilson wrote: admin@domain administrator@domain I've seen a few stories like this. I think they all used either admin or administrator. So I recommend not to allow those. They also don't

Re: Consequences of mis-issuance under CNNIC

On Wed, Apr 01, 2015 at 10:06:53PM -0700, Reed Loden wrote: CNNIC just released a declaration concerning Google's recent update: http://www1.cnnic.cn/AU/MediaC/Announcement/201504/t20150402_52049.htm 1. The decision that Google has made is unacceptable and unintelligible to CNNIC, and

Re: Consequences of mis-issuance under CNNIC

On Thu, Apr 02, 2015 at 09:18:05AM +0100, Gervase Markham wrote: On 01/04/15 23:44, Matt Palmer wrote: 1) If they refuse to provide a list of currently issued certificates; I think this is unlikely, particularly as Google have decided to require CNNIC to agree to CT for all certificates

Re: Requirements for CNNIC re-application

On Mon, Apr 13, 2015 at 06:15:52PM -0500, Peter Kurrasch wrote: Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What happens next?  Where I'm going with this is

Re: Name-constraining government CAs, or not

Everything that Ryan says below, is what I would have said if I were as eloquent. - Matt On Fri, May 15, 2015 at 11:49:39AM -0700, Ryan Sleevi wrote: On Fri, May 15, 2015 1:52 am, Gervase Markham wrote: On 15/05/15 00:01, Ryan Sleevi wrote: I think there's also the broader consideration

Re: Name-constraining government CAs, or not

On Mon, May 18, 2015 at 10:32:05PM -0400, Eric Mill wrote: On Mon, May 18, 2015 at 9:15 PM, Matt Palmer mpal...@hezmatt.org 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

Re: Name-constraining government CAs, or not

On Mon, May 18, 2015 at 02:45:26PM +0100, Gervase Markham wrote: On 17/05/15 23:28, Peter Bowen wrote: This would seem to be a fairly simple rule. Indeed. However, this has not addressed my question about whether the security analysis for government CAs is different to that of commercial

Re: Name-constraining government CAs, or not

On Mon, May 18, 2015 at 12:26:26PM +0200, Kurt Roeckx wrote: On 2015-05-14 17:25, Gervase Markham wrote: 2) If it is different, does name-constraining government CAs make things better, or not? I think it only makes sense to name constrain a government CA if the name constrained only covers

Re: Requirements for CNNIC re-application

On Tue, Apr 14, 2015 at 01:38:55PM +0200, Kurt Roeckx wrote: On 2015-04-14 01:15, Peter Kurrasch wrote: Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What

Re: Consequences of mis-issuance under CNNIC

On Wed, Apr 01, 2015 at 01:35:25PM -0400, Richard Barnes wrote: Alright, one more pass at this. After more feedback from this list (thanks, all!) and some more conversation, I would like to propose something stronger than my last proposal: * Do not remove the CNNIC root, but * Reject

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

Hi Richard, On Thu, Jun 04, 2015 at 02:44:00PM -0400, Richard Barnes wrote: The thing that was driving my earlier proposal with regard to name constraints was a feeling of imbalance. With every CA we add to our program we add risk for every site on the web. That cost is supposed to be

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

On Tue, Jun 09, 2015 at 12:00:23PM -0700, Rick Andrews wrote: On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote: On 2015-06-09 15:26, Peter Kurrasch wrote: 3) How frequently might such tools run? Or to put it differently, how much time do I probably have between when I

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

On Tue, Jun 09, 2015 at 08:26:55AM -0500, Peter Kurrasch wrote: 1) How to exclude domains from the search? For example I want to find gmail certs but exclude something like eggmail which could be a false positive. Constrain your search to domains which have a name part which is exactly

Re: Requirements for CNNIC re-application

On Tue, May 26, 2015 at 02:26:33PM -0700, 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

Re: Symantec Test Cert Misissuance Incident

On Thu, Oct 29, 2015 at 02:17:35PM +0100, Kurt Roeckx wrote: > On 2015-10-28 22:30, Kathleen Wilson wrote: > >According to the article, here is what Google is requiring of Symantec: > > > >1) as of June 1st, 2016, all certificates issued by Symantec itself will > >be required to support

Re: Policy Update Proposal: Remove Code Signing Trust Bit

On Thu, Sep 10, 2015 at 05:54:22PM -0500, Peter Kurrasch wrote: >It should be understood that code signing is very important in the >embedded space--just ask Tesla or Jeep/Chrysler or Nest or other IoT >product developers. If we accept that premise, the question immediately >

Re: Policy Update Proposal: Remove Code Signing Trust Bit

On Fri, Sep 11, 2015 at 06:56:49AM +0300, Moudrick M. Dadashov wrote: > On 9/11/2015 3:23 AM, Peter Bowen wrote: > >On Thu, Sep 10, 2015 at 3:54 PM, Peter Kurrasch wrote: > >>It should be understood that code signing is very important in the > >>embedded space--just ask Tesla or

Re: New wiki page on certificate revocation plans

On Thu, Dec 03, 2015 at 07:32:43PM +0100, Jakob Bohm wrote: > On 03/12/2015 11:25, Gervase Markham wrote: > >On 30/11/15 22:37, Jakob Bohm wrote: > >>1.2. Certificates that are moved from a server software implementation > >>that does do OCSP stapling to another that doesn't. In particular, >

Re: Policy Update Proposal: Require full CP/CPS in English

On Thu, Nov 19, 2015 at 05:00:03PM -0800, Kathleen Wilson wrote: > Insert 3rd bullet point: > "- translate into English the Certificate Policy and Certification Practice > Statement documents pertaining to the certificates to be included and the > trust bits to be enabled;" > > I will appreciate

Re: New requirement: certlint testing

On Mon, Feb 08, 2016 at 12:42:46PM -0800, Kathleen Wilson wrote: > One topic currently under discussion in Bug #1201423 is regarding root > certificates with serial number of 0. The error being returned by > http://cert-checker.allizom.org/ is "Serial number must be positive". > > Arguments

Re: Re: Proposed limited exception to SHA-1 issuance

On Fri, Feb 26, 2016 at 08:32:34AM -0800, douglas.beat...@gmail.com wrote: > I hope the same courtesy is afforded to other high profile customers and > their CA should the need arise. Why should a requestor's profile come into it? Because they're in a better position to make trouble if their

Re: A-Trust Root Renewal Request

On Sun, Feb 28, 2016 at 10:40:36PM -0800, theltal...@hotmail.com wrote: > Am Sonntag, 28. Februar 2016 00:31:48 UTC+1 schrieb Matt Palmer: > > On Fri, Feb 26, 2016 at 06:22:22AM -0800, Christoph Klein wrote: > > > To prevent future problems with values in the certfica

Re: New requirement: certlint testing

On Fri, Feb 12, 2016 at 02:00:26AM -0800, rafa...@gmail.com wrote: > Regarding this point, how will be addressed the issue about > AdministrativeID (directoryName) in SAN of electronic offices? > > As it has been said, all Spanishs CAs are issuing certs in this way in > order to comply with all

Re: More SHA-1 certs

On Fri, Mar 04, 2016 at 09:19:36PM +, Rob Stradling wrote: > Maybe we need to take a different approach that ignores the end-entity > certificate profile completely. How about we propose that... > > - An X.509 certificate is in scope for the BRs if it's signed by an > Issuing CA that is in

Re: Undisclosed CA certificates

On Fri, Apr 29, 2016 at 12:42:28AM -0700, Nick Lamb wrote: > There is an absolutely objective test, but it is negative. If anyone can > predict N-bits of your next serial number then those N-bits were by > definition predictable. To give a concrete example if you issued with 16 > digit serial

Re: Undisclosed CA certificates

On Fri, Apr 29, 2016 at 05:12:28PM -0700, Peter Bowen wrote: > On Fri, Apr 29, 2016 at 5:03 PM, Matt Palmer <mpal...@hezmatt.org> wrote: > > On Fri, Apr 29, 2016 at 12:42:28AM -0700, Nick Lamb wrote: > >> There is an absolutely objective test, but it is negative. If anyone

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

On Thu, May 19, 2016 at 02:26:15PM -0500, 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

Re: SSL Certs for Malicious Websites

Well said, Andrew. You've summarised the issue excellently. - Matt On Thu, May 19, 2016 at 03:19:13PM -0700, Andrew Ayer wrote: > Kathleen, > > I believe that certificate authorities should be content-neutral. They > should not be required to assess "misuse" or "fraud," nor be required > to

Re: SSL Certs for Malicious Websites

On Wed, May 18, 2016 at 03:16:59PM +0100, Gervase Markham wrote: > > What is meant by "fraudulent use"? > > I think the bullet as a whole could mean that we reserve the right to > not include CAs who happily issue certs to "www.paypalpayments.com" to > just anyone without any checks or High Risk

Re: SSL Certs for Malicious Websites

On Wed, May 18, 2016 at 04:35:49PM +, 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? Because the next steps after

Re: SSL Certs for Malicious Websites

On Tue, May 17, 2016 at 11:14:21PM +0200, Richard Z wrote: > There are crime friendly providers already and having crime friendly CAs is > something that users would definitely notice. Why? Do users typically notice the crime friendly hosting providers? - Matt

Re: SSL Certs for Malicious Websites

On Mon, May 16, 2016 at 09:20:40AM -0700, Kathleen Wilson wrote: > In regards to Mozilla policy, maybe we should consider adding text about > Mozilla's expectations for CAs when they find out that a TLS/SSL > certificate that they issued is being used to do bad things. Mozilla should expect that

Re: SSL Certs for Malicious Websites

On Mon, May 16, 2016 at 02:22:08PM +0200, Richard Z wrote: > On Sun, May 15, 2016 at 05:43:39PM -0700, Peter Bowen wrote: > > > Some CAs may choose to not issue to sites known to inject malware, but > > this outside the scope of the SSL requirements. The EV Guidelines it > > very clear that the

Re: SHA-1 Client SSL Certificates phase out ?

On Tue, Apr 19, 2016 at 12:08:21PM -0700, martin.pal...@gmail.com wrote: > On Friday, 15 April 2016 20:26:39 UTC+3, Richard Barnes wrote: > > Do you mean SHA-1 for client certificates? For those, the browser isn't > > the relying party; it would be up to the website to decide whether a SHA-1 > >

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

On Wed, Apr 20, 2016 at 06:48:14AM -0700, Ryan Sleevi wrote: > In either event, the only objection to clarifying this ambiguity in the > Forum was raised by Symantec, and as such, a ballot to correct this > confusion has remained stalled. It seems fairly dysfunctional if a single member of the

Re: Certificate Incident

On Thu, Jul 14, 2016 at 02:52:41AM -0700, Nick Lamb wrote: > On Thursday, 14 July 2016 05:18:20 UTC+1, Andrew Ayer wrote: > > Revocation does not address the risk that this mis-issuance has caused > > to the ecosystem, since collided certificates (the ones we cannot see, > > and need to be

Re: StartEncrypt considered harmful today

On Thu, Jun 30, 2016 at 11:10:45AM -0500, Peter Kurrasch wrote: > Very interesting. This is exactly the sort of thing I'm concerned about > with respect to Let's Encrypt and ACME. Why? StartCom isn't the first CA to have had quite glaring holes in its automated DCV interface and code, and I'm

Re: Hongkong Post recently issued SHA1 cert that could be used in TLS

On Tue, Aug 16, 2016 at 10:22:36PM -0700, ma...@certizen.com wrote: > and have been issuing SHA-256 SSL certificates under "Hongkong Post e-Cert > CA 1- 14" and "Hongkong Post e-Cert CA 1 - 15" respectively "respectively" in what sense? > This certificate is a client certificate issued to a

Re: Policy 2.4 Proposal: Require full CP/CPS in English

In general, I'm in strong agreement with this change, for all the reasons described. One nit to pick with the proposed draft text: On Tue, Jan 24, 2017 at 03:02:45PM +, Gervase Markham wrote: > So the draft text might be something like: > > "CAs must provide English versions of all

Re: Incidents involving the CA WoSign

On Thu, Aug 25, 2016 at 04:03:04AM +, Richard Wang wrote: > For transparency, WoSign announced full transparency for all SSL > certificate from July 5th that post all issued SSL certificate to Google > log server, browsers can distrust WoSign issued SSL certificate after that > day if no SCT

Re: Reuse of serial numbers by StartCom

On Wed, Aug 31, 2016 at 07:57:02PM +0300, Eddy Nigg wrote: > On 08/31/2016 03:19 PM, Matt Palmer wrote: > >That bug appears to pre-date *all* of the certificates listed above. > >Further, the last communication on that bug (2014-09-22), from Eddy Nigg > >(of StartCom),

Re: Sanctions short of distrust

On Fri, Sep 02, 2016 at 11:19:11AM +0100, Gervase Markham wrote: > On 31/08/16 20:43, Nick Lamb wrote: > > This suggests the need for some options short of distrust which can > > be deployed instead, but Mozilla does not seem to have any. If in > > fact it already does, this would be a great place

Re: Incidents involving the CA WoSign

On Fri, Sep 02, 2016 at 10:27:04AM +, Richard Wang wrote: > (2) What I mean is please think about the current users if any action; 10% > from government website, 6 customers is the top 10 eCommerce website in > China; I'm reminded of a line from an old episode of a rather crass TV show, which

Re: Incidents involving the CA WoSign

On Fri, Sep 02, 2016 at 09:01:47AM +, Richard Wang wrote: > You mean if a Chinese, a Chinese company own a USA CA, then the USA CA become > un-trustworthiness? If the Chinese company or US CA are making legal threats to try and suppress disclosure of the ownership, and the Chinese company is

Re: Sanctions short of distrust

On Fri, Sep 02, 2016 at 03:48:13PM -0700, John Nagle wrote: > On 09/02/2016 01:04 PM, Patrick Figel wrote: > >On 02/09/16 21:14, John Nagle wrote: > >>2. For certs under this root cert, always check CA's certificate > >>transparency server. Fail if not found. > > > >To my knowledge, CT does not

Re: Sanctions short of distrust

On Sat, Sep 03, 2016 at 01:45:48AM +0200, Patrick Figel wrote: > On 03/09/16 01:15, Matt Palmer wrote: > > On Fri, Sep 02, 2016 at 03:48:13PM -0700, John Nagle wrote: > >> On 09/02/2016 01:04 PM, Patrick Figel wrote: > >>> On 02/09/16 21:14, John Nagle wrote: >

Re: Incidents involving the CA WoSign

On Fri, Sep 02, 2016 at 07:55:36AM -0700, Peter Bowen wrote: > Do you also plan to submit these to at least one Google-operated log? Did you mean "non-Google-operated log"? I was under the impression that we didn't want everything being stuffed into just Google logs. - Matt -- I really didn't

Re: Incidents involving the CA WoSign

On Sat, Sep 03, 2016 at 01:31:39AM +0200, Kurt Roeckx wrote: > On Sat, Sep 03, 2016 at 09:24:33AM +1000, Matt Palmer wrote: > > On Fri, Sep 02, 2016 at 07:55:36AM -0700, Peter Bowen wrote: > > > Do you also plan to submit these to at least one Google-operated log? > > >

Re: StartCom's StartPKI

On Sat, Sep 03, 2016 at 01:26:51PM -0700, Percy wrote: > 1.WoSign actively mislead users in marketing emails. As much as the inaccuracies and misleading statements in WoSign's marketing materials rub me the wrong way, too, if we were to start pulling the roots of CAs for lying in their marketing,

Re: Incidents involving the CA WoSign

On Sat, Sep 03, 2016 at 02:18:44PM -0700, Peter Bowen wrote: > Can you also please check the following two certificates? It looks > like they were missed when logging all the 2015 certs. > > https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2 >

Re: StartCom's StartPKI

On Sat, Sep 03, 2016 at 10:54:26PM +0200, Kurt Roeckx wrote: > I see no problem with StartCom or WoSign being owned by the same > person. I didn't, either, until they started throwing around legal threats to bury the fact that there was common ownership, and trying to use threats against the

Re: Hongkong Post recently issued SHA1 cert that could be used in TLS

On Thu, Sep 01, 2016 at 10:14:01AM +0800, Man Ho (Certizen) wrote: > What about our existing SSL server certs, which are still valid until 31 > Dec 2016? Majority of those cert. subscribers are offering government > and public services to residents of Hong Kong. You might want to let them know

Re: Hongkong Post recently issued SHA1 cert that could be used in TLS

On Thu, Sep 01, 2016 at 07:48:23PM +0800, Man Ho (Certizen) wrote: > > On 9/1/2016 6:13 PM, Matt Palmer wrote: > > You might want to let them know it's time to get new certs. > > > > - Matt > We did inform all subscribers back in October 2014 that SHA-1 SSL serve

Re: Incidents involving the CA WoSign

On Fri, Sep 02, 2016 at 06:53:23AM +, Richard Wang wrote: > I think we are out of topic. On the contrary, the trustworthiness of CAs is *entirely* on topic. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Incidents involving the CA WoSign

On Fri, Sep 02, 2016 at 05:59:19AM +, Richard Wang wrote: > 1. Eddy told me that this guy is the former employee of StartCom, he > violates the signed NDA that he must shutdown the site within the limit > time. Every re-distribution the wrong information will heavy his penalty > (including

Re: Reuse of serial numbers by StartCom

On Wed, Aug 31, 2016 at 09:29:20AM +0200, Kurt Roeckx wrote: > On 2016-08-31 04:56, Peter Bowen wrote: > >In reviewing the Certificate Transparency logs, I noticed the StartCom > >has issued multiple certificates with identical serial numbers and > >identical issuer names. > > >

Re: Sanctions short of distrust

On Thu, Sep 08, 2016 at 09:44:04AM -0700, Ryan Sleevi wrote: > On Thursday, September 8, 2016 at 4:09:25 AM UTC-7, Rob Stradling wrote: > > > 1. Enforce CT only after a certain date, after which WoSign will need > > > to embed qualified SCTs. This check can be bypassed if the CA > > >

Re: Cerificate Concern about Cloudflare's DNS

On Tue, Sep 13, 2016 at 07:04:31AM -0700, Han Yuwei wrote: > 在 2016年9月13日星期二 UTC+8下午7:12:22，Matt Palmer写道： > > On Mon, Sep 12, 2016 at 08:38:00PM -0700, Han Yuwei wrote: > > > 在 2016年9月13日星期二 UTC+8上午8:07:31，Matt Palmer写道： > > > I am the owner of BUPT.MOE

Re: Cerificate Concern about Cloudflare's DNS

On Mon, Sep 12, 2016 at 08:57:29PM +0100, Rob Stradling wrote: > On 12/09/16 18:57, Jakob Bohm wrote: > > On 11/09/2016 07:49, Peter Bowen wrote: > >> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei wrote: > >>> So when I delegated the DNS service to Cloudflare, Cloudflare have

Re: Cerificate Concern about Cloudflare's DNS

On Mon, Sep 12, 2016 at 08:38:00PM -0700, Han Yuwei wrote: > 在 2016年9月13日星期二 UTC+8上午8:07:31，Matt Palmer写道： > > If Cloudflare *was*, in fact, obtaining certificates on behalf of all its > > DNS-using (only) customers on the "off chance" that they might want to use

Re: Cerificate Concern about Cloudflare's DNS

On Sat, Sep 10, 2016 at 06:33:59PM -0700, xiaoyi...@outlook.com wrote: > But is it a OK behavior if a CDN vendor doesn't immediately revoke the old > cert after I stop using its CDN service? I don't think it's automatically terrible behaviour. Plenty of people let certificates lapse rather than

Re: Sanctions short of distrust

On Fri, Sep 09, 2016 at 12:41:31PM +0100, Rob Stradling wrote: > For CAs that are on (borrowing Matt's wording) "quintuple secret > probation" due to a "history of shenanigans with notBefore dates", > browsers could require that: > 1. The certificate MUST be "CT qualified" via SCTs embedded in

Re: WoSign’s Ownership of StartCom

Hi Gerv, On Fri, Sep 09, 2016 at 10:48:26AM +0100, Gervase Markham wrote: > We have been actively investigating reports that WoSign and StartCom may > have failed to comply with our policy on change of control notification. > Below is a summary representing the best of our knowledge and belief, >

Re: Sanctions short of distrust

On Fri, Sep 09, 2016 at 10:25:43AM -0700, Ryan Sleevi wrote: > On Friday, September 9, 2016 at 4:42:12 AM UTC-7, Rob Stradling wrote: > > That's a good point. So, to fix my proposal... > > > > For CAs that are on (borrowing Matt's wording) "quintuple secret > > probation" due to a "history of

Re: Cerificate Concern about Cloudflare's DNS

On Sat, Sep 17, 2016 at 04:38:50PM +0200, Florian Weimer wrote: > * Peter Bowen: > > > On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei wrote: > >> So when I delegated the DNS service to Cloudflare, Cloudflare have > >> the privilege to issue the certificate by default? Can I

Re: Hongkong Post recently issued SHA1 cert that could be used in TLS

On Wed, Aug 17, 2016 at 10:22:13AM +0200, Kurt Roeckx wrote: > On 2016-08-17 00:23, Ryan Sleevi wrote: > >Practically speaking, what steps could be taken? > > 6) Ask them to immediately stop issuing SHA-1 based certificates that chain > back to any of the root certificates in the Mozilla root

Re: Incidents involving the CA WoSign

On Thu, Aug 25, 2016 at 05:15:58PM -0700, Ryan Sleevi wrote: > On Thursday, August 25, 2016 at 4:35:39 PM UTC-7, Matt Palmer wrote: > > I'm after the specifics of the changes to WoSign's policies and procedures > > regarding *notification*, not quality control. What were Wo

Re: Incidents involving the CA WoSign

On Thu, Aug 25, 2016 at 07:11:18AM +, Richard Wang wrote: > We can post all 2015 issued SSL certificate to CT log server if necessary. That doesn't provide any assurance, in the face of misleading notBefore values in certificates. Without strong assurances that whatever failure of systems or

Re: WoSign: updated report and discussion

On Mon, Oct 10, 2016 at 10:33:15AM -0700, Nick Lamb wrote: > Would anybody here _seriously_ be shocked to read next month that a black > hat group is auctioning some StartCom private keys ? On the evidence > available we have to assume that the keys underpinning both WoSign and > StartCom may

Re: StartCom & Qihoo Incidents

On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote: > Perhaps not. However, Qihoo 360's behavior calls the trustworthiness of the > entire company into question. And such trust, in my view, should be > evaluated when WoSign/StartCom submit their re-inclusion requests in the > future. You can

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 06:00:24AM -0800, Peter Bowen wrote: > into what is issued for their domain names. If domain holders want to > keep their certificates semi-private, then they need to be aware that > security is a moving target and their input on data-driven decisions > may be diminished.

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 11:46:28AM +, Gervase Markham wrote: > CT is getting to be very useful as a way of surveying the certificate > ecosystem. This is helpful to assess the impact of proposed policy > changes or positions, e.g. "how many certs don't have an EKU", or "how > many certs use a

Re: Technically Constrained Sub-CAs

On Thu, Nov 17, 2016 at 04:55:37PM -0800, Peter Bowen wrote: > On Thu, Nov 17, 2016 at 4:38 PM, Matt Palmer <mpal...@hezmatt.org> wrote: > >> (Note: Key pinning isn't the only advantage to being able to freely operate > >> your own intermediate CA.) > > > >

Re: Technically Constrained Sub-CAs

On Thu, Nov 17, 2016 at 02:10:58PM -1000, Brian Smith wrote: > Nick Lamb wrote: > > There's a recurring pattern in most of the examples. A technical > > counter-measure would be possible, therefore you suppose it's OK to > > screw-up and the counter-measure saves us. > >

Re: Technically Constrained Sub-CAs

On Tue, Nov 15, 2016 at 04:27:09PM +0100, Gervase Markham wrote: > I certainly think our view of redaction will be driven by use cases. > AIUI, you are strongly encouraging use cases to be brought to the IETF. > However, if 6962bis is in Last Call, and won't be updated, is the TRANS > group still

  1   2   3   4   >