Thanks Kathleen. We already offer short-lived certs (anywhere from 8 hours up), but they are not issued off a dedicated intermediate. It's a great suggestion, and we'll add it to the DigiCert plan.
Jeremy -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kathleen Wilson via dev-security-policy Sent: Wednesday, August 2, 2017 4:07 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert-Symantec Announcement On Wednesday, August 2, 2017 at 2:13:40 PM UTC-7, Jeremy Rowley wrote: > Today, DigiCert and Symantec announced that DigiCert is acquiring the > Symantec CA assets, including the infrastructure, personnel, roots, > and platforms. At the same time, DigiCert signed a Sub CA agreement > wherein we will validate and issue all Symantec certs as of Dec 1, 2017. Thanks for posting this information here. Pointer to DigiCert's blog: https://www.digicert.com/blog/digicert-to-acquire-symantec-website-security- business/ > Two things I can say we plan on doing (following closing) to address > concerns are: > > a. We plan to segregate certs by type on each root. Going forward, we > will issue all SSL certs from a root while client and email come from > different roots. I would like to see all CAs move in this direction. > We also plan on limiting the number of organizations on each issuing > CA. We hope this will help address the "too big to fail" issue seen > with Symantec. By segregating end entities into roots and sub CAs, > the browsers can add affected Sub CAs to their CRL lists quickly and > without impacting the entire ecosystem. This plan is very much in > flux, and we'd love to hear additional recommendations. I greatly appreciate your consideration in this area! Perhaps there can be different subCAs for large organizations versus smaller/individual site operators (that might be covered as different brands). Of course, I'm always in favor of technically-constrained subCAs for the large organizations. And perhaps one (or more) of the subCAs can be dedicated to short-lived SSL certs, similar to Let's Encrypt? > b. Another thing we are doing is adding a validation OID to all of our > certificates that identifies which of the BR methods were used to > issue the cert. This way the entire community can readily identify > which method was used when issuing a cert and take action if a method > is deemed weak or insufficient. We think this is a huge improvement > over the existing landscape, and I'm very excited to see that OID rolled out. I would like to see all CAs move in this direction as well. Looks like you are going to be very busy! :-) Thanks, and good luck! Kathleen _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
