Subject: Re: Some -15 comments

From: [email-masked] ("Hal Finney")
Date: Mon, 14 Nov 2005 15:37:44 -0800 (PST)

Jon writes, quoting David:
> > We discussed a change to 5.2.3.16 (Notation Data) on the list to
> > change:
> >
> >      First octet: 0x80 = human-readable. This note value is text, a
> >                          note from one person to another, and need
> >                          not have meaning to software.
> > to:
> >      First octet: 0x80 = human-readable. This note value is text.
> >
> > Any way that can go in?  I'm perfectly happy to get an "I Told You So"
> > if someone is confused :)
> >
>
> I remember the discussion, I just don't remember the agreement. Such  
> is the way with rough consensus.
>
> Does it matter one way or the other? I admit to being confused as to  
> why it matters. Enlighten me, please.

What is the functional purpose of this flag?  The meaning of the notation
is going to come from its name field.  The flag is somewhat superfluous.

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.

David's second version better expresses this, IMO.  By just saying
that the note value is text, that means it is reasonable to print it
if desired.  Even software which doesn't understand the meaning of the
notation could print it, and it would be readable.

The current wording carries much more baggage which IMO is not accurate.
We might want to set the human-readable flag on notation packets which
are not primarily meant as notes from one person to another.

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.

PGP Corporation added the preferred-email-encoding self-signature notation
packet, and it has the human-readable flag set.  This is not a note from
one person to another, rather it is intended solely to be handled by
the software.  However it is human readable and if the key is displayed
in some detailed way it would be reasonable for the software to print
the contents of the notation packet.

Hal Finney

---

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

> 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.

> are not primarily meant as notes from one person to another.

I agree with this.
 
> 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.

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.

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Mon, 14 Nov 2005 20:58:52 -0500

> what I would like to use it for.

I think what you are saying and what Hal and I are saying are
basically compatible: interpret the human-readable flag as "I can
print this".

> wheter he accepts a signature or not.

There is no conflict here either.  It is perfectly fine to print
notations on signature verification if you choose to do so.  The
problem is if you have a critical notation that your implementation
does not handle.  You can print this notation or not (it's up to you)
but the important thing is that the unhandled critical notation isn't
treated as handled just because you print it.

> responsibilities are indeed met by just displaying it upon verification.

That's fine.  You can define a notation type any way you like.  It's
perfectly reasonable to define your notation to meet its critical
"contract" by being shown to a user.

David

---

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

> basically compatible: interpret the human-readable flag as "I can

But how to express "you should print this"? I tought the text flag and the
critical flag together were for this very purpose.

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Mon, 14 Nov 2005 21:23:28 -0500

> critical flag together were for this very purpose.

You would define a notation ("[email-masked]" or
the like), which is defined as "show me to a human".

You don't want to overload the human-readable flag for that, since
there are some human readable notations that while being *capable* of
being read by a human, aren't intended for reading by a human on a
regular basis.

David

---

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

> the like), which is defined as "show me to a human".

Sure.
 
> being read by a human, aren't intended for reading by a human on a

I understand that and even agree with it in the light of the fact that
there's already notation in wide use that is not intended for human
interpretation. But I think that a flag indicating that some notation IS
intended to be interpreted by humans is still warranted, using a wording
similar to the original definition of the text flag, perhaps with some
clarification added. Like this:

        First octet: 0x80 = displayable. This note value is text.

                     0x40 = human-readable. This note value is text, a
                            note from one person to another, and need
                            not have meaning to software. If critical,
                            it MUST be displayed whenever the successful
                            verification of the signature is reported to
                            the user

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Mon, 14 Nov 2005 23:33:32 -0500

>                             verification of the signature is reported to

I'm not sure what benefit this has over just defining a notation with
whatever semantics you desire.  This flag, in effect, lets someone
change the semantics of notations they do not own.

David

---

From: Jon Callas <[email-masked]>
Date: Tue, 15 Nov 2005 09:29:53 -0800

> critical flag together were for this very purpose.

The critical flag can called (only slightly humorously) the non- 
interoperable flag.

Normally, when an implementation sees any subpacket it doesn't  
understand, it ignores it. But with the critical flag, you error out  
if you don't understand it.

So ihf you create a human-readable, critical notation, you're asking  
for it to blow up a lot. This may be exactly what you want, but it  
might not.

Now this can create side issues, as well. Let's suppose that I have  
built an automated system (one with no humans). I know exactly what  
your notation is, but I have no human. So I ignore the thing. To me,  
this follows exactly the spirit of "critical" because I know what it  
is and I know I can ignore it. It may not be what you want -- you may  
have thought that human-reable and critical means it will blow up any  
automated process.

Similarly, I might display the notation to a human user and have a  
"please don't show this to me again" check box to have it not  
displayed again. This is a reasonable thing to do, despite a critical  
flag.

This is why I put my tongue in my cheek a bit and call it also the  
non-interoperable flag. If you set the critical flag, you create all  
sorts of interesting ways for the system to surprise people.

	Jon