Looking at it another way, the timelines are:
24 hours if the Subscriber requests the cert (no certificate problem report) 48 hours if there is a key compromise (24 hour investigation + 24 hour to revoke) 8 days if the cert was issued to the wrong domain name or organization (7 day investigation + 24 hours to revoke) * 14 days for all other reasons * My heartburn over how long this is to take care of. 8 days is a long time where domain validation failed. I think the requirement to reply to the certificate problem report is built in by requiring the CA to work with the entity making the report. I don’t have a good idea on how to improve the escalation path. From: Ryan Sleevi [mailto:sle...@google.com] Sent: Wednesday, August 23, 2017 1:33 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: CA/Browser Forum Public Discussion List <public@cabforum.org> Subject: Re: [cabfpub] Revocation ballot v2 On Wed, Aug 23, 2017 at 3:25 PM, Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > wrote: Hmm - that does seem long. What if we keep the investigation to 24 hours and change revocation to 24 hours/2 weeks? There’s no reason for the CA to delay investigating any issue. I wasn't trying to suggest it's long. I think we've seen some CAs want to investigate, such as relevant RFCs, errata, document and change control history, etc. That it is bounded at an upper-bound (by 14 days) keeps it within a reasonable frame. If a CA wants more time, they should be proactively internally reviewing for compliance :) For transparency, what do you suggest? I left it the same as today. Perhaps state that the CA MUST reply to the certificate problem reporter about its decision within 3 days? I know we'd previously talked about reports to public@cabforum.org <mailto:public@cabforum.org> , in line with how 9.16.3 is handled for local law, but the fact that we have a maximum cap at 14 days for revocation does, I think, reduce the risk. I'm also sensitive to the fact that running any form of 'security bug queue' will result in absolutely terrible submissions that are fundamentally incorrect, and I don't want to further impose additional costs for having to deal with junk-reports. My concern is that CAs who receive problem reports would be incentivized to close them as "not an issue", and thus force the root stores to get involved, but that's arguably the status quo today. I think root stores that want to address this would have a variety of tools - for example, requiring quarterly disclosures of the number of problem reports received, responded to, etc - that could address some of those high-level concerns, hopefully without introducing significant burden for junk reports. After all, today, if a CA gets a junk report, there's also zero disclosure requirements - so I'm not terribly convinced we need to solve that problem as well, provided that the cap at 14 days stands.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
