Subject: Re: Some -15 comments

From: [email-masked] ("Hal Finney")
Date: Mon, 14 Nov 2005 17:56:19 -0800 (PST)

Daniel Nagy writes:
> On Mon, Nov 14, 2005 at 03:37:44PM -0800, "Hal Finney" wrote:
> > I'd like to use the flag as a hint to packet-dumping software: if the
> > human-readable flag is set, it is reasonable to dump the notation body
> > as text.  If it is not set, it should be dumped in hex.
>
> Currently, the way I treat this flag is that I display the notation to the
> user whenever the signature is verified. If that's not the purpuse of this
> flag, then I would really like another flag with that purpose. See below
> what I would like to use it for.

I don't think that will work too well on self-sigs with PGP Corp's new
preferred-email-encoding subpackets.  You don't want to print those out.

> > Another difference arises if the subpacket critical bit is set along with
> > the human-readable flag.  With the current wording it might appear that an
> > implementation's responsibilities are met if it somehow causes the text
> > of the notation packet to be displayed to the user, even if it does not
> > recognize the notation type.  I think that would be a serious mistake.
> > The critical bit should require that the notation type be recognized
> > and handled, in order for the signature to be considered valid.
>
> Are you sure? I actually think that displaying some notation whenever the
> signature is verified (correctly) makes a lot of sense and it may be part of
> signature verification. After all, it is ultimately the user who decides
> wheter he accepts a signature or not.

I'm worried that this is going to get too messy.  For a document
signature, if a user wants to put in some qualifications or conditions,
it is better to put them into the document itself rather than into a
notation packet on the signature in the hopes that it will be displayed.
There are no guarantees about display.

Then there are key signatures; and under what circumstances will they be
displayed?  When encrypting some email, do we want to see every notation
packet which every signer has decided to add to every key that we encrypt
to, and perhaps further packets from keys down the web of trust?  How to
organize it and present it in a coherent way?  It will be a mess.

If and when we come to the point where we need a kind of notation packet
that should be displayed on signature verification, we should define its
use and purpose, create a name for it, and spec it out.  I think that
is a better path than to have a flag with rather uncertain semantics
about when it might cause text to be displayed to the user.

> Here is how I am planning to use human-readable notation: in an on-line
> trading or auction application, where reputation tracking is important, one
> can implement user comments about other users' behavior in the form of
> signatures directly on their public keys with appropriate notation (think of
> eBay comments). The comment text is, in my opinion, critical in the sense
> that without it the signature does not make sense, but the implementation's
> responsibilities are indeed met by just displaying it upon verification.

You could still do this, but do it based on the notation name rather than
a flag.  You could have a notation called 'user-reputation-comments'
or some such.  Your application could then define whatever meaning and
handling it wanted for how this type of notation packet should be used.

Hal Finney

---

From: [email-masked] (Daniel A. Nagy)
Date: Tue, 15 Nov 2005 03:43:37 +0100

> preferred-email-encoding subpackets.  You don't want to print those out.

But that's because, strictly speaking, it is not a message meant for users,
and thus a violation of the current wording of the standard. Now, I am
fully supportive of the ITEF practice of letting the implementations shape
the standard, so if the only current implementation uses that flag in the
sense that "this is text" rather than the current wording, I am all for
changing the wording to reflect that, but I think a flag indicating that
some notation is meant (primarily) for human interpretation is warranted.

Here's why: Using this flag, implementations that are unaware of the
contract of that particular notation can still do something useful with it,
namely they can display to the user.
 
> There are no guarantees about display.

I agree with this.

> organize it and present it in a coherent way?  It will be a mess.

I don't think so. The way I see it is that such notations (critical+human
interpretable) should be displayed whenever anything is displayed about the
signature at all. For instance, when the user lists the signatures on a
particular key, such notations must be displayed along with the fact of the
existence of the signature.

> about when it might cause text to be displayed to the user.

But why not have a flag with clear semantics? Like "whenever the fact of
successful signaure verification is reported to the user, this notation must
be included in the report". I don't see any ambiguity here. And it won't
result in a torrent of messages either.
 
> handling it wanted for how this type of notation packet should be used.

But in your iterpretation of the critical flag, if I mark that notation
critical, applications not aware of its purpose would strip the signaure as
unverifiable. If I don't, I contradict the fact that it _is_ critical for
the correct interpretation of the signature.

Also, I don't feel that I am trying to force my peculiar needs on the
community. I think that many applications could benefit from notation that
is guaranteed to be displayed, when listing key signatures by all
implementataions, while being treated in some special way by those that are
aware of its purpose. A combination of "to be interpreted by humans" and
"critical" seems to express this semantics perfectly. Now, if the "text"
flag does not mean that it should be interpreted by humans, it is perfectly
acceptable. But in that case I feel that there is still a legitimate use for
another flag that does mean that the notation is meant for human interpretation.
Don't you think so?

-- 
Daninel