But, the attacker could still send it along as a clearsigned message,
and if the recipient accepts the message at face value, the attack
succeeds.
That's correct. It *would* be possible to use the same subpacket even in
a cleartext context, but that is a much less clear-cut use case that is
more difficult to reason about, and easy to mess up in implementation.
=====[begin text of message to be signed and encrypted to Bob]=====
By your other description, I assume you mean clearsigned messages here?
For encrypted messages, the attack will fail: Bob can't forward a
signed+encrypted message of Alice's to John and trick him into thinking
it was intended for him, since the signature does say it was meant for
Bob.
if the new packet is easy to implement, then great.
For a typical workflow, it's very easy to implement. If you consider an
api that is roughly:
signAndEncryptTo(cleartext, signingKey, recipientKeys) -> ciphertext
decryptAndVerify(ciphertext, decryptionKey) -> verificationstatus, cleartext
then it works transparently from an api user perspective, and uses only
information that is readily available in the implementation for an
additional error case.
- V
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp