ietf-openpgp
[Top] [All Lists]

Re: Comments on current draft

1997-12-03 11:34:32
On Wed, 3 Dec 1997, Tony Mione, <mione(_at_)boeing(_dot_)rutgers(_dot_)edu>, 
wrote:
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.
...

This is just introductory and expository and is intended to give a broad
overview of the process, not constrain an implementation.

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.

It's not a matter of matching hash codes, it is a matter of running it
through the signature verification algorithm.  I agree that the "keeps a
copy" wording is unclear.

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.

This is not historical, it is how it works.  Some gateways munge messages
by altering trailing whitespace, and this allows such messages to verify
correctly.

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)?

1 octet, but counted strings are not used.

5) Section 3.5.3.3:

...
      count of octets to be hashed = (16 + CMANT) << (CEXP + 6)
...

      Just curious? Why the constants 16 and 6?

The 16 is the implicit first bit, as is standard for floating point
formats.  The 6 is a normalization so that a more useful range of values
can be expressed.

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).

Yes, Bill Stewart suggested something similar.  Personally I would
prefer not to make any of them mandatory but perhaps it is necessary as
a temporary measure so that current software can work efficiently.


      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?

Hash algs would normally be chosen by the signer.  They are closely
related to the choice of signing key.  For example, DSS requires SHA.
It doesn't work well for the message recipient(s) to try to say how it
should be hashed for signing, since normally we sign before encrypting
(possibly long before).

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')

Good point.  We need to document the regexps.

      That's all for now. Have fun.

Thanks for your comments!

Hal Finney
hal(_at_)pgp(_dot_)com
hal(_at_)rain(_dot_)org

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