Subject: Re: New packets in PGP 6.0

From: Werner Koch <[email-masked]>
Date: Wed, 9 Sep 1998 09:11:44 +0200

Jon Callas <[email-masked]> writes:

> The PGP developers argued that they should not use the experimental range
> because doing so would de-facto use up that opcode because of all the
> copies of PGP 6 that would use it. I see their point, but I diagree.

Suggestion for the future:  Include some magic bytes to packets in the
experimental range, so you can decide whether it is your experiment or
not; same goes for the experimental subkey types.

Werner

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 9 Sep 1998 14:38:35 +0200

On Wed, Sep 09, 1998 at 09:11:44AM +0200, Werner Koch wrote:

> Suggestion for the future: Include some magic bytes to
> packets in the experimental range, so you can decide
> whether it is your experiment or not; same goes for the
> experimental subkey types.

Actually, one may wish to formalize a procedure for such
private extensions.  The secsh (ssh) internet-drafts have
a nice mechanism for this: They are using textual values
for about all algorithm IDs, etc.  Experimental or local
IDs always have the form <local id>@domain, where domain
is a DNS domain under the control of the entity which
creates the experimental ID.  For OpenPGP, one could think
of an "experimental" packet ID which _must_ be followed by
a string constant containing a local packet ID like the
one I just described.  The rest of the packet will then
conform to whatever the extension wants.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

---

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 09 Sep 1998 08:42:17 -0500

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/08/98 
   at 11:35 AM, Jon Callas <[email-masked]> said:

>You are indeed correct that it's a faux pas that it uses 17 for the
>packet id and not something in the 60-63 range. I argued the same thing
>here at NAI, but I lost that debate. I discussed it with John Noerenberg,
>who agreed that it was a faux pas, but not a big one -- especially given
>that the WG consensus was that there should be an implementation first.
>Nonetheless, I agree with you on *that* part of it wholeheartedly. The
>NAI developers are running the risk that OpenPGP 1.1 will define non-text
>user ids to be something incompatible with what they did for PGP 6, and
>they'll have to adapt.

>copies of PGP 6 that would use it. I see their point, but I diagree.

Just to make things clear, I do not have a problem with NAI comming up
with something new for PGP, nor do I expect them to come to the WG for
permission to do so. My biggest objection was the grabbing of an
unassigned packet id without telling anyone about it. Now myself and
everyone else have to re-write their code to take these new packets into
account (any keys that I encounter with an unassigned packet id are
assumed to be in error and are rejected). Not major, but a PITA non the
less (FWIW I will be writting a patch for 5.0i when I have some free time
unless someone else feels up to it).

I really think that we need to establish some type of informal mechanism
for assigning numbers (packet, hash, algorithm, ect...) to prevent
problems in the future. I fear that things can get very ugly if we have 4
or 5 different vendors start using unassigned numbers whenever they have
something new to add.

Now as far as PhotoID's and ID's in general. I have mentioned in the past
for having some type of generic ID format that contained a type flag so
applications could invoke some type of sanity checking.

So lets say we have packet type 20 -- Generic ID. Then in the type field:

01 -- RFC822 E-Mail address
02 -- Real Name
03 -- Address
04 -- URL
05 -- X.500
10 -- PhotoID
15 -- Fingerprint
30 -- Retinal Scan

... ect

This seems to be a more sane approach than having a seperate packet type
for each ID format.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Air conditioned environment - Do not open Windows.

Tag-O-Matic: To whom the gods destroy, they first teach Windows...

---

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 09 Sep 1998 08:36:18 -0500

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/09/98 

>conform to whatever the extension wants.

I don't know if I really like this as it complicates the packet processing
and is also not compatable with previous versions.

What we could do is make use of the marker packet to id experimental
packets.

- -- 

Tag-O-Matic: MASOCHIST: Windows SDK programmer with a smile!

---

From: Werner Koch <[email-masked]>
Date: Wed, 9 Sep 1998 17:37:51 +0200

> So lets say we have packet type 20 -- Generic ID. Then in the type field:

Please do not continue with numeric ids; use strings (like ssh v2) to
avoid all these number assignment problems.  Numbers can still be
assigned but a registration should not be required.  Compared to a
size of Photo, the additionl bytes of a string don't count.

And this does _not_ make the processing more complicated.

Werner

---

From: Paul Koning <[email-masked]>
Date: Wed, 9 Sep 1998 13:02:54 -0400

>>>>> "Werner" == Werner Koch <[email-masked]> writes:

 Werner> "William H. Geiger III" <[email-masked]> writes:
 >> 10 -- PhotoID 15 -- Fingerprint 30 -- Retinal Scan

 Werner> Please do not continue with numeric ids; use strings (like
 Werner> ssh v2) to avoid all these number assignment problems.
 Werner> Numbers can still be assigned but a registration should not
 Werner> be required.  Compared to a size of Photo, the additionl
 Werner> bytes of a string don't count.

No, but strings don't eliminate the registration problem, because you
still need a way to ensure they are unique.  It's just that the code
space is larger which simplifies that task.

	paul

---

From: Jack Repenning <[email-masked]>
Date: Wed, 09 Sep 1998 12:14:03 -0700

>space is larger which simplifies that task.

Strings don't eliminate the _need_ for registration, but they can
piggy-back off existing registration systems (such as the DNS system for
hostname registration) - which means the availability of strings, plus a
convention such as the suggested one for using them, *does* eliminate the
registration _problem_.

---

From: Paul Koning <[email-masked]>
Date: Wed, 9 Sep 1998 15:21:50 -0400

>>>>> "Jack" == Jack Repenning <[email-masked]> writes:

 Jack> At 10:02 AM 9/9/98 , Paul Koning wrote:
 >> No, but strings don't eliminate the registration problem, because
 >> you still need a way to ensure they are unique.  It's just that
 >> the code space is larger which simplifies that task.

 Jack> Strings don't eliminate the _need_ for registration, but they
 Jack> can piggy-back off existing registration systems (such as the
 Jack> DNS system for hostname registration) - which means the
 Jack> availability of strings, plus a convention such as the
 Jack> suggested one for using them, *does* eliminate the registration
 Jack> _problem_.

Yes, any identifying mechanism with hierarchy lets you piggyback off
an existing setup.  This is why a lot of identifiers are built using
the IEEE OUI as a component, and another bunch use OIDs for the same
reason.

DNS hostnames are actually not a good choice.  Unlike OUIs or OIDs,
DNS names are subject to cancellation or revocation if you don't pay
the yearly fee and/or have your chosen name challenged.

	paul