Re: Feasibility of a binding commitment to revoke before issuance

On Wed, Jul 24, 2024 at 5:06 PM Amir Omidi wrote: > What are the issues you see from the perspective of a root program with > the current framework? > Yes, it would be good to understand what the goals of the framework are, how the current rules work against those goals, and how different

Re: Feasibility of a binding commitment to revoke before issuance

On Wed, Jul 24, 2024 at 2:36 PM 'Ben Wilson' via dev-security-policy@mozilla.org wrote: > Personally, I currently favor extending the timeframe for the revocation > of certificates that have no security impact, > I propose, tongue only slightly in cheek, that if a component of the certificate

Re: Recent Entrust Compliance Incidents

ually identical products/processes). And thus I > can't imagine why the rest of Google wouldn't remove their trust in Entrust > as well. > > On Thu, Jun 27, 2024 at 2:47 PM Mike Shaver wrote: > >> AFAIK, BIMI certs are not related to the browser root stores in any way, >&g

Re: Recent Entrust Compliance Incidents

AFAIK, BIMI certs are not related to the browser root stores in any way, and aren’t signed by server certificate roots. Mike On Thu, Jun 27, 2024 at 4:31 PM 'Kurt Seifried' via dev-security-policy@mozilla.org wrote: > Also do we know what is happening with their VMC root cert? CN = Entrust >

Re: Mozilla delayed revocation incident expectations

On Wed, Jun 26, 2024 at 6:54 PM Tyrel wrote: > While I agree that having detailed use-case environments that result in > subscribers requesting delayed revocation might be fascinating to read, I > think it will be in practice very difficult to gather given the lack of > specificity that seems to

Re: Recent Entrust Compliance Incidents

ity Solutions, along with an updated response to address questions > from the community. > > Thanks, Bruce. > > On Tuesday, June 18, 2024 at 1:35:48 PM UTC-4 Amir Omidi (aaomidi) wrote: > >> I am not going to say with certainty that Entrust is definitely putting >> Chrome

Re: Mozilla delayed revocation incident expectations

On Wed, Jun 26, 2024 at 5:11 PM Ben Wilson wrote: > I think it would be good to collect and analyze use-case environments from > subscribers who have requested delayed revocation, if anyone has bandwidth. > I’m not sure that I have bandwidth, but I *am* sure that I don’t know how to go about

Re: Mozilla delayed revocation incident expectations

On Wed, Jun 26, 2024 at 2:40 PM Zacharias Björngren < zacharias.bjorng...@gmail.com> wrote: > I’ve been thinking a lot about the first question, ever since I noticed > how many of the certificates I sampled in lists of certificates for delayed > revocation incidents included clear markers of not

Mozilla delayed revocation incident expectations

I have two questions about the Mozilla expectations for CAs who have delayed revocation beyond the BR limits. For reference: https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation My first question concerns the requirements for detail about Subscriber requests for delayed revocation,

Re: Proposal for a 24-hour pause in Entrust Discussion

I don’t know that a pause will materially change the dynamic, but I’m willing to give it a shot! Mike On Tue, Jun 25, 2024 at 5:32 PM 'Ben Wilson' via dev-security-policy@mozilla.org wrote: > Hi Everyone, > > In light of the recent exchanges regarding the Entrust report, I would > like to

Re: Recent Entrust Compliance Incidents

haven’t given us any reason to believe otherwise. Mike On Fri, Jun 14, 2024 at 5:01 PM Mike Shaver wrote: > On Fri, Jun 14, 2024 at 4:55 PM 'Bruce Morton' via > dev-security-policy@mozilla.org wrote: > >> Amir, we will respond to the comments from the community, but I want to &

Re: Recent Entrust Compliance Incidents

most Linux systems out >> there use the Mozilla root store directly. >> On Tuesday, June 18, 2024 at 1:12:19 PM UTC-4 Mike Shaver wrote: >> >>> On Tue, Jun 18, 2024 at 12:49 PM Walt wrote: >>> >>>> I'd just like to point out that we now have a situation

Re: Recent Entrust Compliance Incidents

On Tue, Jun 18, 2024 at 12:49 PM Walt wrote: > I'd just like to point out that we now have a situation where Entrust is > in the position of seemingly valuing the opinion of other Root Programs > over Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c42 > > In Comment #37, it was

Re: Recent Entrust Compliance Incidents

