Re: [lamps] Revocation Request Format?

Jacob Hoffman-Andrews <jsha@eff.org> Fri, 02 March 2018 20:26 UTC

Return-Path: <jsha@eff.org>
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 24E5912EAAE for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 12:26:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 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_HI=-5, 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=eff.org
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 RWMO_oIKMzqo for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 12:26:12 -0800 (PST)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D96A127369 for <SPASM@ietf.org>; Fri, 2 Mar 2018 12:26:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=CdBAUHvfutn7jmoog9/vmjPHQCjgUSAj/uiBlLIvIM0=; b=UPPCRENGOpWsynotALYeIp/P/k vSvJ6fzzHkbBiGhWYOXe4Z7rEMYelk2CFOAbutX9hD684DMrdMK9GEwC9YH9vCQn13VvZorIF6VFz Skbldrq48+DDDuPv2HB7oRX2zzeIvapwPN/icDbKS71/grSwHf7jWVlJ903HtR0k1Ycw=;
Received: ; Fri, 02 Mar 2018 12:26:10 -0800
To: Phillip Hallam-Baker <phill@hallambaker.com>, Peter Bowen <pzbowen@gmail.com>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>, SPASM <SPASM@ietf.org>
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>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <9d5be6a2-167b-ba03-ca0f-d076132c1519@eff.org>
Date: Fri, 2 Mar 2018 12:26:10 -0800
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: <CAMm+LwjKKqaG+OjSw3KaSvwymy6mvvyEDx1sMp2EGqXqvPSdjA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------78BF77FF9933A3A3943D0C73"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/y-elfXz6vNrhfv51hoMmR4PluJk>
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: Fri, 02 Mar 2018 20:26:17 -0000

ACME already specifies how to revoke by proving control of the private
key, or by proving control of the affected domains. If a CA wants to
provide standards-based revocation services, they don't need to
implement all of ACME, just enough to sign up for an account and do the
revocation request.

On 03/02/2018 12:17 PM, Phillip Hallam-Baker 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.
>
>
> Standards are all about taking choices that don't matter except that a
> choice is made. If we choose to recognize CRL suicide notes as the one
> mechanism that must be supported, that is one mechanism that can be
> added to PKI toolkits that don't already have it. And yes, there is at
> least one widely used toolkit that allows certificates and CRLs to be
> parsed but not generated.
>
>
>
> On Fri, Mar 2, 2018 at 3:03 PM, Peter Bowen <pzbowen@gmail.com
> <mailto:pzbowen@gmail.com>> wrote:
>
>     On Fri, Mar 2, 2018 at 8:08 AM, Ryan Sleevi <ryan-ietf@sleevi.com
>     <mailto:ryan-ietf@sleevi.com>> wrote:
>     > It seems signing a new CSR has been a common practice as proof of
>     > possession.
>     >
>     > There's one segment of users that want to have a
>     time-constrained request
>     > (that is, incorporating a challenge/response), while another
>     would prefer
>     > that you can generate the 'request to revoke' at the same time
>     you request
>     > the cert, so that you can use this token for situations such as
>     loss of
>     > private key (but not loss of revocation token)
>     >
>     > It doesn't seem like there needs to be a bespoke format here,
>     considering
>     > that the industry is still working through its use cases, and
>     any signed
>     > data is sufficient.
>     >
>     > Further, it may do harm to try and standardize that. Consider
>     the ROBOT
>     > attack ( https://robotattack.org/ ), which presented a signing
>     oracle with
>     > TLS private keys. Prematurely constraining revocation requests to a
>     > particular format might otherwise preclude reasonable
>     demonstration of
>     > private key compromise.
>     >
>     > So I don't think there's anything for LAMPS to do here - we have
>     ample
>     > available technology (running code that already works) and we
>     have not yet
>     > ascertained industry needs in any meaningful way (no rough
>     consensus for
>     > something new)
>
>     There is also a documented (albeit not in RFCs) format for a generic
>     signed public key with challenge:
>     https://www.w3.org/TR/html51/sec-forms.html#the-keygen-element
>     <https://www.w3.org/TR/html51/sec-forms.html#the-keygen-element>
>
>     PublicKeyAndChallenge ::= SEQUENCE {
>       spki SubjectPublicKeyInfo,
>       challenge IA5STRING
>     }
>
>     SignedPublicKeyAndChallenge ::= SEQUENCE {
>       publicKeyAndChallenge PublicKeyAndChallenge,
>       signatureAlgorithm AlgorithmIdentifier,
>       signature BIT STRING
>     }
>
>     The challenge is an arbitrary length IA5STRING, so it could easily
>     include nonce or other challenge data to prove key control.
>
>     Thanks,
>     Peter
>
>
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm