Thanks Wayne. Happy to update with that information. We’ll try to provide it all be end of the year, definitely before Jan 12. I can answer two of these generally now:
* Reason that publicly-trusted certificates are in use - They are used on websites and infrastructure accessed through browsers. There are some that don’t need to be publicly trusted certificates, but the systems still check revocation. If Mozilla blocked the certs, the impact is minimal. If the certificates are revoke, the infrastructure goes down. Would you like me to identify which ones could be blocked by Mozilla vs. revoked? * Reason that the provision for 30-day certificates isn't helpful - The blackout periods don’t allow any change in infrastructure so replacing the certificates is just as difficult as changing the domain names. Even large non-tech companies don’t have a ton of automation so it’s not surprising that they’ll need more days to replace the certs if their blackout period ends the 12th. Of course, I’ll provide further information in the incident report as more specific information comes in. From: Wayne Thayer <wtha...@mozilla.com> Sent: Thursday, December 20, 2018 9:04 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: r...@sleevi.com; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Underscore characters Jeremy, On Wed, Dec 19, 2018 at 10:55 PM Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Done: https://bugzilla.mozilla.org/show_bug.cgi?id=1515564 Thanks for submitting this. It ended up being about 1200 certs total that we are hearing can’t be replaced because of blackout periods. These 1200 are only the ones that can't be replaced by Jan 15th and will cause outages if revoked then? I don't think the information you've supplied is anywhere close to what Ryan asked for or what the community needs in order to make the decision you're asking for. I'm looking for specifics on why every cohort (i.e. every deployment scenario for every customer requesting an extension) of these certificates can't be revoked, such as: * Specific per-customer change freeze dates and the rationale for them * Explanations of the effort and risk involved in replacing them * Reason that publicly-trusted certificates are in use * Reason that the provision for 30-day certificates isn't helpful Only with this information can we have some assurance that any exceptions are limited to the bare minimum and that we're able to learn and improve. Without this information, we're still in the situation of blindly trusting DigiCert to do the right thing, which is no different than having a CA report an incident after the fact. Is it realistic to expect that you can provide the level of detail that Ryan and I are requesting prior to 15-Jan? From: Ryan Sleevi <r...@sleevi.com <mailto:r...@sleevi.com> > Sent: Wednesday, December 19, 2018 11:05 AM To: Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > Cc: r...@sleevi.com <mailto:r...@sleevi.com> ; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Underscore characters Look forward to seeing and discussing once the full scope of the request is shared. On Wed, Dec 19, 2018 at 12:21 PM Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> <mailto:jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > > wrote: We will post the full list of exceptions today. One of the big factors should be the risk to the industry/community if the certificates aren’t revoked. Perhaps we can identify what the risk to the community is in revocation delays first? There’s no need to know the exact certs to talk about what the risk associated with underscore characters is. Could you please explain the risk to the community in a revocation delay as the “unreasonable” argument isn’t really supported without that understanding.
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
