Re: [lamps] Revocation Request Format?

[Ryan Sleevi <[e-mail]>]

On Mon, Mar 5, 2018 at 5:49 AM, Stephen Farrell <[e-mail]>
wrote:

>
> Coupla minor notes below...
>
> On 05/03/18 09:31, Tim Hollebeek wrote:
> > I agree with this.  There’s no need to rush into anything as no
> > buildings are currently burning down, but some of the things people
> > are doing are slightly silly, and it would be worthwhile to come up
> > with a set of potentially non-silly things, and look at the
> > advantages/disadvantages of each.
> >
> >
> >
> > It might be good to start with a Use Cases document first, to figure
> > out who the participants/constituents would be.
>
> I'm not convinced that a use-cases document/draft would be useful,
> just on the basis that, in the IETF context, those often tend to
> produce text that ends up ignored (or OBE). But if someone has the
> interest and cycles to write such text, then that's up to them and
> maybe it'd be useful in this case, not sure. When it exists, I guess
> I'd read it.
>

Yeah, apologies, document was a bit to overloaded a term in the IETF sense
:) I meant that because this problem space is broad, and because the
original motivation (Trustico) isn't really addressed by
yet-another-format, in order to have discussion about the value of a
format, we should try to figure out what problem(s) trying to be addressed.

I tried to offer one ontology - revocation for non-compromise (certificate
lifecycle management), revocation for compromise by 1P (certificate
lifecycle management), revocation for compromise by 3P (incident
reporting). In that final category, I tried to distinguish types of
compromise (disclosure of private key vs signing oracle), and the policy
implications related to incident response. While the original framing was
posed as 1P, the facts available at the time of initial post identified it
was 3P - although the requestor in that incident viewed is as a revocation
request for non-compromise.

Identifying the problems trying to be solved would help identify whether
they are already addressed in other specs (e.g. ACME's definition of the
CLM interfaces), or whether there are unaddressed needs, and for what cases.

While I don't think that deserves formal publication, it does seem to
benefit from having a shared vocabulary for the problems - much like the
W3C WICG's notion of "Explainers" that try to define the problem and
demonstrate the solution, but are not themselves standardized - they're
just used to help ensure productive discussion of the spec.