Note: I am assuming TPK means transferable public key. Some issues that
spring to mind and that you may want to consider in your proposal:
This is a bit awkward if you only want to do encryption (there is no
subpacket then). Some think one should always encrypt and sign, but the
issue at least needs to be raised and considered.
Can you clarify what keys are allowed as embedded TPKs? Just the
signing key for that signature, or arbitrary keys? If the latter (for
example to allow more use cases such as key rollover), then the new
subpacket would be the first subpacket not to have any relationship to
the signature it is contained in, which would be awkward. It would also
potentially allow interesting attack vectors (injecting arbitrary
keyring data). If only some keys are allowed, it needs to be specified
which and how they are verified.
Also, as you said, there are already some ways to transfer public keys
in email as attachment or header. Some email readers already look in
these places and have a GUI to import these keys. You say your proposal
requires no cooperation by the MUAs, but this seems to rely on very
narrow trust models not requiring any user interaction. Maybe you can
expand on that topic a bit? Are the existing mechanisms obsoleted by
it, or is it an alternative? If the latter, can your proposal be
extended to cover existing use cases?
The embedded key can contain signatures, and these signatures can again
have embedded keys. This would allow for arbitrary recursion, which
from experience makes for interesting bugs. Maybe you can add some
considerations for that to your proposal?
Thanks,
Marcus
On 3/25/19 10:20 AM, Justus Winter wrote:
Hello,
I'd like to propose a new signature subpacket that contains a TPK,
let's call it the Embedded TPK subpacket.
I see two immediate use cases:
- If a designated revoker creates a revocation signature, she can
embed her TPK in the signature, so that it is easy to verify the
revocation without having to hunt for her TPK.
- Some MUAs attach TPKs to emails, pEp does so too, and Autocrypt
includes TPKs in mail headers. Instead of doing that, one could
then transmit ones TPK (and those of others in the conversation)
in-band. This has the advantage of requiring no cooperation of
the MUAs, and the PGP implementations can gather the TPKs when
parsing the signatures.
Thanks,
Justus
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
--
Dipl.-Math. Marcus Brinkmann
Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
Universitätsstr. 150, Geb. ID 2/461
D-44780 Bochum
Telefon: +49 (0) 234 / 32-25030
http://www.nds.rub.de/chair/people/mbrinkmann
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp