Re: [lamps] Revocation Request Format?

Ryan Sleevi <> Fri, 02 March 2018 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 968EA129C6D for <>; Fri, 2 Mar 2018 08:08:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ac79Tx28ABBq for <>; Fri, 2 Mar 2018 08:08:12 -0800 (PST)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87763126BFD for <>; Fri, 2 Mar 2018 08:08:12 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id EDFD7C00292B for <>; Fri, 2 Mar 2018 08:08:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type;; bh=25wWUt3wse1sZPMv6c1+6DFqzX8=; b= j+bTf8VETeMorrup08vTXLdyVmJBNK0YRtHQPA2qxcFZNbmFxXBceBP/kxb8Rhg8 VhT6BO68kemL5+V/BbpFmSR+7cOfOC+xQxXFFpjfUSTi97eu3dDUA14aMWz+kqvK xnuX1LvCGe9I2AevuQp/aUi1wfebpb7ZKB6vujqTX3Y=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id D8B6AC00292A for <>; Fri, 2 Mar 2018 08:08:11 -0800 (PST)
Received: by with SMTP id v6so11102594iog.7 for <>; Fri, 02 Mar 2018 08:08:11 -0800 (PST)
X-Gm-Message-State: APf1xPB5l9H7pSzeXO6aDWIpd/DULWB5CCpgwpCD/XrY17XvekSmtoC/ 7GstK8M79jyzW3LFIzLGwEhHHpwOCsiFBRWii5g=
X-Google-Smtp-Source: AG47ELubefNEDN37e+UIb5I6BUWiz1d7IgqjXxNtDqYB1mXO3GjlejcB8xAknE/Omdud61YSCkkWtubob71eRSWXOdA=
X-Received: by with SMTP id w12mr6671548ioe.282.1520006891110; Fri, 02 Mar 2018 08:08:11 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 2 Mar 2018 08:08:10 -0800 (PST)
In-Reply-To: <>
References: <>
From: Ryan Sleevi <>
Date: Fri, 2 Mar 2018 11:08:10 -0500
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Phillip Hallam-Baker <>
Cc: SPASM <>
Content-Type: multipart/alternative; boundary="001a114468f6cd08a20566702e72"
Archived-At: <>
Subject: Re: [lamps] Revocation Request Format?
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Mar 2018 16:08:15 -0000

It seems signing a new CSR has been a common practice as proof of

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 ( ), 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)

On Fri, Mar 2, 2018 at 9:24 AM, Phillip Hallam-Baker <>

> Do we have a PKIX revocation request format?
> I am asking because of a detail in the Trustico situation in which a file
> of 23K private keys was emailed to a CA to request revocation.
> At the point, the circumstances of that situation are not clear. But I can
> see a scenario in which it is entirely plausible that a CA reseller would
> have access to large numbers of TLS private keys and that is when they are
> either hosting or managing the Web sites.
> The management interfaces that allow Web sites to be wheeled around a data
> center have become very sophisticated of late with virtualization and much
> of that infrastructure is 'secret sauce'.
> What might appear to be a five racks of 100 separate machines is likely
> visible in the management console as one single entity.
> _______________________________________________
> Spasm mailing list