Re: [lamps] Revocation Request Format?

It seems signing a new CSR has been a common practice as proof of
possession.

There's one segment of users that want to have a time-constrained request
(that is, incorporating a challenge/response), while another would prefer
that you can generate the 'request to revoke' at the same time you request
the cert, so that you can use this token for situations such as loss of
private key (but not loss of revocation token)

It doesn't seem like there needs to be a bespoke format here, considering
that the industry is still working through its use cases, and any signed
data is sufficient.

Further, it may do harm to try and standardize that. Consider the ROBOT
attack ( https://robotattack.org/ ), which presented a signing oracle with
TLS private keys. Prematurely constraining revocation requests to a
particular format might otherwise preclude reasonable demonstration of
private key compromise.

So I don't think there's anything for LAMPS to do here - we have ample
available technology (running code that already works) and we have not yet
ascertained industry needs in any meaningful way (no rough consensus for
something new)

On Fri, Mar 2, 2018 at 9:24 AM, Phillip Hallam-Baker <phill@hallambaker.com>
wrote:

> Do we have a PKIX revocation request format?
>
> I am asking because of a detail in the Trustico situation in which a file
> of 23K private keys was emailed to a CA to request revocation.
>
> At the point, the circumstances of that situation are not clear. But I can
> see a scenario in which it is entirely plausible that a CA reseller would
> have access to large numbers of TLS private keys and that is when they are
> either hosting or managing the Web sites.
>
> The management interfaces that allow Web sites to be wheeled around a data
> center have become very sophisticated of late with virtualization and much
> of that infrastructure is 'secret sauce'.
>
> What might appear to be a five racks of 100 separate machines is likely
> visible in the management console as one single entity.
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>
>