Hi Marcus :)
thanks for the prompt answer!
Marcus Brinkmann
<marcus.brinkmann=40ruhr-uni-bochum(_dot_)de(_at_)dmarc(_dot_)ietf(_dot_)org>
writes:
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.
That is true. For me, not-sign-then-encrypt is not such a prominent
use case.
Note that this only concerns the key-gossiping use case. Distributing
the revoker's TPK with revocations is always possible.
Can you clarify what keys are allowed as embedded TPKs? Just the
signing key for that signature, or arbitrary keys?
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.
Really? Plenty of signature subpackets deal with keys, user
preferences, or can simply contain arbitrary data (notations).
It would also potentially allow interesting attack vectors (injecting
arbitrary keyring data).
GnuPG's keyring is uncurated, and it uses trust models to compute the
validity of userid,key-bindings. Similar, Sequoia's keystore can
contain keys that have no bindings.
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?
My proposal is ment to obsolete the existing mechanisms. The fact that
we now have multiple incompatible mechanisms is a bit sad, and I'm
trying to extend OpenPGP so that we can have interoperable
implementations again.
By requiring no MUA cooperation I ment to say "no MUA modifications
other than the usual PGP integration". For example, if you look at
Autocrypt, implementing it means that the MUA needs to do a lot of
low-level key manipulations. As I see it, this is much more work than
what is already done for many MUAs. My proposal aims at bringing the
key gossiping to MUAs without requiring further modifications.
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?
I don't see that as too problematic. We already have embedded
signatures, which can contain embedded signatures, and it doesn't seem
to be a problem there.
Cheers,
Justus
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp