[cabfpub] Revocation ballot

[Jeremy Rowley]

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.

[JR] We often get involved directly with our customers on the certificate 
management and deployment-side. Thinking of the CA as only the certificate 
manufacture undervalues the services some CAs provide. Forcing CAs out of the 
advisory role and solely into the issuance role eliminates a lot of the value 
provided. Therefore, we would like to get involved early in the process with 
both the researchers and the Subscribers to advise on all PKI issues. 
Although subscribers have an obligation under the agreement to report 
certificate issues, we know this doesn't always happen. Take Heartbleed for 
example. We received minimal prior notification of the event. However, when 
the event was announced, we released a tool that detected certificate 
impacted.  With advanced notice, we can assist customers in navigating both 
industry and internal events.

> 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.
[JR] There's a consulting role involved as well as a certificate issuance 
role. Many of our customers approach us with questions on the use of PKI and 
best practices.  Heartbleed is an example. We'd like to remain a consultant in 
the framework.  Another consideration is the CA is easy for a researcher to 
contact and report issues to. We have dedicated emails and personnel who 
handle these issues.  For example, Hanno emailed me directly about compromised 
private keys. I have no problem with this. To my knowledge, he did not reach 
out to the subscribers themselves. I also have no problem with this.  As the 
CA, we generally are the ones helping our customers with the certificate 
needs, including helping them through the revocation process.

> 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 4.9.1.1/4.9.1.2.
[JR] What if the certificate was deployed to 1000+ servers? If the private key 
is not disclosed, but there is a need to revoke, giving them time to manage 
the revocation minimizes the impact on relying parties. I generally don't need 
two weeks to investigate the problem. What I need is two weeks to migrate the 
customer to a better practice, which is then followed by revocation.

If I understand your proposal, it would be that if a CA determines the 
Subscriber (or Subordinate CA) meets the requirements of 4.9.1.1, they could 
still delay for up to two weeks before revoking, is that correct?
[JR] Sort of - I propose 4.9.1.1(1) and 4.9.1.1(2) (and corresponding sections 
under 4.9.2.2) require revocation within 24 hours. In both cases, the customer 
requested revocation.  That really should be immediate. What I'm proposing is 
the CA could delay two weeks for things like a subscriber agreement breach or 
if certificate information changes (such as a change in address).

How does that benefit Relying Parties?
[JR] It prevents critical systems from being shut off before the server 
operator can migrate to a new certificate.  It's an attempt to balance risk of 
misuses (a non-public event is less risky) with the desire to keep all 
infrastructure secured. The result of revocation is usually a move to no 
encryption rather than some new encryption - especially if revocation was for 
something like a change in address.

Jeremy

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Thursday, July 13, 2017 4:32 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Revocation ballot

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 4.9.1.1/4.9.1.2.

If I understand your proposal, it would be that if a CA determines the 
Subscriber (or Subordinate CA) meets the requirements of 4.9.1.1, they could 
still delay for up to two weeks before revoking, is that correct?

How does that benefit Relying Parties?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170713/9554a07e/attachment-0001.p7s>