[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [openpgp] Intended Recipient Fingerprint signature subpacket



> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/openpgp