Subject: Re: Critical bits and notations

From: [email-masked] ("Hal Finney")
Date: Tue, 10 May 2005 21:28:36 -0700 (PDT)

In my opinion, the critical bit on a notation packet should mean
that the implementation needs to recognize that particular notation,
not just notation packets in general.  Otherwise we would have no way
of expressing the requirement that the particular notation packet be
understood.

I also wouldn't say that human-readable means that it is enough to display
it.  My interpretation of human-readable is that it is OK to display it
to a person, i.e. that the data is in UTF-8, but not that displaying it
to a person is sufficient to claim full support of the packet.

Hal Finney

---

From: Werner Koch <[email-masked]>
Date: Wed, 11 May 2005 09:17:26 +0200

> not just notation packets in general.  Otherwise we would have no way

I agree.  This matches the way the critical flag of CMS' extended
attributes is used.

Shalom-Salam,

   Werner

---

From: David Shaw <[email-masked]>
Date: Wed, 11 May 2005 10:35:36 -0400

> of expressing the requirement that the particular notation packet be

That makes good sense, and I agree.  However, the text in the draft
doesn't exactly say this (and rather implies the opposite).

I suggest adding this sentence (or similar) to the end of section
5.2.3.16. Notation Data:

  When used on a notation subpacket, the critical bit refers to that
  particular notation, and not to notation subpackets in general.

David

---

From: Jon Callas <[email-masked]>
Date: Wed, 11 May 2005 16:54:01 -0700

> doesn't exactly say this (and rather implies the opposite).

I agree with Hal. I don't think that the text in the draft implies the 
opposite, however. Here's a quote:

    ... The
    purpose of the critical bit is to allow the signer to tell an
    evaluator that it would prefer a new, unknown feature to generate an
    error than be ignored.

This says to me that if you see a notation you don't understand, you 
should error out.

Notations are our extension mechanism. It strikes me as perverse to 
think that you only have to know the general concept of extensions and 
not the specific extension.

>   particular notation, and not to notation subpackets in general.

I put in:

    If there is a critical notation, the criticality applies to that 
specific
    notation and not to notations in general.

but I'll bet you a beer someone finds a creative way to misinterpret 
this.

	Jon

---

From: Ben Laurie <[email-masked]>
Date: Thu, 19 May 2005 21:43:34 +0100

Jon Callas wrote:
> but I'll bet you a beer someone finds a creative way to misinterpret this.

This whole discussion scares me. You have an extension mechanism with no 
registry for extensions.

When these things get popular, it turns out everyone hates them. cf. DNS 
TXT records.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Ben Laurie <[email-masked]>
Date: Fri, 20 May 2005 09:45:17 +0100

Werner Koch wrote:
> On Thu, 19 May 2005 21:43:34 +0100, Ben Laurie said:
> 
> 
>>This whole discussion scares me. You have an extension mechanism with
>>no registry for extensions.
> 
> 
> We do have a way to register extensions ([5.2.3.16. Notation Data]):
> 
>    The IETF name space is registered with IANA. These names MUST NOT
>    contain the "@" character (0x40) is this is a tag for the user name
>    space.
> 
>    Names in the user name space consist of a UTF-8 string tag followed
>    by "@" followed by a DNS domain name. Note that the tag MUST NOT
>    contain an "@" character. For example, the "sample" tag used by
>    Example Corporation could be "[email-masked]".
> 
>    Names in a user space are owned and controlled by the owners of that
>    domain. Obviously, it's of bad form to create a new name in a DNS
>    space that you don't own.
> 
> Where do you see the problem?

Doh! The problem lies between my chair and keyboard. Sorry.

A passing comment, though - if you want domain names to be a safe 
extension mechanism, you should include a date, since they can change 
hands (without consent of the current owner, even).

Cheers,

Ben.

---

From: Werner Koch <[email-masked]>
Date: Fri, 20 May 2005 09:24:31 +0200

Salam-Shalom,

   Werner

---

From: David Shaw <[email-masked]>
Date: Fri, 20 May 2005 20:18:00 -0400

> hands (without consent of the current owner, even).

It's also worth noting that the naming rules are often ignored in
practice.  A year or two ago, I pulled a keyring from one of the
keyservers and enumerated the notation names.  I'd have to dig up my
notes from then, but I seem to recall that around 85-90% of them were
the string "COMMENT".

(Since then, GnuPG has refused to create notation names without a '@'
in them).

David