Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

On Fri, 12 Mar 2021 04:57:56 -0800 (PST) Pablo D__az via dev-security-policy wrote: > [...] > > I completely agree that "Human error" is not an acceptable analysis, > and "training improvement" is not the optimal solution. We have > worked to apply as many automatic controls as possible to

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

On Wed, 10 Mar 2021 13:43:55 -0700 Ben Wilson via dev-security-policy wrote: > This is to announce the beginning of the public discussion phase of > the Mozilla root CA inclusion process for the ANF Secure Server Root > CA. I'd like to draw attention to the first misissuance mentioned in

The CAA DNS Operator Exception Is Problematic

The BRs permit CAs to bypass CAA checking for a domain if "the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS." Much like the forbidden "any other method" of domain validation, the DNS operator exception is perilously under-specified. It doesn't say

Re: Mozilla's Response to Camerfirma's Compliance Issues

On Mon, 25 Jan 2021 22:21:31 -0700 Ben Wilson via dev-security-policy wrote: > Camerfirma has responded to the list of issues by providing a Remediation > Plan, > https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing, > with a commitment to align Camerfirma to the

Re: Summary of Camerfirma's Compliance Issues

On Sun, 17 Jan 2021 00:51:29 -0800 (PST) Ramiro Mu__oz via dev-security-policy wrote: > Some certificates may have been syntactically > incorrect due to misinterpretation, but we have never compromised any > vetting, identification or information validation. This is false, as shown by incidents

Re: Digicert issued certificate with let's encrypts public key

On Sat, 16 May 2020 14:02:42 +0200 Kurt Roeckx via dev-security-policy wrote: > https://crt.sh/?id=1902422627 > > It's a certificate for api.pillowz.kz with the public key of Let's > Encrypt Authority X1 and X3 CAs. > > It's revoked since 2020-01-31, but I couldn't find any incident > report

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

Like others, I am concerned with the lack of transparency around this proposal. Many of the options under consideration would be a departure from Mozilla's no exceptions policy, which could have serious consequences that undermine trust in Mozilla's root program. This ought to require compelling

Re: About upcoming limits on trusted certificates

On Wed, 11 Mar 2020 15:39:34 -0700 Kathleen Wilson via dev-security-policy wrote: > What do you all think about also limiting the re-use of domain > validation? I'm strongly in favor of this change, and think domain validation reuse should eventually be limited to a period much shorter than one

Re: DigiCert OCSP services returns 1 byte

On Fri, 13 Sep 2019 08:22:21 + Rob Stradling via dev-security-policy wrote: > Thinking aloud... > Does anything need to be clarified in 6962-bis though? Yes, it's long past time that we clarified what this means: "This signature indicates the CA's intent to issue the certificate. This

Re: DigiCert OCSP services returns 1 byte

Hi Wayne, > > This means, for example, that (i) a CA must provide OCSP services and > > responses in accordance with Mozilla policy for all Precertificates as if > > the corresponding certificate exists, and (ii) a CA must be able to revoke > > a Precertificate if revocation of the certificate is

Re: Disclosure and CP/CPS for Cross-Signed Roots

On Wed, 24 Jul 2019 16:41:53 + Rob Stradling via dev-security-policy wrote: > [Wearing crt.sh hat] > > https://crt.sh/mozilla-disclosures now has two new buckets: > - Disclosed, but with Inconsistent Audit details > - Disclosed, but with Inconsistent CP/CPS details > > (I started

Re: Disclosure and CP/CPS for Cross-Signed Roots

On Thu, 18 Jul 2019 11:40:31 -0700 Wayne Thayer via dev-security-policy wrote: > Andrew Ayer filed two bugs yesterday [1] [2] that might be worthy of > a bit of discussion. There's a third bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1567062 Like the GoDaddy case, the interm

Re: Certinomis Issues

I would like to highlight the many examples of Certinomis' poor incident response. Sometimes Certinomis ignores problems entirely - for example, in , a misissued certificate is still unrevoked and unacknowledged three months after being

