[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Photuris



Thank you for the detailed review.  I have grouped these together for
ease of processing:

> From: rivest@theory.lcs.mit.edu (Ron Rivest)
> Page 17 (Initiator-Offered-Attributes)
> Page 20 (Responder-Offered-Attributes)
>
> 	It is not clear exactly what is intended by "three or more"
>         Security Parameter Attributes.  Is the number three somewhat
>         arbitrary, or is there some rationale (like maybe I'm supposed to
>         choose one encryption algorithm, one authentication algorithm, and
>         one signature algorithm at least)?  If the number is just arbitrary,
>         it would help to say so.
>
Actually, 3 is the minimal number of attributes which are required to be
supported.  Therefore, the list will always be 3 or more....

         *  *  *  *       5  MD5
            *            17  DES-CBC, 32-bit IV
      *     *            18  DES-CBC, 64-bit IV

added "three (minimum required) or more"


> Page 22: It is not described anywhere what the recipient is supposed to
>          do with the "LifeTime" variable in the Signature_Message.
>          If this is not used by the recipient, it should be omitted.
> 	 (Presumably it should documented what is to be done with this
>          by the recipient.)
>
Good idea.  Actually, the LifeTime is first described under Expiration
in Chapter 1, but an additional explicit section is useful in Security
Parameters as well.

    Each SPI has an associated LifeTime, specified by the SPI owner
    (receiver). The SPI can also be deleted by the SPI Owner using the
    Change_Message. Once the SPI has expired or been deleted, the
    parties cease using the SPI, and purge the associated state.


> Page 24, section 5.2, second paragraph:
> 	
> 	 "The fields protected are described for each method."  I don't
>          see where these descriptions are, and I don't see why they should
>          differ for different "methods."  More explanation is needed here.
>
It currently says (see "Attribute List" Appendix).

In the only described method thus far (DES-CBC), the IV and encrypted
fields are 64-bit aligned.  There may be methods in which the privacy
can take place beginning at the LifeTime, or cover the SPI, for example.
I wanted to leave this open as a possibility.

How about:
    The fields protected, the length of the Padding (if any), and other
    details are described for each Anonymity-Choice method. A single
    non-negotiable key generation cryptographic hash is specified to
    create a special anonymity session-key. See the "Attribute List"
    Appendix for details.


> Page 24: Is padding required even if encryption is not specfied?
>
Added:
    This field is always present, even though no Anonymity-Choice is
    specified or no Padding is required.


> Page 24, line  7: "size of the Padding field" -->
>                   "size of the Padding field in octets"
>
Fixed.


> Page 43: It is not specified what the lengths are of the "Type" and "Length"
>          fields themselves.  Are these supposed to be single bytes, or to
>          be inferred from the figure, or what?
>
Single bytes, inferred from the figure.  (This is traditional RFC format,
and each +-+ is one bit.)

However, I see that I have not been consistent here, as some places the
size is specified, and others it is not.  Also, I have not been
consistent in using words versus numbers, and capitalization.  Fixed.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2