> On Jul 18, 2017, at 12:03 AM, Jeremy Rowley <[email protected]> > wrote: > > Hi Geoff, > > I'm not sure I understand your post. Are you commenting on the proposed > changes or what's currently in the document? From what I read, you'd like to > see the 24 hour rule remain except in the limited circumstances described > below?
The proposed changes, at least one version of them. Yes, keep the 24 hour rule but for these. > ---- > > I do think these timeframes are a bit loose. I wouldn’t like to see a CA > explaining “well, we tried to contact the customer, and they haven’t replied, > so we’re waiting the full fourteen business days” in response to being handed > a copy of the private key. Or if the actual domain owner appears and says > “hey, you issued a certificate for my domain and I didn’t authorize it” and > the CA then takes weeks to revoke. > [JR] Both of these events require revocation within 1 business day With the proposed changes, though, these are all Problem Reports that trigger investigations, and can take many business days to resolve. > However, I don’t think there’s so much of a problem in some specific cases: > - For item 1, the customer may voluntarily request a revocation at some time > in the future. The CA must still act on it within 24 hours of the requested > time. If the revocation is requested because of key compromise or change of > information (and so is not voluntary, it is mandated by the Subscriber > agreement), the following items control. > [JR] I don't see how this is allowed. The CA is required to revoke within 24 > hours under the current requirement and 1 business day under my proposal if > the subscriber requests revocation. However, I like this exception as the > subscriber can plan a specific time and date for revocation. > > - If the private key has been compromised, and the customer is contacted > within 2 business days and accepts the risk, the subscriber may delay > revocation for up to 1 week from the time the CA is first notified. (This is > item 3.) > [JR] The current timeline is 24 hours. I proposed 1 business day. Are you > saying that 2 business days is acceptable to Apple with a 1 week delay in > revocation from the date of notice? The times overlap, so from the moment of notice, you get 24 hours for a preliminary report, 2 business days to contact the subscriber, 3 business days to complete the investigation, and 1 week maximum before the certificate is revoked. If you can’t contact the subscriber, you get 24 hours from the end of the investigation to revoke, or a week, whichever is less. > > - If there is a material change to the certificate information other than the > DNS name, such as the address, I think the revocation can be delayed for up > to 10 business days from the date the information changed, to allow a smooth > changeover, if the customer requests it. This only applies if the previous > information was valid but has changed. (This is item 8 or 10.) > [JR] Thanks. 10 business days is fine with me as well. > > I think you want to word these like this. Otherwise you can end up in a > scenario where someone reports a key compromise to the customer, the customer > is required by the Subscriber Agreement to report it immediately to the CA > and request revocation, which is not a Problem Report, and it must be revoked > within 24 hours; but if it had been reported to the CA, it could have taken > up to 2 weeks. And of course if the reporter sees it’s not revoked fast > enough, the reporter can then go to the CA and say the subscriber is not > following their Subscriber Agreement, which might have consequences far > beyond one certificate. > [JR] Good point. > > For all other items, I don’t see why 24 hours is unreasonable for the actual > revocation. I think setting a deadline on any investigations caused by a > problem report is also a good idea, and think 24 hours for initial response > then 3 business days for final action is OK. > [JR] There are others. > a) Requiring revocation for non-payment seems counter-productive to the goal > of making revocation a technical control, not a business control. The CA is > forced to revoke within 24 hours if payment is delayed by a couple days > because of a violation of the subscriber agreement (#6). I think this is an agreement wording problem. A CA can word the agreement so that a delay in payment does not count as a violation. > b) If I put in my CPS that I will revoke 14 days after receiving notice of a > trademark being awarded to a third party (but not the domain name), then you > could argue that the CA actually only has 24 hours because revocation is > required by the CPS (the timing in the CPS is irrelevant). You can word the CPS to avoid this. > c) Similarly, if technical content presents an unacceptable risk, does the > timeline set for deprecation really control or does the 24 hour rule in this > section control? It should require revocation in accordance with the timeline > established by the CAB Forum. The determination of unacceptable risk is time based. You have to have revoked 24 hours after the time that the risk becomes unacceptable. > d) What does a fraudulently misleading sub-domain mean in the wildcard > context? We have to revoke within 24 hours of being made aware that this > circumstance. I'm not sure how that plays into the certificate problem > report. It effectively shortens the certificate problem report investigation > and revocation period into a single 24 hour period. My understanding is that once you’ve determined it is fraudulently misleading, the investigation is over, and the 24 hours start. > > I really think each revocation reason needs its own timeline, even if some of > them are duplicative. 24 hours seems reasonable for customer requested > revocations and key compromise events. However, other revocations should be > within a certain time after finishing the investigation (which should also be > capped) or within the time frame specified by industry standards. I'll draft > a revision for additional discussion based on your comments and re-circulate. I think in most cases, once you’ve decided to revoke, there is little benefit and much danger in waiting. _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
