Re: DigiCert OCSP services returns 1 byte

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 https://wiki.mozilla.org/CA/Re

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

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

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 hi

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 h

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 reduc

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 E

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

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 C

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 https://ccadb-public

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 repo

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 supposed

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 discussing

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

Re: Misissued/Suspicious Symantec Certificates

Hi Steve, I have a few questions: 1. What criteria is Symantec using to determine if a certificate has a "deficiency" that warrants re-validation? 2. How will Symantec assess whether the domain(s) in a certificate were correctly validated? 3. Is any of the information gathered by processing age

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 issued from “FPS TT”, that had lifetimes

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

On Fri, 24 Feb 2017 08:25:25 -0800 Andrew Ayer via dev-security-policy wrote: > 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-2

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

On Tue, 28 Feb 2017 04:29:20 -0800 (PST) Itzhak Daniel via dev-security-policy wrote: > I also would like to have an official reply from GlobalSign saying > that "on the date they issue the certificate the domain exists". Note that the BRs do not require a domain to exist when a CA issues a DV/O

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: 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 DN" has > > the same "No(1)" that CP has i

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 crawling the pkcs7 blobs in public pdf files and > >> found some

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&QuestionId=Q00028] > > Annie, > > "but these have been k

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 does raise the risk to some clients > that

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&iCAID=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 4b:53:8c:18:00:00:00:00

Re: PROCERT issuing certificates with non-random serial numbers

On Wed, 16 Aug 2017 19:56:45 -0700 Andrew Ayer via dev-security-policy 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://crt.sh/?Identity=%25&iCAID=750 These

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 colle

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 > remediate and to avoid it happening in

CAs not compliant with CAA CP/CPS requirement

The BRs state: "Effective as of 8 September 2017, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state the CA's policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shal

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 08:49:01 -0700 Peter Bowen via dev-security-policy wrote: > On Sat, Sep 9, 2017 at 3:57 AM, Jonathan Rudenberg > wrote: > > > >> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy > >> wrote: > >> > >> In all three of these cases, the "domain's zone does not have a

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 09:21:30 + Jeremy Rowley via dev-security-policy wrote: > Certificate 1 contains a single DNS identifier for > big.basic.caatestsuite.com . > This DNS name has a CAA resource record set that is too large to fit > within a single DNS UDP

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 zone does not have a > > DNSSEC validation chain to the ICANN root" -- I request

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 CA operational staffs operate > across,

Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 13:14:29 -0700 Peter Bowen via dev-security-policy wrote: > On Sat, Sep 9, 2017 at 11:50 AM, Andrew Ayer > wrote: > > On Sat, 9 Sep 2017 08:49:01 -0700 > > Peter Bowen via dev-security-policy > > wrote: > > > >> On Sat, Sep 9, 2017 at 3:57 AM, Jonathan Rudenberg > >> wrote:

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 drill is just a "debugging/query" tool, not a > > resolver you wo

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, Sep 9, 2017 at 1:50 PM, Andrew Ayer > >> wrote: > >> > > >> > drill is buggy and

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 the