One of the threats we addressed early on was the possibility of
a user generating a prototype certificate containing someone else's
public key, just so he could fake some else's signature. (He couldn't
actually sign, but he could claim that someone else's signature
was really his.) We stopped that by requiring that he sign some piece
of "innocuous text" to prove that he actually possessed the private
key that corresponds to the public key in the certificate.
However, if a rogue CA ignores that requirement and goes ahead and
signs the certificate anyway, the spoof would work.
Your example is another instance of the same attack.
Dave>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.
A nasty CA that creates a key pair could generate a certificate
for a nonexistant individual, or he could create an additional
certificate for a real individual and then pretend that he was that
individual by signing something using the fraudulent private key.
What he cannot do is sign something using the other individual's
"real" certificate, since he doesn't know the private key. But he
could claim attribution of something he didn't write (such as
an invention disclosure) through this procedure.
The good guy can defend himself against this fabrication (if he
knows about it) by requesting the rogue CA to revoke his fake
certificate, and if the CA refuses, escallate to the PCA. But this is
troubling.
In the final analysis, this attack is against the name subordination
requirement. If the name subordination requirements are met, the
innocent user would have to prove that he didn't work for that
company, and therefore the certificate issued by the rogue CA was
invalid.
If the good guy and the bad guy work work for the same company, and
the company is the rogue CA, you have a real problem. Now the good
guy has to prove that he never requested or was issued that particular
certificate. Proving a negative is of course difficult, maybe impossible.
In fact, a devious user could generate a certificate request for a second
certificate, use it to sign something, then come back and disavow that
the certificate was his or that he ever received it, alleging the above
scenario. To protect itself, a legitimate CA should require the user to
sign an acknowledgement of receipt of the certificate.
I'm thinking out loud now. Would it help to have the signed innocuous
text actually incorporated in the X.509 certificate? This would prevent
a bad guy from impersonating someone else with the assistance of the
CA, but it wouldn't prevent the CA from generating a key pair, then
making up a totally bogus certificate and keeping the private key for
himself.
I hate to say it, but it almost sounds like we ought to have two CAs sign
each certificate, to provide some protection against a rogue CA!!
Another approach would be to insist on publishing a list of all users
and all of their DNs in one readily accessible place, e.g., an X.500
directory, so that duplicate DNs and certificates could be easily detected.
It certainly sounds as though a user ought to demand such a listing from
his CA, to protect himself against a clone within his own company. But
what assurance does he have that his view of the list is always
complete?
Bob Jueneman