Subject: critical notation data sub-packets

From: Thomas Roessler <[email-masked]>
Date: Tue, 25 May 1999 13:55:19 +0200

The specification is a bit ambiguous about "notation data" signature
subpackets marked as "critical".

Implementors may assume that their implementations can safely ignore
such subpackets since they do "understand" "notation data".  This
may lead to problems with human-readable notation data whose display
to the user may be critical for whatever reason (including legal
ones, think liability limitations), and it may lead to even worse
problems with notation data which is not human-readable.

How do the current implementations handle this situation (most
notably the NAI ones)?  Should the specification be changed?  Should
extensions to RFC 2440 which have to put critical information into
signatures define sub-packets of their own, or should they use
notation data to avoid name-space cluttering?

---

From: Werner Koch <[email-masked]>
Date: Tue, 25 May 1999 15:31:11 +0200

> subpackets marked as "critical".

I don't think so:  If an implementation encounters notation data with
critical bit set and it completely understands the semantics of this
notation data, it can verify the signature.  

To understand this notation data the implementaion might also want to
consult the policy URL to distinguish between different semantics.

The critical bit does not say anthing about how to handle this
subpacket; the implemenation is only required to understand that this
is critical and there is no required action defined for any
subpackets.  I don't think this is within the scope of OpenPGP. 
Definitions of the trust modell and the classes of signatures are 
are on purpose very loose.

> signatures define sub-packets of their own, or should they use

We should avoid to use private sub-packets when there is another way 
to do the task. 

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 26 May 1999 12:13:36 +0200

On 1999-05-25 15:31:11 +0200, Werner Koch wrote:

> We should avoid to use private sub-packets when there is another
> way to do the task.

I'm not thinking about private ones. ;-)

The current spec says:

   This subpacket describes a "notation" on the signature that the
   issuer wishes to make. The notation has a name and a value, each
   of which are strings of octets. There may be more than one
   notation in a signature. Notations can be used for any extension
   the issuer of the signature cares to make.

While this is really fine for private extensions, I see a problem
with using notation data to put information into a sigature
sub-packet in a standardized way.  Essentially, we are lacking a
registry (or a conflict-free naming scheme) for notation data names.

So, to the working group: Should standardized signature extensions
go into sub-packets of their own, or should one start to standardize
certain notation data names?

---

From: Jack Repenning <[email-masked]>
Date: Thu, 27 May 1999 12:36:15 -0700

>certain notation data names?

What about the rfc822 weasel:

     extension-field =
                   <Any field which is defined in a document
                    published as a formal extension to this
                    specification; none will have names beginning
                    with the string "X-">
 
     user-defined-field =
                   <Any field which has not been defined
                    in this specification or published as an
                    extension to this specification; names for
                    such fields must be unique and may be
                    pre-empted by published extensions>

I don't believe there's any clearing-house for user-defined-field names (is
there?). 

Informix Software, Inc.        Jack Repenning
Config/Release Mgmt            [email-masked]
4100 Bohannon Drive            M/S: 4100/2
Menlo Park, CA 94025           FAX: 650/926-6571
VOICE: 650/926-1044               PAGE: 800/781-6182
PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E
PGP/DSS: 955C 44AD 8FCE 77D4 9494 \
          : 4AB2 51F1 3EED 3B82 E870

---

From: Jon Callas <[email-masked]>
Date: Thu, 27 May 1999 17:03:06 -0700

The purpose of the notation subpackets is to have a general-purpose
mechanism for implementors to put in their own extensions, so yes, people
should (in general) use those for any private or controversial additions to
signatures.

Sooner or later, we probably will need a registration system for them, or
some naming convention. Right now, there are a number of obvious things you
can do to restrict conficts, like prefixing your notation name with a
domain name (like foobar.com-private-value) and that will work.

This saves the subpacket versions for something we know we need -- for
example a subpacket that has an implemented features list (like MDC data
packets).

As for the critical bit, in my opinion, it is a way for the writer of a
signature to tell something to the reader. The reader, though, always has
the final say. A few examples:

A human-readable subpacket that's marked critical seems to be something
that the writer really wanted the reader to see. But the reader's software
may have an option to turn it off. I can see where someone might put
human-readable limits of liability or other such crud in there, and I don't
want to have legalese pop up in a window every time I use someone's key.
(But in such a case, I might solve it by deleting that signature,
personally.) So it's perfectly reasonable for an implementation to ignore a
critical human-readable notation. Similarly, a system that's running as a
robot is correct to ignore a critical human readable subpacket.

I think that it's merely impolite (as opposed to non-compliant) for an
implementation to ignore a critical bit. I'll spin another scenario.
Suppose XYZcorp makes an OpenPGP implementation, and they create some
feature that they want everyone else to support, so they mark it as
"critical" in all signatures they create. It's obnoxious, but it wouldn't
be the first time a vendor tried to bully features into a standard. If
another vendor ignored all critical bits on notations that started with
"xyzcorp.com" because of abuse of criticality, I wouldn't call them
non-compliant. If a different vendor was even more gonzo, again, it's up to
users to appeal to them to do the right thing (whatever than means). I
don't want to see it be a standards issue.

This is also the reason why we have a "receiver wins" policy in algorithms.
It is to forestall the case where someone tries to force their feature on
the world.

	Jon