Reading new key packages (Re: Coexistence with OpenPGP/IETF)
Werner Koch
wk at gnupg.org
Tue Jan 16 18:19:30 CET 2024
Hi!
although I don't want to open such a discussion again, here is my stance
on the items obviously raised in the IETF WG:
>> - it's not clear how to populate the fields in an encrypt-then-sign
>> scenario
Why? There is still a literal data packet even if that is first
encrypted. Nothing than a hash of that data leaks - and if you don't
want that use dummy meta data (i.e. those you would also use when you
read from a pipe).
>> - they make it impossible to be able to cleanly detach and reattach
>> signatures
It does not as long as the meta data is the same. And protecting the
meta data of the literal data packet is the whole point of the exercise.
If that is about an oddity in PGP/MIME where you can try to convert a
plain signature into a PGP/MIME signature, it is good if that can be
inhibited. After all it only worked in certain situations (depending on
the canonization of line endings) and this method was never suggested.
>> - when those fields are sometimes signed (v5) and sometimes not (v4),
>> it's difficult to act on them safely
Improving the security of a protocol takes time and is not easy. But
it is better to provide the mechanisms now so that they can be used in
the future.
> All of these may be resolved on implementation level, not the standard
> level.
Right.
Salam-Shalom,
Werner
--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://librepgp.org/pipermail/librepgp-discuss/attachments/20240116/70f70110/attachment.sig>
More information about the LibrePGP-discuss
mailing list