Re: [lamps] Revocation Request Format?

Ryan Sleevi <ryan-ietf@sleevi.com> Mon, 05 March 2018 14:26 UTC

Return-Path: <ryan-ietf@sleevi.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B26E12D80F for <spasm@ietfa.amsl.com>; Mon, 5 Mar 2018 06:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MItvxh8GIOrE for <spasm@ietfa.amsl.com>; Mon, 5 Mar 2018 06:26:13 -0800 (PST)
Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741CA1270AB for <SPASM@ietf.org>; Mon, 5 Mar 2018 06:26:03 -0800 (PST)
Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id C59A120047618 for <SPASM@ietf.org>; Mon, 5 Mar 2018 06:26:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=WHxvihJ6WRbMYWHW/O0oTb0sAWg=; b= h2ABgR54jVmqT2oDXY4XkKXMNKzynMJc8F10ZsQSq1knb1DW3y7qqA8Ce0W3xzC2 w5WRUHeOLNXdOQFR3LhDqTA+3Sr6DOTSWPg5X152R9B6jCyNJCvZNMjrnol9cn8i ssCbtJWSZRMC3QNqAlmVqC4IkH1dyOewoPYy1HrbcOg=
Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id B62CD20047613 for <SPASM@ietf.org>; Mon, 5 Mar 2018 06:26:02 -0800 (PST)
Received: by mail-io0-f178.google.com with SMTP id v6so18146807iog.7 for <SPASM@ietf.org>; Mon, 05 Mar 2018 06:26:02 -0800 (PST)
X-Gm-Message-State: APf1xPDBAWVZmBwk2aY7BMPn8n3/i+qA9UEwMGUWTa7xfmrUnntmevzP HDmmYPMsCDErplNxf9k3F18NmwEVfvakembrdTI=
X-Google-Smtp-Source: AG47ELvhAWWrnKz4FJ1yrDu5lFwW7/vvnLcODbs8VHOf4AmD7+wwkaKQJyBF6K9JZiVHEr/R6nwCVBfw5X+4tCl60hE=
X-Received: by 10.107.70.14 with SMTP id t14mr16894137ioa.281.1520259961994; Mon, 05 Mar 2018 06:26:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.105.214 with HTTP; Mon, 5 Mar 2018 06:26:01 -0800 (PST)
In-Reply-To: <08fe3fa3-563a-3f5d-47ed-0197bce568b5@cs.tcd.ie>
References: <CAMm+LwjAP78hNL9Yaxqaf4K9RHYGk4M8ayJjCWt=F3_VN28cFQ@mail.gmail.com> <CAErg=HEK0aJm+Xb06px=vmfpyESetdRpe2x=q+Wca=9J8nErmw@mail.gmail.com> <CAK6vND8p55yNVoXO6_eJs1ooodVBAFZovJ84ou6uj_4qHt5DGA@mail.gmail.com> <CAMm+LwjKKqaG+OjSw3KaSvwymy6mvvyEDx1sMp2EGqXqvPSdjA@mail.gmail.com> <CAErg=HFBWaSV5-mJCBO8fLP3esfnseiqqJ_Fh1x78BW9=P-kUQ@mail.gmail.com> <26f237b9-bbe6-6efe-2a43-394d44e8334c@cs.tcd.ie> <CAErg=HH+B5+DcvPfUixy-3egm3zdhGjMangtAL0wixKE5PVkzw@mail.gmail.com> <62156108-02c7-054e-1311-855636e3fb52@cs.tcd.ie> <CAMm+LwixRjab9fWRYYzx_WJEMh-wua68tjxkVmHdjJVJkL8OQw@mail.gmail.com> <CAErg=HE8jLA3ANJhwPw-zDhKaoqp7AnDRNRwaU0i332vuOTwHw@mail.gmail.com> <MWHPR14MB1376F063D0655399B1FDE93283DA0@MWHPR14MB1376.namprd14.prod.outlook.com> <08fe3fa3-563a-3f5d-47ed-0197bce568b5@cs.tcd.ie>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Mon, 5 Mar 2018 09:26:01 -0500
X-Gmail-Original-Message-ID: <CAErg=HEzcLTwac02k5Q934c3J8a6hc+hUHJ-O13snVwKxd-a6w@mail.gmail.com>
Message-ID: <CAErg=HEzcLTwac02k5Q934c3J8a6hc+hUHJ-O13snVwKxd-a6w@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Tim Hollebeek <tim.hollebeek@digicert.com>, Ryan Sleevi <ryan-ietf@sleevi.com>, Phillip Hallam-Baker <phill@hallambaker.com>, SPASM <SPASM@ietf.org>, Peter Bowen <pzbowen@gmail.com>
Content-Type: multipart/alternative; boundary="089e0828610000450f0566ab1b44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/Ldz2FeDACbb9Afh5xXlqJijYsWc>
Subject: Re: [lamps] Revocation Request Format?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2018 14:26:16 -0000

On Mon, Mar 5, 2018 at 5:49 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
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.