Even taking Entrust's statements in the past hour at face value we have an issue. At no point have they communicated this change or even implied it was happening despite questioning over the matter for weeks. There is not a single mention like this in their formal report.
There is a serious culture issue at play internally and it needs to be addressed. I said I gave Entrust every opportunity to explain. Why did it take until now for some semblance of an excuse to appear? Not only that but we're being told that in incident 1897630 <https://bugzilla.mozilla.org/show_bug.cgi?id=1897630> that different incident response processes were being followed. This does match the statements in there that everything was ad-hoc, and emphasizes that incident response processes are not being followed internally even at this stage. I do however appreciate that Entrust have finally brought in their emergency planning personnel several months late, I wish them the best of luck. - Wayne On Friday, June 14, 2024 at 9:55:38 PM UTC+1 Bruce Morton 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 and are disturbed that you would attribute > "malicious" motives to any of our actions. The "30 day revocation" option > is a standard option for subscribers in our system that allows them to > replace certificates safely before revoking. In normal course, a subscriber > would just leave them in this "bucket”, and they would automatically be > revoked. When we posted the letter originally, we shared it as an example > of what was sent from us directly to a subscriber and was not posted in the > public domain. We were being transparent by sharing the message. The > redacted section provides specific instructions to our subscribers on how > to revoke and reissue certificates. > > “Revoke within 30 days” was one of two options in the tool. Certificates > placed in this status were reissued within 30 days of when they were placed > in this status; we revoked them sooner if their extension time was reached, > or if the subscriber confirmed they had reissued. > > Prior to April 4, 2024, customer could only select "Revoke immediately" or > "Revoke in 30 days". The default for use in the instructions on March 18 > 2024 was "Revoke in 30 days". Recognizing, this may have been perceived by > customers that they then had 30 days vs the 5 day timeline that was > communicated, Entrust implemented a change to add "Revoke in 3 days" as the > default moving forward to be called out in the event of future > mis-issuance. > > [image: Revoke in 3 days.png] > > These updated instructions with the use of the ‘3 day’ revocation button > were used when communicating with subscribers for Bug 1897630. > > *“Complete the Reissue and select "Revoke in 3 days"* so your production > certificate maintains validity and provides you with sufficient time to > perform the replacement. Note: This does NOT mean your certificate will be > valid for another 3 days. It is just a mechanism to not immediately revoke > your certificate during the replacement process.” > > The full communication can be review in the attached. > > On Friday, June 14, 2024 at 10:11:34 AM UTC-4 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’ll have to go double check everything in your correspondence here, but > if this is all true then this is deeply unsettling and concerning. > > Root program, I implore you to expedite the processing of these issues: If > the concealment of the revocation information was willful, then there’s no > reason to believe that Entrust hasn’t also acted maliciously in other > areas. > > Amir Omidi (he/them) > > > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/4b46ec7d-77c8-4c38-a170-bdbb5e9f8c0bn%40mozilla.org.
