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

2015-12-14 Thread Andrew Ayer
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

Re: Proposed limited exception to SHA-1 issuance

2016-02-24 Thread Andrew Ayer
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

2016-02-23 Thread Andrew Ayer
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: Proposed limited exception to SHA-1 issuance

2016-02-26 Thread Andrew Ayer
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

OCSP Responders Are An Attack Vector For SHA-1 Collisions

2016-03-08 Thread Andrew Ayer
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: OCSP Responders Are An Attack Vector For SHA-1 Collisions

2016-03-09 Thread Andrew Ayer
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

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

2016-04-28 Thread Andrew Ayer
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: SSL Certs for Malicious Websites

2016-05-19 Thread Andrew Ayer
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: SSL Certs for Malicious Websites

2016-05-19 Thread Andrew Ayer
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

2016-05-20 Thread Andrew Ayer
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: Certificate Incident

2016-07-14 Thread Andrew Ayer
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

2016-07-13 Thread Andrew Ayer
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

2016-06-30 Thread Andrew Ayer
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: StartEncrypt considered harmful today

2016-06-30 Thread Andrew Ayer
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: Hongkong Post recently issued SHA1 cert that could be used in TLS

2016-08-17 Thread Andrew Ayer
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: Hongkong Post recently issued SHA1 cert that could be used in TLS

2016-08-17 Thread Andrew Ayer
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: Misissued/Suspicious Symantec Certificates

2017-01-24 Thread Andrew Ayer
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

Re: Misissued/Suspicious Symantec Certificates

2017-01-30 Thread Andrew Ayer
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

2017-01-25 Thread Andrew Ayer
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

Misissued/Suspicious Symantec Certificates

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

Re: Incidents involving the CA WoSign

2016-09-02 Thread Andrew Ayer
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

2016-09-01 Thread Andrew Ayer
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: Incidents involving the CA WoSign

2016-09-04 Thread Andrew Ayer
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: WoSign and StartCom

2016-09-26 Thread Andrew Ayer
> 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: Implementing a SHA-1 ban via Mozilla policy

2016-11-08 Thread Andrew Ayer
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

2016-11-04 Thread Andrew Ayer
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: Remediation Plan for WoSign and StartCom

2016-10-18 Thread Andrew Ayer
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: Technically Constrained Sub-CAs

2016-11-17 Thread Andrew Ayer
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

2016-11-14 Thread Andrew Ayer
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: New SHA-1 certificates issued in 2016

2016-11-03 Thread Andrew Ayer
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: WoSign: updated report and discussion

2016-10-10 Thread Andrew Ayer
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: CA Public Key Material

2016-12-15 Thread Andrew Ayer
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: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-02-24 Thread Andrew Ayer via dev-security-policy
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

Grace Period for Sub-CA Disclosure

2017-03-27 Thread Andrew Ayer via dev-security-policy
[ 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: TrustCor root inclusion request

2017-08-14 Thread Andrew Ayer via dev-security-policy
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

PROCERT issuing certificates with non-random serial numbers

2017-08-16 Thread Andrew Ayer via dev-security-policy
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: PROCERT issuing certificates with non-random serial numbers

2017-08-16 Thread Andrew Ayer via dev-security-policy
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

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

2017-06-21 Thread Andrew Ayer via dev-security-policy
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

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

2017-05-05 Thread Andrew Ayer via dev-security-policy
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

Re: CAA Certificate Problem Report

2017-09-09 Thread Andrew Ayer via dev-security-policy
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

2017-09-09 Thread Andrew Ayer via dev-security-policy
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

2017-09-09 Thread Andrew Ayer via dev-security-policy
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: CAA Certificate Problem Report

2017-09-10 Thread Andrew Ayer via dev-security-policy
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

Per-intermediate CAA/problem reporting info

2017-08-28 Thread Andrew Ayer via dev-security-policy
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: StartCom communication

2017-09-04 Thread Andrew Ayer via dev-security-policy
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 >

Re: DRAFT November 2017 CA Communication

2017-10-25 Thread Andrew Ayer via dev-security-policy
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: Applicability of SHA-1 Policy to Timestamping CAs

2019-03-22 Thread Andrew Ayer via dev-security-policy
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: Survey of (potentially noncompliant) Serial Number Lengths

2019-03-26 Thread Andrew Ayer via dev-security-policy
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: Reported Digicert key compromise but not revoked

2019-05-09 Thread Andrew Ayer via dev-security-policy
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: Certinomis Issues

2019-05-14 Thread Andrew Ayer via dev-security-policy
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: Unretrievable CPS documents listed in CCADB

2019-05-02 Thread Andrew Ayer via dev-security-policy
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: DigiCert OCSP services returns 1 byte

2019-09-16 Thread Andrew Ayer via dev-security-policy
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

2019-09-13 Thread Andrew Ayer via dev-security-policy
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

2019-07-29 Thread Andrew Ayer via dev-security-policy
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

2019-07-18 Thread Andrew Ayer via dev-security-policy
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: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

2020-04-20 Thread Andrew Ayer via dev-security-policy
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: DigiCert OCSP services returns 1 byte

2020-03-15 Thread Andrew Ayer via dev-security-policy
On Tue, 1 Oct 2019 16:51:34 -0700 Wayne Thayer via dev-security-policy wrote: > I could simply move [4] to a "recommended practice" (SHOULD) until the > ballot comes into force, then move it back to "required". Since Ballot SC23 has come into force, can we now move

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

2020-05-16 Thread Andrew Ayer via dev-security-policy
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: About upcoming limits on trusted certificates

2020-03-17 Thread Andrew Ayer via dev-security-policy
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