Subject: Comments on dhpop-02

From: Denis Pinkas <[email-masked]>
Date: Tue, 26 Oct 1999 12:35:25 +0100

Comments on draft-ietf-pkix-dhpop-02

The following comments are mainly presentation and vocabulary
oriented.

For the presentation, I read the document twice but could not have a
clear view of the description being made. I would guess that I would
need much more time to understand it, which I don't have.

This means that the document should be improved to ease the reading.
In particular the document refers upfront to two algorithms which
are not clearly referenced afterwards. The relationship between
sections 3,4 and 5 is not crystal clear.

My main concerns are vocabulary related. The document makes use of
the word "signature" whereas no signature is ever involved. 

I understand a signature as being verifiable by anyone. If it is
only verifiable (and thus forgeable) by one verifier, then it is
only an integrity check value.

The use of the word "signature" should be avoided and several
replacements are proposed. 

The current abstract is:

This document describes two methods for producing a signature from a
Diffie-Hellman key pair.  This behavior is needed for such
operations as creating a signature of a PKCS #10 certification
request.  These algorithms are designed to provide a proof-of-
possession rather than general purpose signing.

I would propose the following:

This document describes two methods for producing an integrity check
value from a Diffie-Hellman key pair.  This behavior is needed for
such operations as creating an integrity check value of a PKCS #10
certification request.  These algorithms are designed to provide a
proof-of- possession rather than general purpose signing.

Then, in the introduction, I would propose:

This document describes two new data origin authentication
algorithms using the Diffie- Hellman key agreement process to
provide a shared secret as the basis for the construction of an
integrity check value. With the first algorithm, the integrity check
value is constructed for a specific recipient/verifier by using a
D-H public key of that verifier.  With the second algorithm, the
integrity check value is constructed for arbitrary verifiers.  This
is done by creating an appropriate D-H key pair and using it for the
creation of the integrity check value.

The title of section 2 should be " Using DH Ephemeral keys for the
authentication process" and the next sentence: 

   The steps for creating a DH-based integrity check value are:

This does not provide all the changes required in the document but
gives the general direction for the replacements.

And additional unrelated topic. LeadingInfo and TrailingInfo are
introduced in section 3, page 3, item c) but only explained on the
next page in section 4. It would be good to move the explanations in
section 3. 

Denis