Date: Wed, 29 Oct 2003 16:30:10 +1300
Message-Id: <200310290330.h9T3UAo08690@cs.auckland.ac.nz>
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
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


"Blake Ramsdell" <blake@brutesquadlabs.com> writes:

>"When looking up certificates using the subjectKeyIdentifier field, S/MIME
>agents MUST be prepared to handle multiple certificates that have the same
>subjectKeyIdentifier value gracefully."

That won't work if you only find the wrong cert using the sKID.  That is,
there are two certs with the given sKID, you get a perfect match on the one
that you can locate, but it's the wrong one.

The real problem here is that by building a spaghetti PKI (one that violates
the original X.509 design) you're subjecting yourself to a world of pain that
no amount of text in a standard can resolve.  So the only practical solution
would be to include a warning to say that everything works as required with a
conventional PKI, but all bets are off once you're in a spaghetti PKI
scenario, because the design was never intended to be used like that.  Might I
suggest:

  "The behaviour of S/MIME agents in a spaghetti PKI scenario is a
  ecumen^H^H^H^Hpolicy matter".

Peter.