Re: Reported Digicert key compromise but not revoked

On Thu, 9 May 2019 14:47:05 + Jeremy Rowley via dev-security-policy wrote: > Hi Han - the proper alias is rev...@digicert.com. The support alias > will sometimes handle these, but not always. Is that also true of SSL certificates? supp...@digicert.com is listed first at

Re: Unretrievable CPS documents listed in CCADB

On Thu, 2 May 2019 18:53:39 -0700 (PDT) Corey Bonnell via dev-security-policy wrote: > As an aside, I noticed that several URLs listed in CCADB are “Legal > Repository” web page URLs that contain a list of many CP/CPS > documents. My recommendation is to slightly amend CCADB Policy to > require

Re: Survey of (potentially noncompliant) Serial Number Lengths

On Mon, 25 Mar 2019 22:16:27 + Rob Stradling via dev-security-policy wrote: > Even better than that (and many thanks to Andrew Ayer for suggesting > this idea)... > > To enable folks to do more thorough statistical analysis, I've > produced another, richer summa

Re: Applicability of SHA-1 Policy to Timestamping CAs

On Fri, 22 Mar 2019 12:50:43 -0600 Wayne Thayer via dev-security-policy wrote: > I've been asked if the section 5.1.1 restrictions on SHA-1 issuance > apply to timestamping CAs. Specifically, does Mozilla policy apply to > the issuance of a SHA-1 CA certificate asserting only the > timestamping

Re: DRAFT November 2017 CA Communication

Hi Kathleen, I suggest being explicit about which CAA errata Mozilla allows. For CNAME, it's erratum 5065. For DNAME, it's erratum 5097. Link to errata: https://www.rfc-editor.org/errata_search.php?rfc=6844 We don't want CAs to think they can follow any errata they like, or to come up with

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 18:10:02 -0700 Peter Bowen <pzbo...@gmail.com> wrote: > On Sat, Sep 9, 2017 at 1:59 PM, Andrew Ayer <a...@andrewayer.name> > wrote: > > On Sat, 9 Sep 2017 13:53:52 -0700 > > Peter Bowen via dev-security-policy > > <dev-security-policy@li

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 13:53:52 -0700 Peter Bowen via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer <a...@andrewayer.name> > wrote: > > > > drill is buggy and insecure. Obviously, such implement

Re: CAs not compliant with CAA CP/CPS requirement

On Fri, 8 Sep 2017 15:22:52 -0700 (PDT) Andy Warner via dev-security-policy wrote: > Google Trust Services published updated CP & CPS versions earlier > today covering CAA checking. I'd suggest checking all CAs again > tomorrow. Given the range of timezones

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 06:57:39 -0400 Jonathan Rudenberg via dev-security-policy wrote: > > > On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy > > wrote: > > > > In all three of these cases, the "domain's

Re: StartCom communication

On Mon, 4 Sep 2017 12:10:19 + Inigo Barreira via dev-security-policy wrote: > [...] > > a. Test certificates > > It__s been detailed in bugzilla #1369359. There__s an attachment with a > detailed explanation what happened, when, who, what was done to >

Per-intermediate CAA/problem reporting info

Currently, CAA identifiers and problem reporting information are collected on a per-CA basis and published in the "CA Information Report"[1]. However, externally-operated sub-CAs generally have their own CAA identifiers and problem reporting information, and this information is not currently

Re: PROCERT issuing certificates with non-random serial numbers

On Wed, 16 Aug 2017 19:56:45 -0700 Andrew Ayer via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > Every certificate known to CT issued by PROCERT with a notBefore > date after September 30, 2016 has what appears to be a non-random > serial number: https://c

PROCERT issuing certificates with non-random serial numbers

Every certificate known to CT issued by PROCERT with a notBefore date after September 30, 2016 has what appears to be a non-random serial number: https://crt.sh/?Identity=%25=750 1e:4d:94:48:00:00:00:00:0c:79 2f:84:26:06:00:00:00:00:0b:1b 3d:94:73:d1:00:00:00:00:0a:ab

