Re: New intermediate certs and Audit Statements

On 9th July 2019, Kathleen wrote: > I propose that to handle this situation, the CA may enter the subordinate CA's current audit statements and use the Public Comment field to indicate that the new certificate will be included in the next audit statements. Hi Kathleen. CCADB now automatically

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

> We already have automation for CCADB. CAs can and do use it for disclosure of > intermediates. Any CA representatives that are surprised by this statement might want to go and read the "CCADB Release Notes" (click the hyperlink when you login to the CCADB). That's the only place I've seen

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

Hi Ben. > *A CA technically capable of issuing server certificates MUST ensure that > the CCADB field "Full CRL Issued By This CA" contains either the URL for > the full and complete CRL or the URL for the JSON file containing all URLs > for CRLs that when combined are the equivalent of the full

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

> Perhaps add: "And also include any other certificates sharing the same > private/public key pairs as certificates already included in the > requirements." (this covers the situation you mentioned where a > self-signed certificate shares the key pair of a certificate that chains > to an included

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

Hi Dimitris. I don't see where you're getting "in order to get an EV audit" from. The proposed language deals with whether or not a CA has got all of the audits that Mozilla deems necessary, not with whether or not a CA may obtain new audits. From: Dimitris

Re: Sectigo to Be Acquired by GI Partners

Jakob wrote: > The part needing clarification started with: > > > In addition to the questions posted by Wayne, I think it'd be useful > > to confirm: > > ... I did not address that part of Ryan's post, but Tim's delayed message did address it. See

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

Hi Ben. I agree with Dimitris that the proposed language is a bit confusing. > "(i.e. a subordinate CA under an EV-enabled root that contains no EKU or the > id-kp-serverAuth EKU or anyExtendedKeyUsage EKU, and a certificatePolicies > extension that asserts the CABF EV OID of 2.23.140.1.1, the

Re: Sectigo to Be Acquired by GI Partners

> ...clarification of what meaning was intended. Merely this... "Hi Ryan. Tim Callan posted a reply to your questions last week, but his message has not yet appeared on the list. Is it stuck in a moderation queue?" ___ dev-security-policy mailing

Re: Sectigo to Be Acquired by GI Partners

Hi Jacob. I don't believe that this list mandates any particular posting style [https://en.wikipedia.org/wiki/Posting_style]. Although interleaved/inline posting is my preferred style, I'm stuck using Outlook365 as my mail client these days. (Sadly, Thunderbird's usability worsened

Re: Sectigo to Be Acquired by GI Partners

Hi Ryan. Tim Callan posted a reply to your questions last week, but his message has not yet appeared on the list. Is it stuck in a moderation queue? From: dev-security-policy on behalf of Ryan Sleevi via dev-security-policy Sent: 03 October 2020 22:16 To:

Re: Sectigo to Be Acquired by GI Partners

Hi Wayne. We are not currently planning any changes to our CP/CPS as a result of this change of control. From: dev-security-policy on behalf of Wayne Thayer via dev-security-policy Sent: 02 October 2020 01:32 To: mozilla-dev-security-policy Subject: Re:

Re: Mandatory reasonCode analysis

, I'm not sure you filtered this report by "thisUpdate", maybe you did it by nextUpdate by mistake? The GlobalSign CRL on this report was created in 2016, thus the question. Doug -Original Message- From: dev-security-policy On Behalf Of Rob Stradling via dev-security-p

Re: Mandatory reasonCode analysis

sis I had anyway - that any CRLs and OCSP published after 9-30 had to have reasonCode. -Original Message- From: dev-security-policy On Behalf Of Rob Stradling via dev-security-policy Sent: Wednesday, September 30, 2020 9:59 AM To: dev-security-policy@lists.mozilla.org Subject: Mandato

Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for revoked CA certificates. Since crt.sh already monitors CRLs and keeps track of reasonCodes, I thought I would conduct some analysis to determine the level of (non)compliance with these new rules. It's not clear to me

Sectigo to Be Acquired by GI Partners

[Posting for Sectigo] There is an agreement for private investment firm GI Partners, out of San Francisco, CA, to acquire Sectigo. We foresee no effect on our operations due to this ownership change. Press release: https://sectigo.com/resource-library/sectigo-to-be-acquired-by-gi-partners

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On 06/07/2020 12:47, Rob Stradling via dev-security-policy wrote: On 06/07/2020 06:11, Dimitris Zacharopoulos via dev-security-policy wrote: IETF made an attempt to set an extention for EKU constraints (https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/) where Rob Stradling

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On 06/07/2020 06:11, Dimitris Zacharopoulos via dev-security-policy wrote: IETF made an attempt to set an extention for EKU constraints (https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/) where Rob Stradling made an indirect reference in

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

On 03/07/2020 12:24, Ryan Sleevi via dev-security-policy wrote: The key destruction is the only way I can see being able to provide some assurance that “things won’t go wrong, because it’s impossible for them to go wrong, here’s the proof” Ryan, distrusting the root(s) would be another way to

Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

On 02/07/2020 17:13, Ryan Sleevi via dev-security-policy wrote: On Thu, Jul 2, 2020 at 11:36 AM Corey Bonnell wrote: If there’s no digitalSignature KU, then the certificate is not a OCSP responder certificate due to the technical inability to sign OCSP responses that would be accepted by

Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

Doug, BR 4.9.9 says: "...the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck, as defined by RFC6960." The certificates that Ryan has identified are OCSP signing Certificates, because they contain the id-kp-OCSPSigning EKU. However, they have been misissued

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

ate Sign, CRL Sign X509v3 Extended Key Usage: Time Stamping, OCSP Signing Peter On Thu, Jul 2, 2020 at 12:14 PM Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > This batch is NOT comprehensive. According to crt.sh, there are > approximately

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

> This batch is NOT comprehensive. According to crt.sh, there are approximately > 293 certificates that meet the criteria of "issued by a Mozilla-trusted, > TLS-capable CA, with the OCSPSigning EKU, and without pkix-nocheck". > misissued.com had some issues with parsing some of these

Re: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)

here a way to filter out the revoked and non-TLS/SMIME ICAs? -Original Message- From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org>> On Behalf Of Rob Stradling via dev-security-policy Sent: Wednesday, June 17, 2020 5:07 AM To: dev-security-policy ma

crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)

