-----BEGIN PGP SIGNED MESSAGE-----
Here are some comments on the first half of
draft-ietf-openpgp-formats-00.txt. Some are nits. Take them for what they
are worth.
0) Before I start, I will quote from the page header:
...
Callas, et. al. Expires May 1998 [Page 1]
^L
Internet Draft OpenPGP Message Format Nov 1998
...
^^^^^^^^OOPS!
(I remember....doing the TIME WARP!)
1) There are a few places where the wording suggests and order in which
message processing must take place. It would be better to word things such
that the implementor can decide order of operations as long as the elements
are processed in the correct manner (i.e. hashes are applied to the correct
octet string, etc). One example is on page 4, section 2.1:
...
Both digital signature and confidentiality services may be applied to
the same message. First, a signature is generated for the message and
attached to the message. Then, the message plus signature is encrypted
using a conventional session key. Finally, the session key is
encrypted using public-key encryption and prepended to the encrypted
block.
...
2) Section 2.2:
...
1. The sender creates a message.
2. The sending software generates a hash code of the message
3. The sending software generates a signature from the hash code using
the sender's private key.
4. The binary signature is attached to the message.
5. The receiving software keeps a copy of the message signature.
^^^^^huh?
Better:
5. The receiving software decrypts the signature with the sender's
public key and saves that hash code.
6. The receiving software generates a new hash code for the received
message and verifies it using the message's signature. If the
^^^^^^^^^^^^^^^^^^
verification is successful, the message is accepted as authentic.
^^^^^^^^^^^^^^^^^^^^^^^^^^
Better:
6. The receiving software generates a new hash code for the received
message. If the new hash code matches the hash code derived from the
signature, the message is accepted as authentic.
...
3) Section 2.6, last paragraph:
...
Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
any line is ignored when the cleartext signature is calculated.
...
Is this text historical? It seems counter intuitive to me to modify
the text of a message in any way before signing it.
4) Section 3.3:
...
A counted string consists of a length and then N octets of string data.
...
How long is the length (1 octet, 2 octets, same length encoding as
the packet length calculations in section 4.2)?
5) Section 3.5.3.3:
...
count of octets to be hashed = (16 + CMANT) << (CEXP + 6)
...
Just curious? Why the constants 16 and 6?
6) Section 5.2.2.2:
It would be good to specify which subpackets are required and which
are optional (or under which conditions they are required/optional). There
are hints in the text, but it would be good to be explicit (perhaps a small
table would make this clear).
Also:
...
{{Editor's note: The above preference (hash algs) is controversial. I
included it in for symmetry, because if someone wants to build a
...
Why is this controversial?
7) Further down in the same section:
...
Regular expression (null-terminated regular expression) (Hashed)
...
Which implementation of regular expressions? (See O'Reilly's
'Mastering Regular Expressions')
That's all for now. Have fun.
Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
mione(_at_)nbcs-ns(_dot_)rutgers(_dot_)edu W3:
http://www-ns.rutgers.edu/~mione/
PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F
Editorial Advisor for Digital Systems Report ***** Important: John 17:3 *****
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNIVpp/MKRuSgNA5pAQG2eQL+OgQqIXF1hoGKQ7stPi9LbpRuqj99GeKu
cZaKrQji+TeIBDbFbWyTsEVp9LeQh2Wq+Ccu7YbFNZBtJ5blJjqkpwur2D0OmAC0
K9nFjl2EIoMf9VxE3wW9Ec78qLIxtXcd
=bZeC
-----END PGP SIGNATURE-----