Re: [lamps] Revocation Request Format?

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 02 March 2018 22:08 UTC

Return-Path: <hallam@gmail.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 7413F124239 for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 14:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Fe0Z8-WSdYV6 for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 14:08:21 -0800 (PST)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF99812D7F1 for <SPASM@ietf.org>; Fri, 2 Mar 2018 14:08:20 -0800 (PST)
Received: by mail-oi0-x234.google.com with SMTP id b8so8117670oib.11 for <SPASM@ietf.org>; Fri, 02 Mar 2018 14:08:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dBZ35PjgvpBA/AlwYd2AynAuvdKWsWrf9yN/wz247lg=; b=uKVVr7kPmXpXo/h04ciqctOAhPbQjNy3QotNKTSEZ42q0zG6rP7O0wSx2qY6Wr+4oY mQ1gL9VSi9dF2BiNbanIqdjdlsw/CBrdYeQ/hC32UW9flggpVxn2ypR//JweBOTg6bnx mBG/UOMMTw5miyiydhquWdYYFzNPet3kKQts+BtUBWitnQMstJzwswXh2XYrPVq2bRSr 039Gb54hgCfB1jCFkScmLzDbgKv4gPAcDzb26HRfQ0GhdypYsHRH2uK83uF9XENwf/EU 69kKLkBwrWm4oxGA0Vjh655/vEnYglACATjfV7YtZiy/7mb7bsFOLbu30Scr+R33MnN0 ayjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dBZ35PjgvpBA/AlwYd2AynAuvdKWsWrf9yN/wz247lg=; b=NUvEdZ6IMVFwV61sfLDyXGUvsVjXHmTgQeKqD2YOfRt96nV00zJwdRP4dsdGQGsUa3 jWNogs1QKenZkLOxtJJrD8V0Il5CMkZmF9NmdEBuWQ5albj0DVY8FEQfLDnm/zAqJlf9 ir8cmhhNP8FmxDlxHobDw+20z+Tx8Z3Or2Swhmlzhj+Jw7TML2XvknaCBo25QztsuHB8 MLhKkG1cDV8snR7nyLfeYG7r+56f4Q554Cfb/+0cV+NOFRgppAWV+td4vPUzG2wYi+JQ ERtU14Zn57neL4AryhQZ+SN3iVHIFshYrkyJqX185X6123/DcjgLLShWPmpmRS3L/IVU Roug==
X-Gm-Message-State: APf1xPAsCBKI0zOiGEsLv77RCxaoGC0S3wcqxDLycbCgzMEPg+mtwGih YDP/My/J1WtwGs+VxYB1qY6zNj0/1pF2/tYeY6o=
X-Google-Smtp-Source: AG47ELue/XOMsb5k8R6tW5j4Dr/+6RwPfqfHbsQQGINtVjzbbDsgS4l1Yybipih9uhUs572kTzgre/RvfHrRQH/fMxc=
X-Received: by 10.202.206.71 with SMTP id e68mr4865318oig.34.1520028500042; Fri, 02 Mar 2018 14:08:20 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.157.5.5 with HTTP; Fri, 2 Mar 2018 14:08:19 -0800 (PST)
In-Reply-To: <9d5be6a2-167b-ba03-ca0f-d076132c1519@eff.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> <9d5be6a2-167b-ba03-ca0f-d076132c1519@eff.org>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 2 Mar 2018 17:08:19 -0500
X-Google-Sender-Auth: MLkK0Sfo7HkogPfFZDgtnCN95ng
Message-ID: <CAMm+LwiGPomh4pRSNo7O2cwj6F1WGBTVQT__dXYZj4=e+rCRqw@mail.gmail.com>
To: Jacob Hoffman-Andrews <jsha@eff.org>
Cc: Peter Bowen <pzbowen@gmail.com>, Ryan Sleevi <ryan-ietf@sleevi.com>, SPASM <SPASM@ietf.org>
Content-Type: multipart/alternative; boundary="001a113cdb04cb2b5d0566753696"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/0OCSBEtVwtsSwI4BSjM3ldWQEZY>
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 22:08:25 -0000

Hmmm...

Well ACME is intended to be a comprehensive certificate lifecycle protocol.
I guess it might depend on whether that part needed JSON or just ASN.1...

Might be all we would need to do is to add a page or two calling out
standalone use as a specific use case and declare victory.



On Fri, Mar 2, 2018 at 3:26 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrote:

> 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> wrote:
>
>> On Fri, Mar 2, 2018 at 8:08 AM, Ryan Sleevi <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
>>
>> 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 listSpasm@ietf.orghttps://www.ietf.org/mailman/listinfo/spasm
>
>
>