Re: [lamps] Revocation Request Format?

[Phillip Hallam-Baker <[e-mail]>]

On Sat, Mar 3, 2018 at 1:34 PM, Ryan Sleevi <[e-mail]> wrote:

>
> On Sat, Mar 3, 2018 at 12:07 PM Phillip Hallam-Baker <
> [e-mail]> wrote:
>
>> On Sat, Mar 3, 2018 at 1:29 AM, Stephen Farrell <
>> [e-mail]> wrote:
>>
>>>
>>>
>>> On 02/03/18 22:33, Ryan Sleevi wrote:
>>> > That's why I think an effort to standardize there is bad, not good,
>>> because
>>> > it counterintuitively fragments the ecosystem, without addressing the
>>> > general issue, which is in my view is moreso a matter of policy,
>>> because of
>>> > the inherent constraints of 2).
>>>
>>> FWIW, I don't agree with your conclusion that *any* standardisation
>>> of revocation signals would be counter-productive, but I also don't
>>> think we ought do any such standardisation unless there are a bunch
>>> of CAs and writers of private key handling s/w who do in fact want
>>> to use the same new format for revocation signalling. I don't see a
>>> whole bunch of CAs and others wanting that right now.
>>>
>>> So in the short term, I think we agree as to what to (not) do:-)
>>>
>>
>> ​At this point, the incident that motivated this proposal happened 4 days
>> ago. So it would probably be a mistake to bang out a draft and promote it
>> to RFC.​
>>
>> ​What I was most interested to know is if we had done the work already
>> and the answer appears to be not in PKIX​ but possibly in ACME. It might
>> just be that all we need to do is to add a few paragraphs to ACME and maybe
>> get an IANA content type for whatever the standalone message blob is.
>>
>>
>> I do think we will need to standardize because we are almost certain to
>> want to pop these blobs in our CT logs at some point and it is in any case
>> the right thing to do. One code path is always better than five code paths
>> offering the same functionality.
>>
>
> It might be good to start with a Use Cases document first, to figure out
> who the participants/constituents would be. This would align with Stephen’s
> remark re: what writers of private key handling s/w should use. Considering
> such solutions naturally preclude solving (some of) the “compromise”
> scenarios that must be dealt with today, the merits of those use cases
> could be independently evaluated before trying to shape such work.
>
> I view the transparency aspect as similarly orthogonal - such transparency
> is more beneficial for demonstrating the private key holder authorized a
> revocation. In today’s Web PKI, that is a real problem with CAs
> unilaterally revoking for specious reasons (“malware”, “customer stopped
> paying monthly fee”, “we added a new domain name to the customer account”)
> or Resellers, often misguided, requesting revocation per the terms of their
> contract with the CA without regard to whether or not the Certificate
> recipient desires it.
>
>>
​The customer's credit card having been declined due to fraud or a
chargeback for fraud is actually one of the most potent signs indicating
that the certificate is likely to be used maliciously.​