Re: TrustCor root inclusion request

On Mon, 14 Aug 2017 20:27:05 +0100 Neil Dunbar via dev-security-policy wrote: > Note that TrustCor is capable of removing SHA-1 as a signature hash on > OCSP responses, if the community determines it presents risk to the > relying parties. However, this

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Tue, 20 Jun 2017 21:23:51 +0100 Rob Stradling via dev-security-policy wrote: > [CC'ing rev...@digicert.com, as per > https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00028] > >

Re: Unknown Intermediates

On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy via dev-security-policy wrote: > On Fri, Jun 16, 2017 at 2:00 AM, Rob Stradling > wrote: > > > On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote: > > > >> Hello, I was

Re: Symantec: Draft Proposal

On Fri, 5 May 2017 17:18:38 +0100 Gervase Markham via dev-security-policy wrote: > On 05/05/17 17:09, Peter Bowen wrote: > > We know that the RAs could use different certificate profiles, as > > certificates they approved had varying issuers, and "Issuer

Grace Period for Sub-CA Disclosure

[ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67 ] Mozilla's CA Certificate Policy says: > All certificates that are capable of being used to issue new > certificates, that are not technically constrained, and that directly > or transitively chain to a certificate

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

On Fri, 24 Feb 2017 07:08:54 -0800 (PST) "blake.morgan--- via dev-security-policy" wrote: > Trustis has some time ago, migrated all TLS certificate production to > SHA-256 Issuing Authorities. The small number of previously issued > SHA-1 TLS certificates

Re: Misissued/Suspicious Symantec Certificates

On Fri, 27 Jan 2017 09:43:00 -0800 (PST) Nick Lamb wrote: > On Friday, 27 January 2017 12:11:06 UTC, Gervase Markham wrote: > > * It's not clear what the problem is with the issuance in category > > F. I don't see any mention of "dev119money.com" in Andrew's initial > >

Suspicious test.com Cert Issued By GlobalSign

I found another certificate for www.test.com that I believe was mis-issued by GlobalSign: https://crt.sh/?sha256=9d503e7c6c4fb6e6d7436c07ff445b95214871ea13ac1cb3b0d7abbce9be6cfb This certificate was issued on 2015-09-11 and is not yet expired. I was not paying close attention to

Re: Misissued/Suspicious Symantec Certificates

Hi Hanno, On Tue, 24 Jan 2017 10:38:01 +0100 Hanno B__ck wrote: > Hello, > > I have a few observations to share about this incident, not sure how > relevant they are. Thanks for sharing these. I found them interesting. > There are 4 "example.com" certificates related to

Misissued/Suspicious Symantec Certificates

I. Misissued certificates for example.com On 2016-07-14, Symantec misissued the following certificates for example.com: https://crt.sh/?sha256=A8F14F52CC1282D7153A13316E7DA39E6AE37B1A10C16288B9024A9B9DC3C4C6

Re: CA Public Key Material

On Wed, 14 Dec 2016 18:46:31 -0800 Tavis Ormandy wrote: > Hello, while working on an unrelated problem, I happened to notice > that this leaf certificate for > DNS:test.wgh.cn and DNS: test.ydn.cn has the same RSA public key as > this trusted root

Re: Technically Constrained Sub-CAs

On Thu, 17 Nov 2016 09:28:43 -1000 Brian Smith <br...@briansmith.org> wrote: > On Mon, Nov 14, 2016 at 6:39 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > > As Andrew Ayer points out, currently, CAs are required to ensure > > TCSCs comply with the BRs. Non-c

Re: Technically Constrained Sub-CAs

On Mon, 14 Nov 2016 06:00:24 -0800 Peter Bowen 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 > >

Re: Implementing a SHA-1 ban via Mozilla policy

On Tue, 8 Nov 2016 11:17:29 + Gervase Markham wrote: > On 07/11/16 17:09, Nick Lamb wrote: > > On Monday, 7 November 2016 13:53:31 UTC, Gervase Markham wrote: > >> You mean EKU-constrained (e.g. to email, or OCSP only)? > > > > I was thinking also of a pathlen constraint.

Re: New SHA-1 certificates issued in 2016

On Fri, 4 Nov 2016 10:30:00 + Gervase Markham wrote: > We need to recall that currently, SHA-1 issuance is not banned > directly by Mozilla policy, but only by the BRs. And so we don't have > a route to object to certs not covered by the BRs. The March 2016 CA

Re: New SHA-1 certificates issued in 2016

On Thu, 3 Nov 2016 17:53:01 + Gervase Markham wrote: > On 28/10/16 16:11, Patrick Figel wrote: > > I found a number of SHA-1 certificates chaining up to CAs trusted by > > Mozilla that have not been brought up on this list or on Bugzilla > > yet. > > Using the handy crt.sh

Re: Remediation Plan for WoSign and StartCom

On Tue, 18 Oct 2016 15:49:26 -0700 Gervase Markham wrote: > On 18/10/16 15:42, Ryan Hurst wrote: > > I do not understand the desire to require StartCom / WoSign to not > > utilize their own logs as part of the associated quorum policy. > > My original logic was that it could

Re: WoSign: updated report and discussion

On Mon, 10 Oct 2016 12:11:49 +0100 Gervase Markham wrote: > > During the time that the incidents > > occurred, StartCom and WoSign were for all intents and purposes the > > same company, one wholly owned by the other, both managed by the > > same disgraced CEO, and sharing

Re: WoSign and StartCom

> This fixing of the notAfter date in this style of certificate may > have been a sensible move to avoid accidentally issuing SHA-1 > certificates whose validity extends into 2017, which would also be a > BR violation. This contradicts the "Issue D" section at

Re: Incidents involving the CA WoSign

On Sat, 3 Sep 2016 21:50:51 -0700 Peter Bowen wrote: > The log entries for the SM2 certificates are > https://ctlog.wosign.com/ct/v1/get-entries?start=109239=109240; > crt.sh doesn't have them. The matching serial numbers are > https://crt.sh/?id=30613201 and

Re: Incidents involving the CA WoSign

On Fri, 2 Sep 2016 11:19:18 +0100 Gervase Markham wrote: > On 31/08/16 19:13, Ryan Sleevi wrote: > > A) Remove the CA. Users may manually trust it if they re-add it, > > but it will not be trusted by default. > > > F) Distrust all certs with a notBefore date after date X,

