Pete,
I'm not sure I see how this is different than the same nasty CA
generating a key pair, creating the bogus certification path,
and spoofing an entire message. In either case, recipients are
relying on the appropriateness of the identity vouched for by
the CA (and the validity of the CA itself). While its true that in
your example, the CA could change the attribution of an encrypted
message, I'm not sure why I, the attacker, wouldn't just as soon
create an entire message from scratch.
Dave
Date: Fri, 08 Oct 93 12:48:37 A
To: pem-dev(_at_)tis(_dot_)com
From: p(_dot_)churchyard(_at_)ic(_dot_)ac(_dot_)uk
Subject: A small cloud with a golden lining?
If I was nasty CA (like from a rival company) one of the things I can
do is to change the certificates on any PEM messages and thus can
change the attribution of the PEM message.
Since I know the public key used to sign a message, I can generate a new
certificate that has that public key. I just copy over the MIC and the
message body intact and thats it...
The fix is easy to the PEM protocol and also touches on one of the areas
that I think the PEM specs are wrong.
The fix.
PEM should transport RFC822 messages and not just the RFC822 message body. If
you have 822 headers then it is easy to insert an extra Originator-Id header
into them BEFORE the message is signed. A nasty CA cannot now get away
with changing the Certs since the Originator ID in the message headers is
now covered by the MIC. With a full RFC822 message, you can now cleanly
interface to MIME because you can PEM a MIME message and have the MIME
headers in the Header part of the 822 message and not extracted into the
envelope headers.
Pete.