Re: [lamps] Revocation Request Format?

Russ Housley <housley@vigilsec.com> Mon, 05 March 2018 17:04 UTC

Return-Path: <housley@vigilsec.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 98C0B12D86A for <spasm@ietfa.amsl.com>; Mon, 5 Mar 2018 09:04:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 c_QKoBTlxRcp for <spasm@ietfa.amsl.com>; Mon, 5 Mar 2018 09:04:21 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB7B12D95F for <SPASM@ietf.org>; Mon, 5 Mar 2018 09:04:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6823030066F for <SPASM@ietf.org>; Mon, 5 Mar 2018 12:04:19 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9FNnbo3vPGDu for <SPASM@ietf.org>; Mon, 5 Mar 2018 12:04:17 -0500 (EST)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 68E3A300548; Mon, 5 Mar 2018 12:04:17 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <118164B3-8A17-45CA-8FF8-C7D2945A7DE1@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F1D645F2-CB06-409B-A47D-932105249036"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 5 Mar 2018 12:04:28 -0500
In-Reply-To: <CAErg=HFBWaSV5-mJCBO8fLP3esfnseiqqJ_Fh1x78BW9=P-kUQ@mail.gmail.com>
Cc: SPASM <SPASM@ietf.org>
To: Ryan Sleevi <ryan-ietf@sleevi.com>, Phillip Hallam-Baker <phill@hallambaker.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>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/3OHoRYB_GQ3RAeGwpGtZ9Ct09rI>
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 17:04:22 -0000

> On Mar 2, 2018, at 4:19 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> 
> On Fri, Mar 2, 2018 at 3:17 PM, Phillip Hallam-Baker <phill@hallambaker.com <mailto:phill@hallambaker.com>> wrote:
> If it is a signing key, just sign a CRL for the certificate. Now that is not quite the same as revoking the key but certs are the only things PKIX makes status assertions about.
> 
> Do we have to support self-revocation of certs with only encryption only keys? Probably not.
> 
> Since a very common reason for having to revoke a cert is that the private key is lost entirely any revocation format cannot be the only way to request revocation. So I don't see the relevance of the robot attack.
> 
> Because it's a demonstration of compromise. Any attempt to define how that demonstration of compromise is proved (which I think is *bad* standardization) is to make it more difficult to report or demonstrate compromise.

When we had a similar discussion many years ago, the feeling was somewhat different.  If someone has assess to the private key and uses it to authenticate a revocation request, the CA should honor it.  Since the party clearly has access to the private key, thee are many things that party could do that are more harmful than revoking the associated certificate.

Russ