On Fri, Jun 14, 2024 at 4:55 PM 'Bruce Morton' via dev-security-policy@mozilla.org wrote: > Amir, we will respond to the comments from the community, but I want to > make it clear that Entrust was absolutely NOT trying to "conceal" anything > related to how we do revocation > You redacted a part

Re: Handling of inconsistencies between BRs, CPs, and CPSes

On Fri, Jun 14, 2024 at 12:44 PM Wayne wrote: > As for your questions: > 1. It depends on the context - not a straight answer but this is a complex > document. I am of the opinion that given the language of the "take > precedence" statement, it was meant to fill-in gaps that are left by an >

Re: Recent Entrust Compliance Incidents

On Fri, 14 Jun 2024 at 10:11, Amir Omidi wrote: > I missed that they tried to conceal the part of the email where 30 day > revocation was granted. How on earth is this acceptable? > I want to be clear here: I don't know that that part of the instructions was meant to convey to affected

Re: Recent Entrust Compliance Incidents

Apologies for the delayed response; it took longer than I expected to go through the many similar incidents and find the references I wanted, and indeed in the end I omitted many others. Thanks to Ben and the Mozilla community for their patience. Entrust Report Comments First, I just have to say

Re: Revocation and Regulators

On Mon, Jun 10, 2024 at 11:06 AM Tyrel wrote: > Since it has come up in multiple delayed revocation events across multiple > CAs, I want to push back on the idea that regulators are a valid reason for > revocation delays in most cases. What do you mean by valid? - seen as an acceptable reason

Re: Distrust dates for GLOBALTRUST 2020 CA

gt;> longer trusted and to remove all documentation stating that their future >> issuances would work in specific root chains. I just don't see the security >> or integrity rationale in such a wide window, although I recognize that it >> has previous precedent I'd echo my sta

Re: Distrust dates for GLOBALTRUST 2020 CA

I have to agree with Andrew. Continuing to trust this root and the integrity of "notBefore" on the certs it issues seems like it adds risk to Firefox and Thunderbird users without basically any value to the world. If those certificates have their key material leak, do we have any reason to believe

Re: Distrust dates for GLOBALTRUST 2020 CA

Sorry, I meant for the CT-based validity checking! Mike On Tue, Jun 11, 2024 at 11:49 AM 'Ben Wilson' via dev-security-policy@mozilla.org wrote: > Here is the Bugzilla bug - > https://bugzilla.mozilla.org/show_bug.cgi?id=1901080 > Ben > > On Tuesday, June 11, 2024 at 9:43:3

Re: Distrust dates for GLOBALTRUST 2020 CA

On Tue, Jun 11, 2024 at 11:39 AM 'Ben Wilson' via dev-security-policy@mozilla.org wrote:. > Our long-term plan is to enhance our validity checking with CT. > This is great to hear. Are there bugs that can be followed that cover the necessary work here (I assume in NSS and then in Firefox and

Re: Recent Entrust Compliance Incidents

On Mon, Jun 10, 2024 at 7:28 PM Ben Wilson wrote: > Preferably here, but if the requests for clarification are structured in > markdown in Bugzilla as replies to Comment 1 > , then that > would be acceptable, too. Otherwise, general

Re: Recent Entrust Compliance Incidents

Does this mean that the window has closed for feedback to Mozilla on the report and its responsiveness to the request? Will requests for clarification be in this thread, the listed bug, or elsewhere? Does this mean that Mozilla feels that the action items listed in that bug are sufficiently

Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)

On Sun, Jun 9, 2024 at 3:34 PM Paul Wouters wrote: > On Jun 8, 2024, at 23:53, Mike Shaver wrote: > > The CA’s primary responsibility is to the web’s users, not to its > customers. > > That is an interesting view, possibly not shared by its shareholders or > the legal frame

Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)

Apologies, I somehow managed to send white-on-white HTML from gmail mobile and I honestly have no idea how. On Sat, Jun 8, 2024 at 9:48 PM Jeffrey Walton wrote: > I would caution against that. Effectively, Mozilla would be fiddling > with the market. The market should be the one to punish (or

Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)

On Sat, Jun 8, 2024 at 9:48 PM Jeffrey Walton wrote: > I would caution against that. Effectively, Mozilla would be fiddling > with the market. The market should be the one to punish (or reward) > Entrust for the premiums on manual issuance, not Mozilla. When > subscribers get tired of paying too

Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)

