Darren Harter <dharter(_at_)cesg(_dot_)gov(_dot_)uk> writes:
http://www.cesg.gov.uk/ellisint.htm
It describes CESG's prior invention of RSA and DH ;-)
Yeah, well, too bad you guys didn't publish and save us 20 years
of PKP.
Trevor Freeman <trevorf(_at_)microsoft(_dot_)com> 12/16 6:13 pm >>>
Tim,
If you want to show unequivocally you sent the message then you construct
a new signing data layer with the existing data nested within, rather than
add a new signer info block to the existing signed. If you want to know
the sequence a series of parallel signatures where constructed then use
time to differentiate the signatures.
Trevor
I think the issue that Tim was trying to convey is that there is no way of
preventing somebody else from adding their signature to your SignedData.
The problem then, as a receiving application, is who to take as the
originator of the message. This problem is compounded if we do the
suggested check of cert altSubjectName against the From: field. Timestamps
are great so long as you can trust that the User has a good time source (and
has used it), and that all signers fill the field.
As far as I can see, the only way of preventing other users from appending
their signature after you have sent the message is to have a variant of
SignedData called LockedSignedData defined as follows:
LockedSignedData ::= SIGNED{ SignedData }
i.e. Take MSP's SequenceSignature approach and sign the SignedData ;-)
The attack, as I understand it, is that you trick
someone into co-signing a message and then pretend it's from them.
This is stopped, as you say, by having co-signing be a different
operation from signing. (This is what countersigning provides, and
it's analagous to your approach above.)
However, if you believe that there is a role for multiple signatures
at the same level (i.e. multiple SignerInfos) by different entities,
then (at the moment) receivers can't know which one of those entities
sent it. (The semantics of multiple signatures have always been pretty
confused.) The obvious fix for this is an attribute that says 'I'm
just a co-signer, not a signer'. But I'm not sure what semantics
that would have different from countersign. It's obvious that
we need multiple signatures from the same entity for mixed-algorithm
environments so we certainly can't do away with multiple signatures
altogether.
There's no way AFAIK, to stop someone who has access to a message
from tacking on their own signature (and stripping yours), which
is the attack you describe. Even with LockSignedData, since
they have access to the plaintext one can therefore simply generate
a new SignedData.
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."