On Mon, Mar 5, 2018 at 12:10 PM okaphone.elektronika--- via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> On Monday, 5 March 2018 15:44:20 UTC+1, Eric Mill wrote: > > I think it probably makes more sense to focus on sensitive key material > > than non-sensitive CSRs. > > > > As a starting point, how reasonable would it be for CAs to question their > > resellers, or to disseminate additional language to add to their reseller > > agreements to prohibit non-transactional/ephemeral key storage? > > > > -- > > konklone.com | @konklone <https://twitter.com/konklone> > > I remember I read somewhere in the discussion about this incident that > Trustico also may have taken normal CSR's from their customers and replaced > them with CSR's they generated. Which would typically go unnoticed as they > then after singing provided a file (pem or whatever) that could be put on > the users webserver "without any further hassle". That is, they private key > in that file would be the one Trustico used for that replacement CSR and > not the one the customer provided. So, ehm... it worked. ;-) > I think unfounded speculation such as this is actively harmful. Extraordinary claims deserve some evidence. Otherwise, it makes discussion no better than an angry mob, particularly because of the technical challenges. I do not know if that is truly what happend. But if it is, it would explain > why some people on reddit persisted in saying their key could not have been > compromised as they never gave it to Trustico at all, but they still got > the notification E-Mail that their certificatie was about to be revoked. A much simpler explanation is one already echoed on the list. Trustico requested revocation for all the certs they sold, but could only provide the keys for the certs they generated. Yet because they requested it for all, and stated compromise, an email was sent to those customers - even though no evidence of compromise had been provided. > > I don't know if it's worth investigating that angle any further, but it's > perhaps a scenario worth considering in this context. For the reseller > would strictly not be storing private keys of such subscribers. > > CU Hans > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
