[cabfpub] Revocation revamp

[Ryan Sleevi]

On Thu, Mar 19, 2015 at 7:20 AM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

>  Hi everyone,
>
>
>
> I think the Baseline Requirements need improvements on how CAs are
> required to handle certificate revocations, especially if the certificate
> issue is reported by security researchers. There needs to be a distinction
> between private keys exposed through an attack and where private keys are
> made vulnerable through an exploit (such as heartbleed).
>
>
>
> For incidents where the vulnerability has not been made public or where
> there is an exploit affecting the general user base, there should be a
> longer time period for revocation than 24 hours. For private keys being
> malicious misused, we should still have the 24 hour window.
>
>
>
> The length of time we permit for revocation should be strict enough to
> prevent abuse but flexible enough to permit investigation and patching in a
> timely manner. Plus, a less strict revocation deadline would encourage CA
> participation in the remediation efforts and reduce the panic created by a
> high-profile vulnerability. Right now, the 24 hour requirement is actually
> an incentive to exclude CAs from the remediation process as not giving CAs
> notice provides more time to remediate.
>
>
>
> One idea to make the revocation period flexible, something like requiring
> the CA to provide notice that the certificate will be revoked because of
> the reasons specified in Section 13.1.5 and then requiring revocation
> within one week after the announcement of an industry vulnerability and
> within 72 hours after public disclosure of the vulnerability is made.  This
> gives CAs time to participate in the discussions and ensures we still have
> a short revocation window for publicly disclosed threats.  Another idea is
> to simply expand the time by up to two weeks if the revocation is part of
> on-going investigation into an issue or a planned patch process.
>
>
>
> Thoughts?
>
>
>
> Jeremy
>

Thanks for bringing this up, Jeremy.

I think you're right, the current BRs put CAs in a nasty spot with respect
to investigating issues, which I think puts customers in a nasty spot with
regards to certs.

For example, 13.1.3 allows 24 hours for a CA to *begin* investigating an
incident, while 13.1.5 allows 24 hours for a CA to *revoke* a certificate.
When you combine the two periods, it would seem as if a CA only has 24
hours to make a decision and, if they're unable to get sufficient
information, must err on the side of revoking, because failing to revoke
may constitute a breach of 13.1.5.

For the sake of discussion, here's several hypotheticals:
1) A CA is informed that a certificate for example.com misrepresents the
Organization/Locality information. The CA needs time to examine the claim,
the vetting performed, and whether or not the claim is correct. However,
13.1.5 (8) / 13.1.5 (10) requires revocation 24 hours after a CA is "made
aware".
2) A copy of a court ruling regarding a domain name is sent to the CA,
pursuant with 13.1.5 (6). However, the CA needs to authenticate the
document to confirm its legitimacy and the status of the ruling.
3) A CA is notified of a possible phishing/fraudulent site using a
wildcard, pursuant with 13.1.5 (7). However, the site is inaccessible with
the CA tries to access it, and thus they're unable to initially confirm the
report.

Each of these cases have situations where a CA may have a Relying Party
report something as a concern, but require time to investigate. 13.1.3
recognizes the need for investigation, but leaves a gap for when
investigation and revocation happen. If the CA is unable to complete
investigation within the appropriate time, or when there are complicating
factors, a responsible CA will have to err on the side of caution (and
avoiding a qualified finding) by revoking the certificate.

That's probably not ideal.

On the other extreme, I can see cases where an Applicant/Subscriber
misrepresents the information to the CA in order to obtain a certificate,
under conditions that may cause the CA difficulty to investigate. The
Applicant/Subscriber would prefer the CA not revoke the certificate (we're
assuming a secretly nefarious Subscriber), and so the CA shouldn't simply
"not revoke" because it will cause the (nefarious) Subscriber difficulty.

In between are cases where there is a (good) Subscriber who would prefer
the CA not revoke within 24 hours due to organizational complexity, cost,
and disruption to Relying Parties, and the Subscriber is willing to accept
those risks.

There are also cases where a (good, but uninformed) Subscriber would be
willing to accept the risks while or after a CA investigates a claim, but
where Browsers or Relying Parties would view the Risks as unacceptably high.


Random dates/times for discussion:
- Within 24 hours of a report, a CA must begin investigating.
- Within 24 hours of an investigation starting, a CA MUST make a
preliminary decision known to the reporter and the Subscriber.
- Within 72 hours of a public disclosure of an issue, a CA MUST take
action. [Sets the upper bound at 72 hours of public disclosure; e.g.
Heartbleed type scenarios]
- Within 7 days of a preliminary decision, a CA MUST take action. [Sets the
upper bound at 1 day response + 1 day initial finding + 7 days final
finding]
- [Needs better wording] A CA must maintain a record of the investigation,
including communications with Relying Parties and Subscribers during the
course of an investigation.
- Some sort of special set of conditions in which a Subscriber MAY request
an extension, up to 7 days, but only for certain conditions. We'd probably
need to go down the list of 13.1.5 and consider security risks of an 'evil'
Subscriber and which cases the risk of harm to a 'good' Subscriber outweigh
those risks.

Basically, we want to find a solution that allows a "good" Subscriber
flexibility, without creating incentives for an "evil" Subscriber or an
"security incompetent" CA (e.g. who classifies everything as 'low/no
risk'), yet recognizing also that rational security professionals can and
do disagree about degrees of severities.

The above dates aren't necessarily things I think we'd be happy with, but
I'm just throwing them out to provide a more concrete point for discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150319/5e5d1a4a/attachment-0003.html>