ietf-openpgp
[Top] [All Lists]

Re: Notation packet for PGP/MIME ability

2005-01-16 09:25:14

On Thu, Jan 13, 2005 at 09:07:29AM -0800, "Hal Finney" wrote:

Regarding the location of the preferred email format notation packet, I
should have made it clear that this is a subpacket in the self-signature
on the userid.

As far as human-readability, it's true that it might be more convenient
in terms of compatibility with existing code to use an array of numeric
values.  But human readability has some advantages, too.  It allows
notation packets to be displayed to users even when the software doesn't
understand what they mean.  Utilities like pgpdump and gnupg's built-in
dumper can probably already display this notation packet.  It doesn't
help all that much for what we are doing in this particular case but it
does add to the transparency and understandability of the overall system.

Note that pgpdump and GPG's dumper can display either human or machine
readable notations.

I do understand the desire for more transparency, but the "regular
user" is not going to examine a key packet-by-packet to determine
whether to send PGP/MIME or not.  They're going to let the system
handle such details for them.

Thinking about it some, one good reason to be human-readable is to
allow earlier versions of programs to partcipate in this.  GnuPG does
have a --cert-notation option which lets users set notations on key
signatures (including self-signatures), but this is not really
workable for this.  Once set, users cannot change such notations
without deleting and recreating the whole self signature (and then
item-by-item replacing the various preferences, feature flags, etc).
I forsee a lot of user confusion there, as the --cert-notation option
was never really designed for self-signatures and this kind of use.
GPG will need new code to allow users to set and unset this mail
preference in the way they'd expect - the way they can set and unset
all other preferences.

Since it needs new code anyway, I'd much rather be able to leverage
the existing preference code.  The standard has three preference
lists, all done the same way.  This would be the only different one.

I want to emphasize that I'm not arguing against the idea of a mail
encoding preference.  I think it's a excellent idea, and have argued
for it in the past.  I'd just much rather have a simple array of bytes
for speed and ease of both implementation and use.

David