Subject: Re: minor typos/points?

From: [email-masked]
Date: Mon, 22 May 2000 08:45:29 -0700

>    5.2.3.4. Issuer
>
>       (8 octet key ID)
>
>       The OpenPGP key ID of the key issuing the signature.
>
>       MUST be present in the hashed area.

keyid can be unhashed.  I'm not sure it makes sense to have a mandatory
unhashed packet, since unhased packets can have no security properties.

> section 5.6 says:
>
>    Typically, this packet is found as the contents of an encrypted packet, 
>    or following a Signature or One-Pass Signature packet, and contains 
>    literal data packets.
>
> does this mean that multiple contiguous literal data packets can be
> compressed into a compressed data packet?  if so, how is an
> implementation supposed to interpret multiple literal data packets
> contained in a single compressed data packet?

This is an area of ambiguity we have run into.  Can you put multiple
literal data packets into compressed or encrypted data?  Can they be
inside/after signature packets?

My feeling is that it should be allowed.  Literal packets can have file
names associated with them and so this would be an efficient mechanism
for transferring multiple files.  I don't know what the current
implementations do.

> section 6.1 has:
>
>   #define CRC24_POLY 0x1864cfbL
>
> should this not be:
>
>   #define CRC24_POLY 0x864cfbL

Not if you want the code to work... note the line where that constant
is used, the high "1" is used to clear a "1" in the crc variable.

> section 11.2 says:
>
>    A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet
>    Tag, followed by the two-octet packet length, followed by the entire
>    Public Key packet starting with the version field.
>
> strictly speaking, this seems to imply that only old packet format packets
> can be used.  i presume that is not what is meant.  how about the following
> wording:
>
>    A V4 fingerprint is the 160-bit SHA-1 hash of the entire Public Key
>    packet (i.e. the entire packet header and all of the packet body fields).

No, it has to be a two byte length.  The length must be canonicalized
to two bytes.  Otherwise there may be ambiguity in that the same length
can be expressed in different forms.

> section 11.2 says:
>
>   a.2) high order length octet of (b)-(f) (1 octet)
>
>   a.3) low order length octet of (b)-(f) (1 octet)
>
> what does (f) refer to here?

Should be (e).

> section 12.1 says:
>
>   Note also that if an implementation does not implement the preference,
>   then it is implicitly a TripleDES-only implementation.
>
> what does the phrase "the preference" refer to?  does it mean if an
> implementation doesn't implement a system of preferences?

More specifically, that it doesn't support the preferred algorithm
subpacket.  It doesn't create them, it doesn't read them.  It should
always use triple des.

Hal

---

From: [email-masked]
Date: Tue, 23 May 2000 12:16:35 +0900

From: [email-masked]
Subject: Re: minor typos/points?
Date: Mon, 22 May 2000 08:45:29 -0700
Message-ID: <[email-masked]>

> unhashed packet, since unhased packets can have no security properties.

so, the issuer subpacket should not be mandatory then?

> for transferring multiple files.  I don't know what the current

i wonder about how well this would work w/ mime.  for mail situations,
i wonder whether it wouldn't be simpler and easier for users and
implementors to either tar or zip up multiple files as a single file
or to attach multiple files.

for situations where the data is being processed directly by an
openpgp implementation, processing multiple contiguous literal data
packets seems fine...but openpgp and zip seem to be merging :-)

> Not if you want the code to work... 

doh!

> note the line where that constant is used, the high "1" is used to
> clear a "1" in the crc variable.

how about the following code then?  i think it would make the text and
the code eaiser to understand and thus help prevent the question that
i asked from being asked again in the future (hopefully, it wouldn't
generate additional ones).

       #define CRC24_GENERATOR 0x864cfbL
       #define CRC24_POLY (CRC24_GENERATOR | 0x1000000L)

> can be expressed in different forms.

ok i understand.  i see i was completely off regarding the old format
packets.

how about adding an explicit note in the rfc noting that the length
must be canonicalized to two bytes to prevent ambiguity in expressing
a particular length?  

i presume that two-octet lengths are sufficient for all the relevant
key sizes...

i keep wondering why there are even one-octet and two-octet lengths in
new format packets.  it seems far simpler to just have five-octet and
partial lengths.  are there significant advantages to having one- and
two-octet lengths?

> subpacket.  It doesn't create them, it doesn't read them.  It should

thanks for the clarification.

---

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 23 May 2000 07:40:44 -0500

In <[email-masked]>, on 05/22/00 

>i wonder about how well this would work w/ mime.  for mail situations, i
>wonder whether it wouldn't be simpler and easier for users and
>implementors to either tar or zip up multiple files as a single file or
>to attach multiple files.

>for situations where the data is being processed directly by an openpgp
>implementation, processing multiple contiguous literal data packets seems
>fine...but openpgp and zip seem to be merging :-)

I always make it a practice to zip even individual files *before*
encryption and sending. Zip seems better at dealing with file system
issues better than PGP is (CRLF<->LF conversions, preserving EA's,
...ect).

-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 26 May 2000 08:49:53 +0900

From: "William H. Geiger III" <[email-masked]>
Subject: Re: minor typos/points?
Date: Tue, 23 May 2000 07:40:44 -0500
Message-ID: <[email-masked]>

> issues better than PGP is (CRLF<->LF conversions, preserving EA's,

i would be interested in seeing concrete examples demonstrating the
differences.  can you provide any?