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

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

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

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

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 13:53:52 -0700 Peter Bowen via dev-security-policy wrote: > On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer > wrote: > > > > drill is buggy and insecure. Obviously, such implementations can > > be found. Note that

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: CAA Certificate Problem Report

On Sat, 9 Sep 2017 18:10:02 -0700 Peter Bowen wrote: > On Sat, Sep 9, 2017 at 1:59 PM, Andrew Ayer > wrote: > > On Sat, 9 Sep 2017 13:53:52 -0700 > > Peter Bowen via dev-security-policy > > wrote: > > > >> On Sat,

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

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: 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: 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 summary table (named >

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: 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: 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: 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 intermediate

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

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

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