[cabfpub] Revocation ballot

[Jeremy Rowley]

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.  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 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?  

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Thursday, July 13, 2017 1:37 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

Hi Jeremy,

I think you may have misunderstood. That is, I think that at any point the CA determines any of the conditions on 4.9.1.1 or 4.9.1.2 are met, they should remain obligated to revoke within 24 hours. That includes the full list.

I think greater time for the investigation of a certificate problem report - which allows for ascertaining whether or not 4.9.1.1 or
4.9.1.2 have been met - is reasonable, because as it stands, CAs are obligated to err on the side of revocation (and assume 4.9.1.1/4.9.1.2 will be true) rather than not.

I don't think it's a positive step forward, however, to suggest that a CA may opt to _not_ revoke, or to delay revocation beyond 24 hours, once 4.9.1.1 or 4.9.1.2 are met. I'm particularly troubled, for example, by the suggestion that the impact of revocation be considered
- as that's entirely a subjective, unquantifiable, and arguably unsupportable interpretation in general, and it creates a perverse incentives, as the incentives of both the CA and the subscriber are to 'not' revoke an illegitimate certificate, even if it causes substantial harm to the ecosystem or Relying Parties.

It's unclear, however, if it was your intent to do that. My understanding is that the goal was to provide additional time for a CA to investigate the facts surrounding a Certificate Problem Report, so that they can fully determine whether 4.9.1.1/4.9.1.2 are met - not to make it possible for a CA to 'never' have to revoke a certificate (which is a natural consequence, as presently worded).

On Thu, Jul 13, 2017 at 3:24 PM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> Thanks Ryan - I missed that.  IMO, we should leave the cap at 1 business day (or even 24 hours) for those two events.  If the subscriber is requesting revocation, there's no reason to delay.
>
> I don't mind adding a two week cap for the rest of the reasons if that helps.
>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi at google.com]
> Sent: Thursday, July 13, 2017 1:19 PM
> To: Jeremy Rowley <jeremy.rowley at digicert.com>; CA/Browser Forum 
> Public Discussion List <public at cabforum.org>
> Subject: Re: [cabfpub] Revocation ballot
>
> Hi Jeremy,
>
> This seems rather problematic. I greatly appreciated DigiCert's past consideration of this, which was to set the absolute upper bound at no greater than two weeks.
>
> As proposed, this would effectively make 4.9.1.1 and 4.9.1.2 pointless, as it leaves it fully up to CA discretion. As we've seen with the validation methods' "any other method", CA discretion creates significant challenges for relying parties and auditors to be assured of the integrity of the Web PKI and of the technical and material factors weighing in.
>
> That is, I'm totally supportive of an approach that tries to balance
> 24 hours, but I think anything that allows for arbitrarily-determined revocation, as proposed, would be a big step backwards for the security and confidence in the PKI.
>
> On Thu, Jul 13, 2017 at 2:47 PM, Jeremy Rowley via Public <public at cabforum.org> wrote:
>> Hi all,
>>
>>
>>
>> I took Ben’s previous ballot proposal for changing revocation 
>> timelines and combined it with the timelines previously proposed.
>> Basically, the timelines were established to still require CA 
>> responsiveness but balance with compromise notices that are received at weird hours or during holidays.
>>
>>
>>
>> Looking forward to your comments.
>>
>>
>>
>> Jeremy
>>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
-------------- 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/a0050bd1/attachment.p7s>