Identifying revoked certificates

"Michael Young" <> Wed, 05 September 2001 02:08 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA03179 for <>; Tue, 4 Sep 2001 22:08:52 -0400 (EDT)
Received: by (8.11.6/8.11.3) id f851uHq25786 for ietf-openpgp-bks; Tue, 4 Sep 2001 18:56:17 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id f851uFD25782 for <>; Tue, 4 Sep 2001 18:56:15 -0700 (PDT)
Received: from mwyoung ([]) by (Netscape Messaging Server 4.15) with SMTP id GJ62QL01.T2B for <>; Tue, 4 Sep 2001 21:56:45 -0400
Message-ID: <010901c135ad$a7233000$>
From: "Michael Young" <>
To: <>
References: <p05100309b7baf2e20a43@[]>
Subject: Identifying revoked certificates
Date: Tue, 4 Sep 2001 21:54:06 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 7bit


From: "Jon Callas" <>;
> Now then, one of the remaining things really on our agenda is to discuss
> fixing the secret key format.

Can I get something added to the agenda?

Last week, I asked how certificate revocation was supposed to work in
the presence of multiple certificates for the same key/userId (or
key/subkey or just key) material.  I don't buy the argument that the
spec shouldn't cover semantics here -- I don't care if the spec says
how an implementation should treat a revocation, but I think it's
critical that the sender and receiver agree on what is being revoked.

My proposal was to add a signature subpacket to contain the hash
algorithm and value from the certificate being revoked.  Old
implementations should ignore it (unless the sender marks it critical,
in which case they should ignore the revocation itself).  New
implementations can use it to positively identify the original.

Does this sound reasonable?  If not, do you disagree with the premise
that identification is useful?  Or, do you dislike the form of the ID?

(Plus, in doing so, the spec can remain silent on the meaning of
duplicate certificates.  I favor adding a "most recent prevails"
recommendation, but if I can revoke *specific* older ones to make
my intention clear, I don't need to depend on any other rules.)

Version: PGP Personal Privacy 6.5.3