Re: 3rd try at Algorithms Section

Hi Jim,

From:  "Jim Schaad" <jimsch5@home.com>
Reply-To:  <jimsch@exmsft.com>
To:  "'Donald E. Eastlake 3rd'" <dee3@torque.pothole.com>,
            <xml-encryption@w3c.org>
Cc:  <lde008@dma.isg.mot.com>
Date:  Wed, 13 Jun 2001 12:26:20 -0700
Message-ID:  <001101c0f452$b86e0ed0$0e00a8c0@soaringhawk.net>
In-Reply-To:  <200106110445.AAA0000049220@torque.pothole.com>

>There are a couple of issues that I still have on this section.
>
>1.  I would like to add a paragraph along the following lines:
>"The working group decided to include the IV as part of the cipher text
>stream in order to allow for the encryption method parameter to be omitted.
>Good cryptographic practice requires that a different random IV  be used
>with every block algorithm. If the IV were specified as part of the
>encryption method, either the IV would have to be implicitly known by the
>decryptor or the encryption method structure would be required to exist in
>order to carry the IV."

I have added some words here...

>2. I do not like the fact that a schema has been proposed for
>EncryptionMethod that provides for an amalgamation of different parameters
>from various different algorithms.  I can see somebody attempting to set the
>KeySize parameter with 3DES and not getting expected behavior.  The values
>of 112, 128, 168 and 192 are all reasonable values to place into that
>structure for the uninitiated (and would be logical to include if doing key
>derivation potentially).  I strongly prefer having each algorithm define the
>parameters it needs in it's namespace.

Schema does not provide any way to make the presence of child elements
conditional on an attribute value.  I have made some minor changes
including adding language prohibiting the presence of any child
parameter elements not specifically permitted by the algorithm in use.
So attempting to provide, for example, a KeySize to 3DES should produce
an error.

>3. You omitted using most of my comments on DH.  KeyInfo is suppose to
>contain within it one or more methods of retrieving the same key value.  The
>inclusion of the AgreementMethod item violates this principle.  The
>information to do key agreement is part of the DH encryption method and
>should be placed at that location.

I'm not sure exactly what comments you are talking about.

True, you caught me in violating the definition of KeyInfo that each
child is supposed to give information that would enable you to know
the key.  It's not the presence of AgreementMethod that violates that
but the presence of a KeyInfo at the same level as AgreementMethod
which must be combined with AgrementMethod.  I've changed this so both
needed keys are explicit parameters to AgreementMethod.

>jim

I'm about to post version 4 which, while I'm sure it isn't perfect, is
probably well enough along that it could be spliced into the overall
document.

Thanks,
Donald

Received on Monday, 18 June 2001 13:09:42 UTC