Re: [lamps] Revocation Request Format?

Phillip Hallam-Baker <> Sat, 03 March 2018 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 726F2126BF3 for <>; Sat, 3 Mar 2018 09:08:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z56zqdLd81fd for <>; Sat, 3 Mar 2018 09:08:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A10C1204DA for <>; Sat, 3 Mar 2018 09:08:01 -0800 (PST)
Received: by with SMTP id c12so9255169oic.7 for <>; Sat, 03 Mar 2018 09:08:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+jdqJjhiVDXjO6CuJlCDxwlt40c7nFGc65NLlWQSAGk=; b=Yt0bVb1zCb0UwwBIdKbl8Gecblv9rltWhi40WCzJj7OlSxMz0xnik95XLhPF+oYj7S ePG2m/fWO22bXnKmncHUSR4K8Xg6H3L0/acCci/fyOVzBtwHNKq/w9JDV37P0vq/Dp+w CLgSDFqXXjxCe0TIHRpbeB7CiBDbdhUYjvukOn4SDhrpjalfbwC8SoHKdBXu/Oz20g1s BdPk9FKbWnm8V7ATAEtym75e7JPELrF1R131STV1jKvEIc0WyirhMzTtoXXEUZZeWyAy bu41mq7yEY4ZaSMUSUD5x3M1ubNJqJHL0aTSy1oXVDFojeEaCBEycU2t+iP9zVm79r/a i4Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+jdqJjhiVDXjO6CuJlCDxwlt40c7nFGc65NLlWQSAGk=; b=Ku8ZuJNwg9E73q/LH47LOgUNmL6tWmmWZKixtYMzuJOzFuCbcuP0VAEEKDVwm9TQkT fVu+XEd8KloaAB7+depoqEXcIrnUs4kV71+0YnhMa0cgHHj4qv/+92ijaSlcEfcPQwfd xqdIov4PGCJLI5NvtWo34icreMW+VTXKSErD0KO9xLjluk46EKsYt9YBCMADyBE/0RD1 oP5pIjkUyShEKFYxfBxwY32n2Ah9rEy8G+SzB59oNjQFrRvTwtWjZPYH0wMt6MBpaLJc cSuidlExyv5fvdAb/ym091iNHNSBbHieWbolZDaqwXTZ4+D77odTGLt/TIxjdP35Kcq3 deDA==
X-Gm-Message-State: AElRT7Fa4zFcg+yRLp7DPDeY2gohuOHXck0EKph5p5YoVYB/eYZlG1Wv j1mRzV80QmkKzegnh9EKf6FHdNXrlnqpSQH2bwY=
X-Google-Smtp-Source: AG47ELutb+ZTfkk8NkWPNEN1mug5mzsPmD55FgriszG2yRWSwXsOMh7juXuxpaAwo+roWVzM+2Q8k1MIR0bem53iCH0=
X-Received: by with SMTP id r190mr6484940oie.180.1520096880463; Sat, 03 Mar 2018 09:08:00 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 3 Mar 2018 09:07:59 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Phillip Hallam-Baker <>
Date: Sat, 3 Mar 2018 12:07:59 -0500
X-Google-Sender-Auth: 4sQbZOeWWJjTdTZU-XF1GfJrQxI
Message-ID: <>
To: Stephen Farrell <>
Cc: Ryan Sleevi <>, SPASM <>, Peter Bowen <>
Content-Type: multipart/alternative; boundary="001a113cd4b695938d0566852206"
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 17:08:03 -0000

On Sat, Mar 3, 2018 at 1:29 AM, Stephen Farrell <>

> 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.