Re: [lamps] Revocation Request Format?

Russ Housley <housley@vigilsec.com> Mon, 05 March 2018 19:18 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 EA59C12D7E4 for <spasm@ietfa.amsl.com>; Mon, 5 Mar 2018 11:18:54 -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 bkaT1XUY5eCz for <spasm@ietfa.amsl.com>; Mon, 5 Mar 2018 11:18:52 -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 EB806129C6D for <SPASM@ietf.org>; Mon, 5 Mar 2018 11:18:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D34FB300558 for <SPASM@ietf.org>; Mon, 5 Mar 2018 14:18:49 -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 IVP25sh4ywjm for <SPASM@ietf.org>; Mon, 5 Mar 2018 14:18:48 -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 01BC8300435; Mon, 5 Mar 2018 14:18:47 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <C6E68CC0-7C0F-4424-BAFC-0F4250E8EA2B@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1E9E4E46-F800-4565-832C-F3D717A0055F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 5 Mar 2018 14:18:59 -0500
In-Reply-To: <CAErg=HErsa-eYXPrW4CtB8UNO0SMYJxWm3ZR8-UiptDNuhO=wA@mail.gmail.com>
Cc: SPASM <SPASM@ietf.org>
To: Ryan Sleevi <ryan-ietf@sleevi.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> <118164B3-8A17-45CA-8FF8-C7D2945A7DE1@vigilsec.com> <CAErg=HErsa-eYXPrW4CtB8UNO0SMYJxWm3ZR8-UiptDNuhO=wA@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/9W25wFYp01QMFkdpUGufRMe007g>
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 19:18:55 -0000

> On Mar 5, 2018, at 1:26 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> 
> On Mon, Mar 5, 2018 at 12:04 PM Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
>> On Mar 2, 2018, at 4:19 PM, Ryan Sleevi <ryan-ietf@sleevi.com <mailto: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.
> 
> I think we’re in violent agreement on how it should work - any demonstration should be accepted as proof. :)
> 
> I was highlighting, however, that a policy on which CAs normalize how that demonstration is done has the unfortunate side-effect of encouraging that to be the de facto way it is done, which changes the burden from CAs (to process/verify requests) to reporters/subscribers (to produce requests the CA will accept). I’m suggesting that’s an exchange of effort that does more harm than good, ties into the policy aspects of the PKI (what methods are acceptable to request revocation), and does provide compelling benefit for those reporting compromise. For those self-requesting revocation, that’s an aspect of Certificate lifecycle management, and there’s no inherent need for a signed proof (as demonsrrated by ACME’s protocol and the existing PKI management tools).

Aren't we already there, based on the CMP, CMC, and ACME protocol mechanisms?  Of course, any report of compromise that is not authenticated by the private key still must be investigated by the CA.

Russ