Subject: Re: Some -15 comments

From: [email-masked] ("Hal Finney")
Date: Tue, 15 Nov 2005 10:16:57 -0800 (PST)

Jon Callas writes:
> 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.

That's not my understanding.  Rather, you don't consider the signature
valid, if there is a critical subpacket you don't understand.  You don't
"error out."

Now, for document signatures, failure to understand a critical notation
may in some cases be as bad as erroring-out, because whatever purpose
was meant to be expressed by creating the signature, won't happen.
But for keyring signatures, which are often redundant, we could for
example imagine a signature which says, I am not vouching for the binding
between userid and key, but rather I am making a certain assertion about
this userid or key.  If we don't understand this notation the correct
thing is to ignore the signature, and that is in fact what the spec says
should happen.

Critical notations allow implementors to essentially extend signature
semantics beyond the official set of signature types.  We have a protected
namespace for proprietary extensions, and we have the ability for legacy
applications silently to ignore unrecognized extensions.  It's a good
feature.

Hal Finney

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 16 Nov 2005 03:07:20 +0100

> thing is to ignore the signature, and that is in fact what the spec says

Yes, that is my understanding as well. Critical notation means that it is
essential for the correct interpretation of the signature and without
understanding the notation the signature is meaningless.

> applications silently to ignore unrecognized extensions.  It's a good

I agree.

As for the subject of our discussion, I think that we all agree that the
spec for 0x80 should be stripped of "a note from one person to another..."
bit., because one major implementation does not treat it that way.

The only disagreement seems to be whether "a note from one person to
another" should be retained as an interoperable feature or should it be
delegated to private notation namespace.

The disadvantage of the  latter approach would be that various implementers
would (possibly) implement this same semantics with a host of different
notation names and won't interoperate.

Now, I can see that implementing the former using a type flag also causes
problems. Maybe, it should be a common, ITEF-namespace notation? Or an
entirely separate subpacket type akin to "reason for revocation"?

I am not sure. But in either case, as far as immediate modifications to the
standard text are concerned, this "a note..." part should be removed from
the definition of 0x80, because it means something that 0x80 definitely
doesn't. Whether or not to add that text someplace else is  an entirely
different question.

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Wed, 30 Nov 2005 10:47:25 -0500

> doesn't. Whether or not to add that text someplace else is  an entirely

Is this rough consensus?

David

---

From: Werner Koch <[email-masked]>
Date: Wed, 30 Nov 2005 17:20:55 +0100

> Is this rough consensus?

I concur.

Salam-Shalom,

   Werner