[cabfpub] Ballot 213 - Revocation Timeline Extension

Ryan Sleevi sleevi at google.com
Wed Sep 13 18:07:16 UTC 2017


On Wed, Sep 13, 2017 at 1:50 PM, Jeremy Rowley <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> wrote:
>
>
>
> On Wed, Sep 13, 2017 at 1:24 PM, Jeremy Rowley via Public <
> 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/26574369/attachment-0003.html>


More information about the Public mailing list