[cabfpub] Ballot 213 - Revocation Timeline Extension

[Jeremy Rowley]

Not that a QIIS is slow to provide information but the QIIS may be slow to  update. For example, one QIIS may say the address is A. A second may state the address as B. Resolving the different information takes time. Is there much interest from the CAB forum perspective on this issues?

Requiring reporting on this issues has the added disadvantage that it encourages a quick resolution (a determination that the address remained unchanged) rather than a thorough investigation about the changed info.

On Sep 13, 2017, at 10:44 AM, Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>> wrote:



On Wed, Sep 13, 2017 at 1:24 PM, Jeremy Rowley via Public <public at cabforum.org<mailto:public at cabforum.org>> wrote:
A 24 hour report to the CAB Forum doesn’t make sense if the length of the investigation is not tied to the understanding/interpretation of the CAB Forum requirement.  For example, if someone alleges a company changed addresses, revocation may be required under “information appearing in the Certificate is inaccurate or misleading”.  Information in the QIIS might not be updated, the contact person may be on vacation, etc.  This isn’t a CAB Forum issue so there’s no reason to report that it’s taking longer than 24 hours to complete the certificate problem report.

What should be required, imo, is a report to the entity submitting the certificate problem report about why it’s taken longer than the required 24 hours.  For investigation, what if we did:

  *   24 hours required for the initial report
  *   24 hours for the final report if the problem alleges X, Y, or Z
  *   7 days for the final report for all other reasons.

Anything taking longer than 24 hours because of an issue with the CAB Forum requirements, must be reported to the CAB Forum.

Then revocation stays at:

  *   24 hours required for X, Y, and Z
  *   24 hours SHOULD for all other reasons
  *   7 days required for all other reasons

Will this work?


I'm not sure I agree with that. That is, if someone is having trouble looking up information in a QIIS, then I think there is an expectation that CAs should be able to have process and controls to be able to confirm that information in a timely fashion. If, for example, the QIIS is particularly slow, then having a public discussion allows for opportunities to share information, such as whether CAs are using another QIIS to address this gap, or whether automated solutions exist, or whether an opportunity exists to feed that back to a QIIS.

I'm suggesting that, as an industry, we benefit most from information sharing, particularly around the challenges faced to ensure users are kept secure.

The ontology of whether or not it's a CA/B Forum issue is problematic, because one CA may argue it's a CABForum problem can easily vary between two CAs with the same problem. One may view it as a Forum problem that our definition of QIIS precludes certain automated sources (which might allow for a more rapid response), while another may view it as an external problem.

Similarly, if CAs are routinely getting 'bad' problem reports, having transparency about that allows the CA/Browser Forum to respond, as an industry, on potential solutions for that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170913/a4ab3ea4/attachment-0003.html>