Identifying revoked certificates

"Michael Young" <mwy-opgp97@the-youngs.org> Wed, 05 September 2001 02:08 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03179 for <openpgp-archive@odin.ietf.org>; Tue, 4 Sep 2001 22:08:52 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id f851uHq25786 for ietf-openpgp-bks; Tue, 4 Sep 2001 18:56:17 -0700 (PDT)
Received: from smtprelay3.adelphia.net (smtprelay3.adelphia.net [64.8.25.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f851uFD25782 for <ietf-openpgp@imc.org>; Tue, 4 Sep 2001 18:56:15 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GJ62QL01.T2B for <ietf-openpgp@imc.org>; Tue, 4 Sep 2001 21:56:45 -0400
Message-ID: <010901c135ad$a7233000$fac32609@transarc.ibm.com>
From: "Michael Young" <mwy-opgp97@the-youngs.org>
To: <ietf-openpgp@imc.org>
References: <p05100309b7baf2e20a43@[192.168.1.180]>
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
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----

From: "Jon Callas" <jon@callas.org>;
> 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.)

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO5WFnGNDnIII+QUHAQExMgf/bWSykKCbGLUwKBwQg2etB6br0EvUO3ya
33Vz2gxjkeUN/W0v5IeWu0NJHpBFaBkjsM7SvG/jBi4E0Sso7FXn+qu0N+k/Lm2t
B/7WWKnF+hZfYl2s+facScyF5rGQ6xiWsb3godcLjYRxTTcPrbfdD4qzqNEPpa9J
vblPkkD+77TR0FYSsLqOjImGbV+rSgAN5SXa4qDphPT9cZ06PVUY+exD0fLiOPHo
ONd31YjMrlOw8WiNYnhWpGiE7pMx7MLTe44QDWbpIRIVqOjO8B8p2Hm8MhISpC96
FiZiz5PHw7j7ViEgPnse9tV4vwiQ6yzqcV43xhnBkXB84wM33KatGg==
=M5t4
-----END PGP SIGNATURE-----