Re: [lamps] Revocation Request Format?

Ryan Sleevi <> Sat, 03 March 2018 18:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BA9D1204DA for <>; Sat, 3 Mar 2018 10:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] 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 SodtCDoAVAKZ for <>; Sat, 3 Mar 2018 10:34:17 -0800 (PST)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2822D126D05 for <>; Sat, 3 Mar 2018 10:34:13 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id BA3CD20047604 for <>; Sat, 3 Mar 2018 10:34:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type;; bh=1R7iWHD8M7+oYb85sOQjCUGlQ+o=; b= HKMBh1v4O2MHYbhQAeCN5TDj2iF5Myp3/rZAbFwrY226Ew/f5x9LVBVXnos/Xdf9 k2WDcLl7JEOplK831ABPDeyjq+3w+e4O/k9r/kuW4ioQk3I5OGNcBW39kMvs5IDk t3Jr20BN4RgV/1MseP/Ohnwekg21VjJ4wDKZehu60jE=
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 5E51F201702C2 for <>; Sat, 3 Mar 2018 10:34:12 -0800 (PST)
Received: by with SMTP id u84so13882123iod.9 for <>; Sat, 03 Mar 2018 10:34:12 -0800 (PST)
X-Gm-Message-State: AElRT7F/8+XfF7zybewtpAFO4Ua2xFXvFObjHdVay6/B87oJA139+bnM repa+DKSbJU/qJYUciUX8Xg00rEjBzcUWsW8FWY=
X-Google-Smtp-Source: AG47ELsdZeoY79zY6/SrUtNrhRkpD4uo83vj6qcYBabZjJmR3ejYebNB+3usFFZiFUKrt20zmVusZ40V6F1pn8vemsE=
X-Received: by with SMTP id s65mr11934749ios.159.1520102051724; Sat, 03 Mar 2018 10:34:11 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Sat, 03 Mar 2018 18:34:00 +0000
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Phillip Hallam-Baker <>
Cc: Peter Bowen <>, Ryan Sleevi <>, SPASM <>, Stephen Farrell <>
Content-Type: multipart/alternative; boundary="001a1139818cd0c3d205668656bb"
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: Sat, 03 Mar 2018 18:34:20 -0000

On Sat, Mar 3, 2018 at 12:07 PM Phillip Hallam-Baker <>

> On Sat, Mar 3, 2018 at 1:29 AM, Stephen Farrell <
> > wrote:
>> On 02/03/18 22:33, Ryan Sleevi wrote:
>> > That's why I think an effort to standardize there is bad, not good,
>> because
>> > it counterintuitively fragments the ecosystem, without addressing the
>> > general issue, which is in my view is moreso a matter of policy,
>> because of
>> > the inherent constraints of 2).
>> FWIW, I don't agree with your conclusion that *any* standardisation
>> of revocation signals would be counter-productive, but I also don't
>> think we ought do any such standardisation unless there are a bunch
>> of CAs and writers of private key handling s/w who do in fact want
>> to use the same new format for revocation signalling. I don't see a
>> whole bunch of CAs and others wanting that right now.
>> So in the short term, I think we agree as to what to (not) do:-)
> ​At this point, the incident that motivated this proposal happened 4 days
> ago. So it would probably be a mistake to bang out a draft and promote it
> to RFC.​
> ​What I was most interested to know is if we had done the work already and
> the answer appears to be not in PKIX​ but possibly in ACME. It might just
> be that all we need to do is to add a few paragraphs to ACME and maybe get
> an IANA content type for whatever the standalone message blob is.
> I do think we will need to standardize because we are almost certain to
> want to pop these blobs in our CT logs at some point and it is in any case
> the right thing to do. One code path is always better than five code paths
> offering the same functionality.

It might be good to start with a Use Cases document first, to figure out
who the participants/constituents would be. This would align with Stephen’s
remark re: what writers of private key handling s/w should use. Considering
such solutions naturally preclude solving (some of) the “compromise”
scenarios that must be dealt with today, the merits of those use cases
could be independently evaluated before trying to shape such work.

I view the transparency aspect as similarly orthogonal - such transparency
is more beneficial for demonstrating the private key holder authorized a
revocation. In today’s Web PKI, that is a real problem with CAs
unilaterally revoking for specious reasons (“malware”, “customer stopped
paying monthly fee”, “we added a new domain name to the customer account”)
or Resellers, often misguided, requesting revocation per the terms of their
contract with the CA without regard to whether or not the Certificate
recipient desires it.