ietf-openpgp
[Top] [All Lists]

CTB and Length Type 3

1998-05-09 01:13:33
-----BEGIN PGP SIGNED MESSAGE-----

Hi,

I am having a little problem in parsing signed messages following the
draft documentation.

Both PGP 2.6.x & 5.0 produce the following (output as binary file):

A3 01 01 AF 00 50 FF [remained is signature block]

The first packet is a compressed packet (CTB 0xA3) with a type 3 length
(Old format). Per the docs:

4.2.1. Old-Format Packet Lengths

   The meaning of the length-type in old-format packets is:

   0 - The packet has a one-octet length. The header is 2 octets long.

   1 - The packet has a two-octet length. The header is 3 octets long.

   2 - The packet has a four-octet length. The header is 5 octets long.

   3 - The packet is of indeterminate length.  The header is 1 octet
       long, and the implementation must determine how long the packet
       is. If the packet is in a file, this means that the packet
       extends until the end of the file. In general, an implementation
       should not use indeterminate length packets except where the end
       of the data will be clear from the context. The new format
       headers described below have a mechanism for precisely encoding
       data of indeterminite length.

Obviously this is not the case as the compressed data packet does not
cover the entire file as there is a signature packet that follows.

Now the next octet (01) represents zip compression algorithm.

Where I am having problems is with the remaining 5 octets. I have read
through RFC1591 and I am still lost at decodeing the remainder of this
compression packet.

At this point I am not intrested in Inflating the data but calculating the
length of the compressed packet so I can find the start of the sig block
for sepeate processing.

Also Section 10.2 does not seem accurate as:

Signed Message :- Signature Packet, OP Message | One-Pass Signed Message.

Seems to imply that the signature packet comes first followed by the OP
Message (the opposite is the case with 2.6.x & 5.x).

Perhaps a section on the binary format of signed messages would be
helpfull for anyone that will be using this document to implement OpenPGP
in the future.

In Section 7:

  If the "Hash" armor header is given, the specified message digest             
       

  algorithm is used for the signature. If there are no such headers,            
       

  SHA-1 is used. If more than one message digest is used in the                 
       

  signature, the "Hash" armor header contains a comma-delimited list            
       

  of used message digests.                                                      
       


SHA-1 should be replaced with MD5.


Well I think that's it for right now. If someone can help out with the
compression packet it would be appreciated.

Thanks,

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: It's OS/2, Jim, but not OS/2 as we know it.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNVQRpo9Co1n+aLhhAQHwoQQAs+H4yT9J+kpKbjEXrRQ/xmqCVlhWoR5c
fGbGEQVk1hYIZlAYava1yErJUKIDjkoifbpb3cPprYEXyQWZ1r0/sV57Fnjafy0R
g8+RY+0LmEU8l8pUpUqnSi0bbM6EISFQal5FzzSIHDROfUzCyJr8X6GpivW/8TjA
TTf3Ek4S9E4=
=Ox2+
-----END PGP SIGNATURE-----


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