Re: [lamps] Revocation Request Format?

Ryan Sleevi <> Mon, 05 March 2018 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E56012DA6D for <>; Mon, 5 Mar 2018 10:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tp3VqkWdB9uu for <>; Mon, 5 Mar 2018 10:27:21 -0800 (PST)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11F1112E88A for <>; Mon, 5 Mar 2018 10:27:06 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id C429EA007F06 for <>; Mon, 5 Mar 2018 10:27:05 -0800 (PST)
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 A7642A007F04 for <>; Mon, 5 Mar 2018 10:27:05 -0800 (PST)
Received: by with SMTP id u5so11323688itc.1 for <>; Mon, 05 Mar 2018 10:27:05 -0800 (PST)
X-Gm-Message-State: AElRT7FsrqI8D/s4aab605EXkK8vWn28K8RuACahMu7TvWoaX/ZX1MS4 m7GMdt7oB4glCWiQEJNdtuOq+ZNE8z2DF30ib5I=
X-Google-Smtp-Source: AG47ELs92vqa2T856j27Wmuo0SXCKD4X1Jk11CBTCh6ey+IOFyIyc3hle910UOU1HZhLjDgBx89mu1Q+fm57G3BQ2Bc=
X-Received: by with SMTP id b6mr14921697itf.148.1520274425008; Mon, 05 Mar 2018 10:27:05 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Mon, 05 Mar 2018 18:26:54 +0000
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Russ Housley <>
Cc: Phillip Hallam-Baker <>, Ryan Sleevi <>, SPASM <>
Content-Type: multipart/alternative; boundary="f403045fae28105a3a0566ae7950"
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: Mon, 05 Mar 2018 18:27:29 -0000

On Mon, Mar 5, 2018 at 12:04 PM Russ Housley <> wrote:

> On Mar 2, 2018, at 4:19 PM, Ryan Sleevi <> wrote:
> On Fri, Mar 2, 2018 at 3: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.
> Because it's a demonstration of compromise. Any attempt to define how that
> demonstration of compromise is proved (which I think is *bad*
> standardization) is to make it more difficult to report or demonstrate
> compromise.
> When we had a similar discussion many years ago, the feeling was somewhat
> different.  If someone has assess to the private key and uses it to
> authenticate a revocation request, the CA should honor it.  Since the party
> clearly has access to the private key, thee are many things that party
> could do that are more harmful than revoking the associated certificate.

I think we’re in violent agreement on how it should work - any
demonstration should be accepted as proof. :)

I was highlighting, however, that a policy on which CAs normalize how that
demonstration is done has the unfortunate side-effect of encouraging that
to be the de facto way it is done, which changes the burden from CAs (to
process/verify requests) to reporters/subscribers (to produce requests the
CA will accept). I’m suggesting that’s an exchange of effort that does more
harm than good, ties into the policy aspects of the PKI (what methods are
acceptable to request revocation), and does provide compelling benefit for
those reporting compromise. For those self-requesting revocation, that’s an
aspect of Certificate lifecycle management, and there’s no inherent need
for a signed proof (as demonsrrated by ACME’s protocol and the existing PKI
management tools).