RE: Request change in son-of-rfc2633

pgut001@cs.auckland.ac.nz (Peter Gutmann) Wed, 29 October 2003 04:15 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 XAA22692 for <smime-archive@lists.ietf.org>; Tue, 28 Oct 2003 23:15:23 -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 h9T3ZiI7021508 for <ietf-smime-bks@above.proper.com>; Tue, 28 Oct 2003 19:35:44 -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 h9T3ZiW8021507 for ietf-smime-bks; Tue, 28 Oct 2003 19:35:44 -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 h9T3ZfI7021494; Tue, 28 Oct 2003 19:35:42 -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 h9T3Zfo9008396; Wed, 29 Oct 2003 16:35:41 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9T3bu208738; Wed, 29 Oct 2003 16:37:56 +1300
Date: Wed, 29 Oct 2003 16:37:56 +1300
Message-Id: <200310290337.h9T3bu208738@cs.auckland.ac.nz>
From: pgut001@cs.auckland.ac.nz
To: ejnorman@doit.wisc.edu, ietf-pkix@imc.org
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>

[Cross-posted back to S/MIME, where the thread started]

Eric Norman <ejnorman@doit.wisc.edu> writes:

>Is there a claim (#1 above) that you can have the DN in the subject of a
>parent's (signer's) certificate be different from (as in different bunch of
>bytes) the DN in the issuer of one of its offspring and yet the chain is
>still valid because the xKIDs match?

Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI that
violates the original X.509 design, i.e. with re-parenting, arbitrary cross-
certification, etc etc where issuers no longer match subjects).  For example
MS apparently implemented chaining by sKID in Windows because of user demand
for this when the users broke chaining by issuer name through spaghetti PKI
design practices, and various other implementations no doubt do similar
things, depending on how they've read the PKIX tea leaves.

Peter.