[cabfpub] Ballot 213 - Revocation Timeline Extension

Wed Sep 13 18:14:54 UTC 2017

If we’re trying to require transparency, I’d rather see a requirement to publish all certificate problem reports within 24 hours, regardless of resolution. First, this accomplishes the goal in a more straight-forward manner. Second, publication separates the transparency goal from the resolution timeline frames. 

24 hours to publish

24-7 days to investigate/fix

24-7 days to revoke

The other question is where should these be published.  The CAB Forum questions list seems like the wrong place. The CAB Forum isn’t the mis-issuance police (the browsers are).  The questions list in particular is intended for third party questions about the CAB Forum requirements. The Mozilla dev list is a better place to publish. If that’s the case, wouldn’t a publication of certificate problem reports be better presented as a Mozilla root store requirement? 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Wednesday, September 13, 2017 12:07 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

On Wed, Sep 13, 2017 at 1:50 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

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? 

I think there is and should be. For example, if we have QIIS's with different information, then it matters to those who rely on CAs to provide accurate information to understand what the QIISes are that a CA uses.

Understanding how (different) CAs address this problem - and whether these solutions provide the expected level of assurance - is useful.

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.

I'm not sure I agree with that. If anything, if a CA provides a quick resolution ("QIIS A states that the Address is A"), then it provides sufficient detail to allow the reporter to demonstrate that ("QIIS B states that the Address is B").

I think we should continue to err on the side of transparency in both policy and remediation, so that we can ensure there is a sufficient level of consistency amongst CAs, and that there is sufficient clarity as to what the expectations are.

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/a8e53fcb/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4984 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170913/a8e53fcb/attachment-0003.p7s>