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? ----
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 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? - 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). 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). 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. 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. 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. Thanks!
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
