On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote: > All CAS are required to maintain the capability to process and receive > revocation requests 24x7 under the baseline requirements. The headache is not > with the CA. Rather, it's notifying the customer that their certificate will > be revoked before the start of the next business day. Having a one to two > business day rule instead of 24 hours for non compromise issues gives the > end entity time to receive the notification and replace their certificate > with a compliant version.
I'm sure many customers would absolutely prefer that and on the surface it does sound like a good solution. However, I think it's another example of the general difference of opinion between people on this list around whether we should be holding CAs to the highest standards or not. These mis-issued certificates are typically not a security concern, but they speak to either ignorance on the part of CA operators or a pattern of lackadaisical controls within the issuance systems. Neither of these is acceptable behavior at this juncture. Conformance with the BRs has been mandatory for over 5 years now. Customers need to be made aware of the failures of their chosen providers and the responsibilities incumbent upon them as subscribers, and if their own certificate installation/replacement processes are sufficiently archaic as to make it difficult to replace a certificate in an automated fashion then they should rectify that immediately. That said, to continue the thought experiment, what does "1-2 business days" really mean?Does the CA get 1-2 business days followed by 1-2 for the customer? What if there's a holiday in the CA's country of operations followed by a holiday in the customer's home country? How quickly does this window extend to 2+ weeks? If you were to go down this path I'd strongly prefer it to be a hard deadline (e.g. 72 hours) and not anything related to business days. -Paul _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
