[cabfpub] R: Re: Revocation revamp

[Adriano Santoni]

I fully concur. 


Inviato da Samsung Mobile.

<div>-------- Messaggio originale --------</div><div>Da: Ryan Sleevi <sleevi at google.com> </div><div>Data:19/03/2015  18:00  (GMT+01:00) </div><div>A: Jeremy Rowley <jeremy.rowley at digicert.com> </div><div>Cc: public at cabforum.org </div><div>Oggetto: Re: [cabfpub] Revocation revamp </div><div>
</div>

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: https://cabforum.org/pipermail/public/attachments/20150319/0bbe9719/attachment.html