Re: Incidents involving the CA WoSign

On Thu, 1 Sep 2016 09:00:38 -0700 "Ryan Sleevi" wrote: > Incident -2: 16 January 2015 - 5 March 2015 - 1,132 BR-violating SHA-1 > certificates ( https://cert.webtrust.org/SealFile?seal=2019=pdf ) This was a violation of a "SHOULD NOT" (not a "MUST NOT") issue SHA-1 certificates

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

On Wed, 17 Aug 2016 11:43:45 -0700 (PDT) cspann...@gmail.com wrote: > On Wednesday, August 17, 2016 at 10:31:29 AM UTC-7, Andrew Ayer wrote: > > The attacker has to be able to control (or predict) the prefix of > > the data signed by the CA (which in the case of a TBSCertificat

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

On Wed, 17 Aug 2016 19:08:08 +0200 Kurt Roeckx wrote: > On Wed, Aug 17, 2016 at 09:55:24AM -0700, Ryan Sleevi wrote: > > > I don't think adding that CA certificate to OneCRL is enough, > > > that would only protect Mozilla users. They should revoke all > > > the relevant

Re: Certificate Incident

On Thu, 14 Jul 2016 02:52:41 -0700 (PDT) Nick Lamb <tialara...@gmail.com> 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 o

Re: Certificate Incident

On Wed, 13 Jul 2016 20:02:58 -0700 (PDT) sanjay_m...@symantec.com wrote: > On Tuesday, July 12, Symantec erroneously produced and issued 8 SHA-1 > certificates in support of one customer’s application to submit SHA-1 > TBS Certificates to the CA/B Forum for a SHA-1 exception. Symantec > has

Re: StartEncrypt considered harmful today

On Thu, 30 Jun 2016 22:36:19 +0200 Christiaan Ottow wrote: > We acquired certificates for a private domain (and some subdomains) > of the tester in question, and one for our domain pine.nl. Details of > the latter are attached, with the modulus and signature left out. The >

Re: StartEncrypt considered harmful today

On Thu, 30 Jun 2016 15:54:02 -0400 Jonathan Rudenberg wrote: > > > On Jun 30, 2016, at 15:44, Christiaan Ottow > > wrote: > > > > The certificates we had issuedto us as proof of concept (only for > > our own domains), were not revoked and we don't

Re: SSL Certs for Malicious Websites

On Thu, 19 May 2016 16:52:26 -0700 (PDT) tech29...@gmail.com wrote: > Your main concern – unjustified delay in issuing a certificate to > your customer while a human looks at the domain to decide if there is > a problem - is not really related to any of Kathleen’s questions. > Your other comments

Re: SSL Certs for Malicious Websites

On Tue, 17 May 2016 03:19:22 + Peter Gutmann wrote: > Matt Palmer writes: > >On Mon, May 16, 2016 at 02:22:08PM +0200, Richard Z wrote: > >> knowingly issuing/tolerating certificates for sites known to > >> inject malware is > >> * contrary to

Re: SSL Certs for Malicious Websites

Kathleen, I believe that certificate authorities should be content-neutral. They should not be required to assess "misuse" or "fraud," nor be required to revoke certificates except upon request of the owner of a domain listed in the certificate. Requiring CAs to police website content is

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

On Wed, 27 Apr 2016 23:46:25 -0700 (PDT) sanjay_m...@symantec.com wrote: > We have a technical control in place for systems that issue S/MIME > certs in this CA hierarchy. Our systems use static cert templates > from which end-entity certs are issued. Those templates include an > EKU value, but

Re: OCSP Responders Are An Attack Vector For SHA-1 Collisions

On Wed, 9 Mar 2016 21:40:32 +0100 Jakob Bohm wrote: > 1. Use a non-CA OCSP certificate if the relevant clients are known to >support this aspect of the OCSP protocol (I don't know if any OCSP >clients, historic or otherwise, lack this ability). Using a dedicated

OCSP Responders Are An Attack Vector For SHA-1 Collisions

As we all know, the Baseline Requirements forbid signing certificates with SHA-1 after January 1, 2016. However, both the BRs and Mozilla policy are silent on the topic of OCSP response signatures[1]. Theoretically, CAs could continue to sign OCSP responses with SHA-1 indefinitely. Indeed, among

Re: Proposed limited exception to SHA-1 issuance

On Wed, 24 Feb 2016 16:11:38 -0800 (PST) rbar...@mozilla.com wrote: > 2. On issuance of any such certificate(s), the issuer MUST take the > following actions: 2.a. Submit the certificates to one or more > Certificate Transparency logs. (There is no requirement for the > certificates to contain a

Re: Proposed limited exception to SHA-1 issuance

On Wed, 24 Feb 2016 14:58:37 + Gervase Markham wrote: > > They had ample opportunity to avoid a crisis. It is not > > Mozilla's responsibility to dig them out of the hole they have dug > > for themselves, > > It is not our responsibility; on the other hand, the damage

Re: Proposed limited exception to SHA-1 issuance

On Tue, 23 Feb 2016 18:57:41 + Gervase Markham wrote: > Please comment on whether this proposal seems reasonable, being aware > of the short timelines involved. I am opposed. There is no telling how many other organizations are in a similar situation due to poor planning

Re: Remove trust of Symantec's Class 3 Public Primary Certification Authority?

On Sat, 12 Dec 2015 16:56:04 -0800 Yuhong Bao wrote: > I think this and most of the other 1024-bit roots was removed or > restricted to email in Mozilla some time ago (last remaining one is > Equifax). They had been consider obsolete for a long time. Indeed, the