[cabfpub] Revocation ballot
sleevi at google.com
Thu Jul 13 15:31:40 MST 2017
On Thu, Jul 13, 2017 at 5:48 PM, Jeremy Rowley
<jeremy.rowley at digicert.com> wrote:
> I thought the goal was to start heading to a responsible disclosure model where the revocation timeline is a balance of public dissemination of information compared to the need for certificate holders to remediate the issue, actively engaging the CA early instead of waiting until revocation is required. Right now, there's a strong incentive not to tell the CA about compromise events because it starts the 24-hour window.
I'm not really sure I understand where the disincentive is?
Are you talking about subscribers being disincentivized to tell their
CA that their key was compromised? They're already obligated to do so,
under the Subscriber Agreement, so I'm not sure how that changes. The
Subscriber still wants to ensure timely revocation of their key, since
it impacts their customers/clients/Relying Parties.
Are you talking about security researchers being disincentivized to
report customer compromise to CAs? That seems like the right incentive
- the researcher should work with the affected parties, since they're
the ones that would need to rotate keys, examine impact, etc - and let
those subscribers contact the CA.
Why tell the CA that their Subscriber was compromised, rather than the
Subscriber themselves? Alternatively, if the Subscriber _is_
compromised, then it's absolutely the correct incentive for the
researcher to report this directly to the CA, so that Relying Parties
are not mislead, regardless of what steps the Subscriber steps.
> For non-public issues, I'd rather work with the customers earlier than wait to be brought in until 24 hours before the revocation occurs.
Could you explain or provide an example of this? As the CA - a service
provider role - naturally being brought in the end of a
customer-impacting issue is the right way to handle it.
> Could we balance the issue to say within 24 hours of public disclosure or within two weeks of receiving a certificate problem report where the CA confirms that one of the reasons under Section 4?
When we past discussed this, my understanding of the conclusion was
that the CA would be afforded up to two weeks to investigate the
problem report (with the requirement additional details about why the
delay occurred being made public), but that upon determining it met
one of the revocation reasons, was obligated to make the timely
revocation under 184.108.40.206/220.127.116.11.
If I understand your proposal, it would be that if a CA determines the
Subscriber (or Subordinate CA) meets the requirements of 18.104.22.168, they
could still delay for up to two weeks before revoking, is that
How does that benefit Relying Parties?
More information about the Public