ietf-openpgp
[Top] [All Lists]

content tag, format, terminology

1997-08-06 09:23:15
There is a general problem with inconsistent terminology.

I suggest that "octet" be changed everywhere to "byte", with a short
section defining byte.  Here's what I use:

1.1.  Terminology

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [RFC-2119].

   byte             An 8-bit quantity; also known as "octet" in
                    standardese.

====

The term "packet" is simply wrong.  A packet is a link-layer term.

I suggest that "packet" be changed everywhere to "element", which would
be consistent with other sections of the draft, including section titles
using element.

====

And then there is the problem of the "cipher type byte", which does not
define a cipher, and which contains a "tag".  Please change the name to
"Content Tag Byte", which should not be too hard.

Many of the possible combinations of the CTB are not legal, or are never
generated.  The draft is confusing.  A better organization would be a
simple tabular list of the legal values and formats of the CTB.

Here's what I suggest:

hex     element                                 length  version
===     =======                                 ======  =======
00..83  Reserved
84      Public-Key-Encrypted Session-Key        1-byte  2.3.x
85      Public-Key-Encrypted Session-Key        2-byte  2.6.x
86..87  Reserved
88      Signature                               1-byte  2.3.x
89      Signature                               2-byte  2.6.x
8A..93  Reserved
94      Secret-Key
(etc.)
  ..C0  Reserved
C1      Public-Key-Encrypted Session-Key        n-byte  5.0.x
C2      Signature                               n-byte  5.0.x
(etc.)

Reserved.  A CTB MUST NOT have a tag with this value.

====

And that n-byte length definition needs work.  Very hard to understand.

Worse, it is really rather ugly.  Why have the 0..191 1-byte variant?
Why not start with 2-byte length for everything?  Are we really
encouraging smaller than 256-bit moduli?

OK, I suppose we are stuck with 0..191 for compatibility.

But the next step should be changed.  After all, you are bringing this
to the IETF for standardization; the IETF will have change control.

That power of two variant should be tossed.  Is it ever used?

In this case, I recommend that the stepping be this:

hex     decimal length  formula
===     ======= ======  =======
00..BF  to 191  1-byte  0 .. 191
C0..EF  to 239  2-byte  ((b[1] - 192) * 256) + b[2] + 192
                aka     b[1..2] - 2**15 - 2**14 + 192
                aka     b[1..2] - 48,960
                aka     192 .. 16,575
F0..FB  to 251  3-byte  b[1..3] - 2**23 - 2**22 - 2**21 - 2**20 + 16,576
                aka     16,576 .. 1,065,151
                aka     much too much for IP
FC..FF  to 255          reserved

WSimpson(_at_)UMich(_dot_)edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson(_at_)MorningStar(_dot_)com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

<Prev in Thread] Current Thread [Next in Thread>