Inspired by last month's email threads and Bugzilla issues relating to CA Issuers misconfigurations, I've just finished adding a new feature to crt.sh... https://crt.sh/ca-issuers Sadly, this highlights plenty of misconfigurations and other problems: PEM instead of DER, certs for the wrong

Future of Certlint / CABLint (was Re: ZLint 2.1.0-RC1 and announcement list)

In other linter news... It has become clear that the original certlint/cablint repository (https://github.com/awslabs/certlint) is no longer being maintained. At Sectigo we still use cablint as one of our preissuance linters, and we've been running into more and more problems with cablint's

Re: ssl.com: Certificate with Debian weak key

On 07/03/2020 23:57, Matt Palmer via dev-security-policy wrote: As further independent confirmation, the crt.sh page for the certificate shows that crt.sh *also* identifies the certificate as having a Debian weak key. My understanding is that crt.sh uses a database of keys that was

Re: Acceptable forms of evidence for key compromise

"As an alternative, a standard “revocation request” format could be developed that leverages the relative discoverability of each CA’s problem-reporting mechanism." Alternatively, how about we add discoverability to my proposal by asking Kathleen to add a "revokeCert API URL" field to the

Re: Acceptable forms of evidence for key compromise

"but ISTM that you've stopped slightly short of actually proposing it in this list thread. " Or not!  From: dev-security-policy on behalf of Rob Stradling via dev-security-policy Sent: 02 March 2020 21:30 To: Nick Lamb ; mozilla-dev-secur

Re: Acceptable forms of evidence for key compromise

"I do think there's value in developing some standard mechanism to request revocation/demonstrate possession of the private key." Such as https://tools.ietf.org/html/rfc8555#section-7.6 ? ISTM that any CA could stand up a standalone "revokeCert" API that only accepts proofs signed by the

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

Dimitris, Since CAs should already be disclosing that an intermediate certificate is "externally-operated" by populating the "Subordinate CA Owner" field in the CCADB record, what's the benefit of duplicating this information in the intermediate certificate itself? What happens if an

Re: DigiCert OCSP services returns 1 byte

On 02/10/2019 00:51, Wayne Thayer wrote: > On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling wrote: > > I propose that you update [4] to say that Mozilla won't treat > non-compliance with [4] as an "incident" whilst it remains the case > that the BRs are inconsistent with [4]. > > I could

Re: DigiCert OCSP services returns 1 byte

On 01/10/2019 00:45, Wayne Thayer via dev-security-policy wrote: > I've initiated a CAB Forum ballot [1] to resolve the inconsistency that Rob > identified. Thanks Wayne. I've offered to endorse. > I also want to acknowledge the feedback from Google on the timing of this. > I can appreciate the

Re: DigiCert OCSP services returns 1 byte

On 19/09/2019 21:01, Ryan Sleevi wrote: > It would be helpful for one of the relevant documents, or another > document, or even an errata, to clarify that OCSP services can be > offered for pre-certificates.  It’s merely a question of clarifying > the technical requirements about

Re: DigiCert OCSP services returns 1 byte

On 16/09/2019 18:08, Andrew Ayer wrote: > 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 thi

Re: OCSP responder support for SHA256 issuer identifier info

I'm not aware of any requirement that demands that OCSP responders support SHA-256 for CertID.hashAlgorithm or of any requirement that forbids this. Therefore, I think 1, 2 and 4 are all acceptable responses to an OCSP request whose CertID.hashAlgorithm is SHA-256. SHA-1 is the defacto

Re: DigiCert OCSP services returns 1 byte

On 17/09/2019 08:01, Kurt Roeckx via dev-security-policy wrote: > On 2019-09-16 14:02, Rob Stradling wrote: >> >> ISTM that this "certificate presumed to exist" concept doesn't play >> nicely with the current wording of BR 4.9.10: >>     'If the OCSP responder receives a request for status of a

Re: DigiCert OCSP services returns 1 byte

On 16/09/2019 23:58, Wayne Thayer wrote: > On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote: > And so at this point ISTM that the OCSP responder is expected to > implement two conflicting requirements for the serial number in > question: >    (1) MUST respond "good", because

Re: DigiCert OCSP services returns 1 byte

On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote: > Here's some suggested wording for the last paragraph: > >> This means, for example, that (i) a CA must provide OCSP services >> and responses in accordance with Mozilla policy for all certificates >> presumed to exist based on the

Re: DigiCert OCSP services returns 1 byte

On 13/09/2019 19:24, Tim Hollebeek wrote: > Yes, but I think this clarifies things in the wrong direction. Hi Tim. I'm not clear what you mean. I was talking specifically and only about what IETF could/should do regarding this matter. Which part did you disagree with, and why? > -Tim > >>

Re: DigiCert OCSP services returns 1 byte

On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote: > So, this is something that would be helpfully clarified via either an IETF > draft, There's already a 6962-bis draft [1] in IESG Last Call, which (when we finally complete it!) will obsolete RFC6962. 6962-bis redefines

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

On 29/07/2019 21:52, Andrew Ayer via dev-security-policy wrote: > 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,

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

g CA under their own > qualifying audit, and our audits which cover the Root and the intermediate CA > which we operate in an offline manner. > > Thank you, > Brenda Bernal > DigiCert > > On 7/24/19, 9:42 AM, "dev-security-policy on behalf of Rob Stradling via &g

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

[Wearing Sectigo hat] Andrew, thanks for filing [1]. Sectigo will provide a full response on that bug, but I'll just note here that we have updated the CCADB records for the cross-certificates such that the Audit and CP/CPS details are now consistent with the Web.com roots. As it happens, I

Re: CA-issued certificates for publicly-available private keys VU#553544

I've just created a batch for this second list on the Revocation Tracker: https://misissued.com/batch/49/ On 03/04/2019 15:50, CERT Coordination Center wrote: > Hi Wayne, > > Sorry about the delay in getting back to you. This first round of CA > notifications went out at approximately 10AM

Re: Survey of (potentially noncompliant) Serial Number Lengths

On 18/03/2019 21:11, Hector Martin 'marcan' wrote: > On 19/03/2019 02.17, Rob Stradling via dev-security-policy wrote: >> On 18/03/2019 17:05, Kurt Roeckx wrote: >>> On Mon, Mar 18, 2019 at 03:30:37PM +0000, Rob Stradling via >>> dev-security-policy wrote: >>

Re: CA-issued certificates for publicly-available private keys VU#553544

I've just created a batch for this list on the Revocation Tracker: https://misissued.com/batch/47/ On 22/03/2019 19:05, CERT Coordination Center via dev-security-policy wrote: > Hi folks, > > I'm sharing this information with this list per suggestion of Hanno > Böck. Some time ago we started

Re: Survey of (potentially noncompliant) Serial Number Lengths

On 18/03/2019 17:05, Kurt Roeckx wrote: > On Mon, Mar 18, 2019 at 03:30:37PM +0000, Rob Stradling via > dev-security-policy wrote: >> >> When a value in column E is 100%, this is pretty solid evidence of >> noncompliance with BR 7.1. >> When the values in column E a

Re: Survey of (potentially noncompliant) Serial Number Lengths

On 18/03/2019 15:43, Rob Stradling via dev-security-policy wrote: > On 18/03/2019 15:30, Rob Stradling via dev-security-policy wrote: > >> On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote: >>> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:

Re: Survey of (potentially noncompliant) Serial Number Lengths

On 18/03/2019 15:30, Rob Stradling via dev-security-policy wrote: > On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote: >> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote: > >>> If any other CA wants to check theirs before someone else does, th

Survey of (potentially noncompliant) Serial Number Lengths

On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote: > On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote: >> If any other CA wants to check theirs before someone else does, then now is >> surely the time to speak up. > > Someone else is in th

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

On 14/03/2019 01:09, Peter Gutmann via dev-security-policy wrote: > I'd already asked previously whether any CA wanted to indicate publicly that > they were compliant with BR 7.1, which zero CAs responded to (I counted them > twice). Peter, Mozilla Root Store Policy section 2.3 [1] requires CAs

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote: > On Tuesday, March 12, 2019 at 11:53:25 PM UTC, Kurt Roeckx wrote: >> >> The expected distribution when generating a random 64 bit integer >> and properly encoding that as DER is that: >> - about 1/2 integers require 9 bytes >> -

Re: Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

On 13/03/2019 03:04, Peter Gutmann wrote: > Rob Stradling via dev-security-policy > writes: > >> I've been working on an alternative proposal for a serial number generation >> scheme, for which I intend to write an I-D and propose to the LAMPS WG. > > This seems

Re: Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

teps 7 and 8 to... 7. Perform a binary search for the first occurrence of H || A || R || D in the DER(TBSCertificate) that was produced in step 6, and replace that first occurrence with H || A || R || TRUNCATE_TO_64BITS(D). 8. Sign the (modified by step 7) DER(TBSCertificate). > On Tue, Mar

Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

Hi all. I've been working on an alternative proposal for a serial number generation scheme, for which I intend to write an I-D and propose to the LAMPS WG. However, since other folks' proposals are already flowing, I will share the gist of mine here. Comments welcome! - Serial Number

Re: DarkMatter Concerns

On 07/03/2019 05:14, Benjamin Gabriel via dev-security-policy wrote: > Part 1 of 2: > > Dear Ryan, > > A fair and transparent public discussion requires full disclosure of each > participant's motivations and ultimate agenda. Whether in CABForum, or > Mozilla-dev-security-policy, I represent

Re: DarkMatter Concerns

Hi Scott. It seems that the m.d.s.p list server stripped the attachment, but (for the benefit of everyone reading this) I note that you've also attached it to https://bugzilla.mozilla.org/show_bug.cgi?id=1427262. Direct link: https://bug1427262.bmoattachments.org/attachment.cgi?id=9046699 On

Re: DarkMatter Concerns

On 25/02/2019 16:17, Nick Lamb via dev-security-policy wrote: > On Sat, 23 Feb 2019 10:16:27 +0100 > Kurt Roeckx via dev-security-policy > wrote: >> I would also like to have a comment from the current root owner >> (digicert?) on what they plan to do with it. > > Two other things would be

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

On 24/01/2019 14:09, Kurt Roeckx via dev-security-policy wrote: > On 2019-01-24 12:08, Rob Stradling wrote: >> >> Hi Kurt. >> >> BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP >> address or Fully-Qualified Domain Name that is one of the values >> contained in the

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

On 24/01/2019 09:04, Kurt Roeckx via dev-security-policy wrote: > On 2019-01-24 9:47, Buschart, Rufus wrote: >> Good morning! >> >> I would like to sharpen my argument from below a little bit: If a CA >> gets a request to issue a certificate for the domain >> xn--gau-7ka.siemens.de, how can the

Re: Test website monitor

On 14/01/2019 08:09, westmail24--- via dev-security-policy wrote: > This URL ( https://crt.sh/test-websites ) does not work (~5 days) Fixed. Thanks. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy

Re: Yet more undisclosed intermediates

On 02/01/2019 14:10, Rob Stradling via dev-security-policy wrote: > On 02/01/2019 13:44, info--- via dev-security-policy wrote: >> We're reviewing what happened with this subCA, because it's reported to the >> CCADB (like all other subCAs). At the moment we've seen tha

Re: Yet more undisclosed intermediates

On 02/01/2019 22:40, Wayne Thayer via dev-security-policy wrote: > Yes, the idea is that CT could remove the need to enforce intermediate > disclosures via policy. Hi Wayne. That seems at odds with (my understanding of) the purpose of the disclosure requirement. The relevant phrase in the

Re: Yet more undisclosed intermediates

On 02/01/2019 13:44, info--- via dev-security-policy wrote: > El miércoles, 2 de enero de 2019, 12:49:52 (UTC+1), Rob Stradling escribió: >> On 09/10/2018 23:53, Wayne Thayer wrote: >>> On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote: >>> Wayne, Kathleen: >>> Given the number of

Re: Yet more undisclosed intermediates

On 09/10/2018 23:53, Wayne Thayer wrote: > On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote: > Wayne, Kathleen: > Given the number of times that all the CAs in Mozilla's Root Program > have been reminded about Mozilla's requirements for disclosing > intermediate certs, I wouldn't

Re: Use cases of publicly-trusted certificates

On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote: > For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp- > browserWwwServerAuth" .  WWW is mentioned only in a comment under the > OID definition. Hi Jakob. Are you suggesting that comments in ASN.1 specifications are

Re: Online exposed keys database

2018 at 05:56:08PM +0900, Hector Martin 'marcan' via > dev-security-policy wrote: >> On 19/12/2018 20:09, Rob Stradling via dev-security-policy wrote: >>> I'm wondering how I might add a pwnedkeys check to crt.sh. I think I'd >>> prefer to have a table of SHA-256(SPKI) stor

Re: Online exposed keys database

Hi Matt. This is great. A few comments inline... On 19/12/2018 09:00, Matt Palmer via dev-security-policy wrote: > Hi Ryan, > > On Tue, Dec 18, 2018 at 08:24:48PM -0800, Ryan Hurst via dev-security-policy > wrote: >> My first thought is by using SPKI you have limited the service >>

Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable

On 14/12/2018 21:06, Wayne Thayer via dev-security-policy wrote: > I think it;s worth calling out that Let's Encrypt has implemented what > appears to be a relatively simple mitigation: > https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-bytes/77945 Sectigo implemented this

Re: DigiCert Assured ID Root CA and Global Root CA EV Request

Hi Jeremy. Comments inline... On 14/12/2018 02:23, Jeremy Rowley via dev-security-policy wrote: > Here’s the breakdown: > > FATAL: x509: RSA modulus is not a positive number > > Bad reading of the BRs. The BRs say the range should be between 2^16+1 and > 2^256-1. The team implementing

Re: Test website monitor

Hi Rufus. I'm not aware of any root program or CABForum requirement that supports your interpretation. On 13/12/2018 12:26, Rufus Buschart wrote: > Very nice! Are you sure, that this requirement is only valid for "Root > CAs"? I was always under the impression, that such a test web site needs

Test website monitor

Thanks to Kathleen for suggesting/requesting this new crt.sh feature... To facilitate compliance checking for the 3 test websites that BR 2.2 [1] requires for each root certificate, I've created this new report: https://crt.sh/test-websites Anything in red on this page represents either: a

Re: CA Communication: Underscores in dNSNames

Wayne, many thanks for drawing the attention of the CAs to this matter. Sectigo (formerly Comodo CA) stopped issuing certificates with underscores in dNSNames soon after CABForum ballot 202 failed. A search of our CA database this week found 251 certificates that are in scope for the BRs,

Re: Comodo Rebrand to Sectigo

On 07/11/2018 01:36, RS Tyler Schroder via dev-security-policy wrote: > Based on a recent visit to crt.sh , Comodo has rebranded to Sectigo > > > (Talked with Wayne off-list to confirm there's no announcement required under > BR Sec. 8, so just posting it for general

Re: Violation report - Comodo CA certificates revocation delays

On 19/10/2018 10:42, Ben Laurie wrote: > On Fri, 19 Oct 2018 at 10:38, Rob Stradling wrote: FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever signed.>>> Put it in Trillian? :-) That had occurred to me.  ;-) Would it be useful? To be properly useful you would

Re: Violation report - Comodo CA certificates revocation delays

On 18/10/2018 22:55, Ben Laurie wrote: On Fri, 12 Oct 2018 at 19:01, Rob Stradling wrote: On 12/10/18 16:40, Ryan Sleevi via dev-security-policy wrote: > On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie mailto:b...@google.com>> wrote: >> This is one of the reasons we also need

Re: Violation report - Comodo CA certificates revocation delays

On 12/10/18 13:53, Jakob Bohm via dev-security-policy wrote: On 12/10/2018 14:33, Ben Laurie wrote: This is one of the reasons we also need revocation transparency. Or just a crt.sh enhancement to remember the previously collected revocations. crt.sh already remembers previously collected

Re: Yet more undisclosed intermediates

On 09/10/2018 23:53, Wayne Thayer wrote: >    - DigiCert > > Looks like DigiCert disclosed these within a few hours of your email. Yes, but I hope that DigiCert will provide an incident report so that we can understand why DigiCert's "processes in place to ensure that these requirements

Yet more undisclosed intermediates

"ACTION 6" of Mozilla's September 2018 CA Communication [1] reminded CAs of the Mozilla Root Store Policy requirement [2] that non-technically-constrained intermediate CA certificates... "MUST be publicly disclosed in the CCADB by the CA that has their certificate included in Mozilla's

Re: Increasing number of Errors found in crt.sh

On 01/10/2018 16:51, Rob Stradling via dev-security-policy wrote: Hi Iñigo. I suspect it's because my script that produces the 1 week summary data [1] isn't using a consistent view of the underlying linting results throughout its processing.  Hopefully this [2] will fix it. Doh. [2

Re: Increasing number of Errors found in crt.sh

://bugzilla.mozilla.org/show_bug.cgi?id=1495518 * Certinomis: issued & revoked a precertificate containing a SAN of 'www', didn't report it - https://bugzilla.mozilla.org/show_bug.cgi?id=1495524 - Wayne On Mon, Oct 1, 2018 at 8:51 AM Rob Stradling via dev-security-policy <mailto:dev-security

Re: Increasing number of Errors found in crt.sh

! If I am not mistaken, it seems to me that we have just 1 certificate in that list, and it's a non-trusted certificate (it was issued by a test CA). Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto: On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote: Is it possible

Re: Increasing number of Errors found in crt.sh

plying for inclusion, which in some cases are ones which have a history of non-compliance under other root programs, but there's no way to programatically tell if a CA is applying for inclusion). Alex On Mon, Oct 1, 2018 at 10:05 AM Rob Stradling via dev-security-policy <mailto:dev-securi

Re: Increasing number of Errors found in crt.sh

ing number of Errors found in crt.sh Thank you Rob! If I am not mistaken, it seems to me that we have just 1 certificate in that list, and it's a non-trusted certificate (it was issued by a test CA). Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto: On 01/10/2018 14:38, Adriano S

Re: Increasing number of Errors found in crt.sh

to view linting info on older certs issued by that CA. e.g., https://crt.sh/?caid=31477=cablint=2018-01-01 (This feature is undocumented because not all historical certs have been linted by crt.sh). Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto: On 01/10/2018 14:38, Adr

Re: Increasing number of Errors found in crt.sh

On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote: Is it possible to filter the list https://crt.sh/?cablint=issues based on the issuing CA ? Yes. First, visit this page: https://crt.sh/?cablint=1+week Next, click on the link in the "Issuer CN, OU or O" column that

Re: Google Trust Services Root Inclusion Request

Richard, You might like to familiarize yourself with the Mozilla Forum Etiquette Ground Rules: https://www.mozilla.org/en-US/about/forums/etiquette/ Note this in particular: "Be civil. No personal attacks. Do not feel compelled to defend your honor in public. Posts containing personal attacks

Re: Unrevoked/unexpired certificate with Debian Weak Key

On 17/06/18 21:09, Daniel Cater via dev-security-policy wrote: On Monday, 14 May 2018 15:25:43 UTC+1, Rob Stradling I'm currently running the check against all of the certs on the crt.sh DB. I'll report back once this has completed. Hi Rob, Did your checks find anything else in the end?

Re: Unrevoked/unexpired certificate with Debian Weak Key

On 14/05/18 11:39, Jakob Bohm via dev-security-policy wrote: On 14/05/2018 10:42, Hanno Böck wrote: Hi, Yesterday was the 10y anniversary of the Debian OpenSSL random number generator bug. A few days ago I did a re-check of the CT logs for vulnerable keys. I found one unexpired, unrevoked

Re: Mis-issuance of certificate with https in CN/SAN

On 16/03/18 10:27, Rob Stradling via dev-security-policy wrote: On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote: Please see https://crt.sh/?id=353098570=cablint Note: This is the CT precertificate. Note 2: According to crt.sh, the OCSP response for this precertificate

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

On 22/04/18 21:04, Eric Mill via dev-security-policy wrote: On Fri, Apr 20, 2018 at 9:30 AM, Tim Shirley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: First of all, it's important to distinguish between the BR r But even if you accept my premise there, then you have

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

On 20/04/18 14:30, Tim Shirley via dev-security-policy wrote: First of all, it's important to distinguish between the BR requirement, which is defined in terms of certificate *issuance* dates, and the value in the "Not Before" field. I'm guessing the "Not Before" value in this certificate is

Re: Mis-issuance of certificate with https in CN/SAN

On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote: Please see https://crt.sh/?id=353098570=cablint Note: This is the CT precertificate. Note 2: According to crt.sh, the OCSP response for this precertificate is not correct.  (error message: "OCSP response contains bad number of

Re: Trustico code injection

We also asked Trustico to cease offering any tools to generate and/or retain customer private keys. They have complied with this request and have confirmed that they do not intend to offer any such tools again in the future. Trustico have also confirmed to us that they were not, and are not,

Re: How do you handle mass revocation requests?

On 01/03/18 10:51, Ben Laurie via dev-security-policy wrote: On 28 February 2018 at 21:37, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On Wed, 28 Feb 2018 20:03:51 + Jeremy Rowley via dev-security-policy wrote:

Re: Certificate for com and it

On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote: On 08/02/18 13:47, Hanno Böck wrote: Is a revoked intermediate cert a license for operating a yolo CA that signs everything? Given the fragility of revocation checking I'd find that a problematic precedent. In this case, the

Re: GlobalSign certificate with far-future notBefore

On 23/01/18 22:55, Jonathan Rudenberg via dev-security-policy wrote: https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date This incident makes me think that two changes should be made: 1) The Root Store Policy should explicitly ban forward and

Re: Camerfirma's misissued certificate

Hi Juan. Is there a particular technical reason why you feel the need to include "all the certs chaining up to the roots" in your OCSP responses? When an OCSP response is signed directly by the CA that issued the corresponding certificate, the OCSP response does not need to contain any

Re: Add Wayne Thayer as Peer of Mozilla's CA Certificates and CA Certificate Policy modules

+1 ISTM that Wayne is already doing an excellent job! On 16/01/18 22:03, Kathleen Wilson via dev-security-policy wrote: All, I propose adding Wayne Thayer as a peer[1] of Mozilla's CA Certificates Module[2] and CA Certificate Policy Module[3]. As you know, Wayne and I are distributing the

Re: CCADB disclosure of id-kp-emailProtection intermediates

about the Mozilla CA communication that said that CAs had until 15 April 2018? -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Rob Stradling via dev-security-policy Sent: Tuesday, January 16, 2018 2:29 PM To: m

  1   2   >