IETF Logo Mail Archive

RE: Request change in son-of-rfc2633

pgut001@cs.auckland.ac.nz (Peter Gutmann) Tue, 28 October 2003 02:47 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 VAA04762 for <smime-archive@lists.ietf.org>; Mon, 27 Oct 2003 21:47:40 -0500 (EST)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2AUI7086827 for <ietf-smime-bks@above.proper.com>; Mon, 27 Oct 2003 18:10:30 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S2AT0M086826 for ietf-smime-bks; Mon, 27 Oct 2003 18:10:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2ARI7086821 for <ietf-smime@imc.org>; Mon, 27 Oct 2003 18:10:28 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz)
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9S2ALo1030172; Tue, 28 Oct 2003 15:10:21 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9S2CPq01616; Tue, 28 Oct 2003 15:12:25 +1300
Date: Tue, 28 Oct 2003 15:12:25 +1300
Message-Id: <200310280212.h9S2CPq01616@cs.auckland.ac.nz>
From: pgut001@cs.auckland.ac.nz
To: blake@brutesquadlabs.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz
Subject: RE: Request change in son-of-rfc2633
Cc: ietf-smime@imc.org
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

"Blake Ramsdell" <blake@brutesquadlabs.com> writes:

>Apparently I was one of the deluded folks that believed that SKI was meant to
>be globally unique.

As was almost everyone else.  The problem is that there are two incompatible
interpretations of the sKID:

1. Alternative chaining mechanism if chaining by DN fails, e.g. with cert
   reparenting or some types of spaghetti PKIs.

2. Disambiguating factor if chaining by DN leads to multiple issuers, e.g.
   with other types of spaghetti PKIs.

The problem is that taking one or the other view changes a simple "You've used
the wrong cert" (or "Cert to verify this isn't available") to "An attacker is
modifying your messages!", which will cause very different reactions in users.

Peter.

v2.28.0 | Report a Bug | By Email | System Status