Re: [lamps] Revocation Request Format?

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 05 March 2018 10:49 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 848AD128954 for <spasm@ietfa.amsl.com>; Mon, 5 Mar 2018 02:49:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 W87CoYXLLOQ7 for <spasm@ietfa.amsl.com>; Mon, 5 Mar 2018 02:49:43 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0509312783A for <SPASM@ietf.org>; Mon, 5 Mar 2018 02:49:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B045DBE2E; Mon, 5 Mar 2018 10:49:39 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHt8dDrW0xmo; Mon, 5 Mar 2018 10:49:39 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B722ABE38; Mon, 5 Mar 2018 10:49:38 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1520246978; bh=hgf0DrO+fNzdGaZ1u531L5Iq+leFNhPpd8RmK8ISCns=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=sOHo5ivC2MJfbeMe6/Vf0AzgH0KzVx52/pLwYBxWJ6zJ8RbvBBoKrbJVn/TxDcTKt 9IflQSsse7h8cBMJlB1xWD0u6lT2IY3KpBmAt8yNTNDwln9NWjBwBvzDD9uuGAmQ+h LdPay+CJ9gO7x4f9AfoZs4bT4MwBSF9X95GJr56s=
To: Tim Hollebeek <tim.hollebeek@digicert.com>, Ryan Sleevi <ryan-ietf@sleevi.com>, Phillip Hallam-Baker <phill@hallambaker.com>
Cc: SPASM <SPASM@ietf.org>, Peter Bowen <pzbowen@gmail.com>
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>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Message-ID: <08fe3fa3-563a-3f5d-47ed-0197bce568b5@cs.tcd.ie>
Date: Mon, 5 Mar 2018 10:49:37 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <MWHPR14MB1376F063D0655399B1FDE93283DA0@MWHPR14MB1376.namprd14.prod.outlook.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NlE8WphOKU1FvWA1syKbKNnl9nKGZxWau"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/6g60EB2-4Z5KKcBP-nNb1XNZrz0>
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 10:49:45 -0000

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.

> This would align with
> Stephen’s remark re: what writers of private key handling s/w should
> use. 

I think s/should use/would use/ is more in line with what I meant to
say, both for CAs and those writing/using private key handling s/w.
Put another way, there's a lot of things we could say such folks
"should" do, but there's little point in doing so unless they would
actually do stuff.

Cheers,
S.


> 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.
> 
> 
> 
>