I'm not really sure I agree that there should be multiple tiers of revocation, but just to go along with the thought experiment..
If there were, "key compromise" is definitely not the only case I'd want on the more aggressive schedule, I'd also want to include cases where there was a failure in DV and the rightful owner of a domain wanted the cert revoked. Alex On Wed, Aug 9, 2017 at 10:19 AM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> 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. > > > On Aug 9, 2017, at 1:10 AM, Paul Kehrer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > >> On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote: > >> 24 hours is super short when it's a Saturday morning at 4 am and it’s a > European government entity. I agree that is what the policy says now, but, > for lower risk items, the policy should change, preferably to at least one > business day. > >> > > > > It is short, but any CA possessing global trust should already have > procedures in place for handling revocation in a prompt manner. It seems > odd that it would be onerous for them to revoke a non-compliant > certificate. The only difference is a need to confirm to the CA's > satisfaction that the given certificate is in violation of the BRs, which I > would expect any competent CA to be eminently capable of doing. > > > > -Paul > > _______________________________________________ > > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