On Sat, Jun 8, 2024 at 6:29 PM Paul Wouters wrote: > > > On Jun 8, 2024, at 18:16, Watson Ladd wrote: > > > >  > > Could Mozilla update the root store policy to make clear that > > improvements like ACME shouldn't be extra cost items but instead > > considered part of the service provided to

Re: Financial incentive against security ( was Re: [EXTERNAL] Recent Entrust Compliance Incidents)

On Sat, Jun 8, 2024 at 6:15 PM Watson Ladd wrote: > On Sat, Jun 8, 2024 at 2:15 PM Mike Shaver wrote: > >"It would mean that revenue from the financial disincentive that Entrust > puts in place against Subscriber automation (I believe it's called > "SUB-PKI-CEG-ACME

Re: [EXTERNAL] Recent Entrust Compliance Incidents

On Sat, 11 May 2024 at 15:04, 'Chris Bailey' via dev-security-policy@mozilla.org wrote: > To that end, I want to confirm our intent to provide a full written > response to you and the community prior to June 7. > > o_o > a full written response to you and the community prior to June 7. > > o_O

Re: when do things really need to be revoked? who decides?

ave caused > outages by revoking if we didn’t think the revocation would meet the bar > required for a delayed revocation report or if there is a key compromise > (requiring 24 hour revocation). > > > > *From:* dev-security-policy@mozilla.org *On > Behalf Of *Mike Shaver >

Re: when do things really need to be revoked? who decides?

stand > why a capitalization issue is requiring a cert rotation. The worse the > issue, the faster and easier to get permission. > > > > *From:* Mike Shaver > *Sent:* Thursday, May 30, 2024 9:23 AM > *To:* Jeremy Rowley > *Cc:* Wayne ; dev-security-policy@mozilla.org > *

Re: when do things really need to be revoked? who decides?

Have we actually seen any evidence that this is the barrier, and not just the Subscribers’ historic processes? It seems like the sort of thing that one would expect to be outlined in the per-subscriber detail expected by the BRs, but those tend to be extremely sparse on actually *why* the

Re: Vulnurability Disclosure - How does it happen?

Historically at least, Mozilla secure bugs are kept closed only while publishing the information would itself be harmful to the security of Mozilla’s users or others on the web. Relevant patches are out, etc. We held fuzzing tools back for a year or so because another major browser had a hard time

subscriber certificate agility KYC for CAs

I wanted to elaborate on a piece of my last message, specifically around issuance of certificates for uses that are not compatible with the misissuance revocation requirements specified in the BRs. We very commonly see that delayed revocation incidents are rationalized by CAs as being required

when do things really need to be revoked? who decides?

DELAYED REVOCATION IS TOO COMMON This is long enough, so I’ll spare readers dozens of links to delayed-revocation incidents collected in Bugzilla; we all know that pretty much any other incident that involves misissuance will come with a delayed-revocation chaser these days. In *many* of those

comment on Entrust_Issues wiki page

The page lists the following issue: “ 5. EV Certificate missing Issuer’s EV Policy OID - https://bugzilla.mozilla.org/show_bug.cgi?id=1888714 Entrust issued 1,963 EV TLS certificates September 11-22, 2023, without including an EV TLS CP OID. Root Causes were the misinterpretation of the EV

Re: evaluation of aggregate behaviour for CAs

Oh, I feel dumb for not searching the old Google group, considering that I used to subscribe to it. Thanks for that, I'll review those cases and see how they were brought forward. Mike On Thu, 2 May 2024 at 18:25, Andrew Ayer wrote: > Hi Mike, > > On Thu, 2 May 2024 17:09:42 -04

Re: evaluation of aggregate behaviour for CAs

On Thu, 2 May 2024 at 17:54, Watson Ladd wrote: > Bugzilla is not the place to look for this kind of conversation. In > recent memory I can recall Camerfirma > (https://wiki.mozilla.org/CA/Camerfirma_Issues and > mozilla.dev.security.policy) and I recall a few more that searching > hasn't turned

evaluation of aggregate behaviour for CAs

Hello, I have been re-reading the Mozilla root policy, which necessarily leaves substantial discretion to Mozilla as to when revocation of a root (or otherwise constraining it, if such capabilities existed) is appropriate. >From also reviewing a number of historical incidents in Bugzilla, it

Re: CA Incident Transparency and Public Audits

Thanks, Wayne. I think this sort of analysis is quite valuable for constructing a reliable history of behaviour when evaluating CA operational effectiveness. Where should it be kept longer-term? I wonder if there should be a per-root journal generated/maintained, to better help identify patterns