Re: [lamps] Revocation Request Format?

[Ryan Sleevi <[e-mail]>]

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.

>