RE: 2nd try at Algorithms Section

Donald,

Here are my comments on your draft.

1.  The current thinking for the S/MIME working group is that 128 and 256
are going to be MUST algorithms with 192 probably being a MAY.  The working
assumption here is that 128 is going to be strong enough for the "near"
term, and that 256 is there for the paranoid to use.  I suggest that we
following the S/MIME working group's lead.  128 and 256 are REQUIRED, 192 is
OPTIONAL.

2.  I suggest that we remove RC2 key wrap from the table.  We are not using
RC2 as an algorithm so there is no need to keep the RC2 key wrap.

3.  Section 5.2, para 1:  Please omit the text "Any initialization vector
required is encoded with the cipher text."  Why this is true of the
algorithms we are defining, it is not necessarily true for other peoples
definitions.

4.  General:  I have not looked at the DigSig draft recently, however I
would like to know which name form is going to be used for this algorithm:
The one based on the xmlenc draft (xmlenc#3des) or the "urn" version used in
the examples draft.  I think this item needs discussion.

5.  Section 5.3.1:  I found the discussion of the 3DES key processing to be
very confusing.  After reading the text I found that I needed to change my
current key handling significantly as the "parity" bits are no longer
carried in the key value.  Currently implementations have a 192-bit key
value of which 168-bits are significant key information.  Processing the way
it is currently described is very hard as every 8-th bit is parity and needs
to be inserted in the 56-bit key to make a 64-bit key value.  This text
should be altered by removing the discussion on EDE entirely as this is
covered in the FIPS and ANSI documents.

6. Section 5.3.1:  I firmly believe that changing the chaining mode changes
the algorithm and a new URI should be assigned.  I also would like
information such as the chaining mode to be included in the URI so I prefer
the text "xmlenc#3des-ede-cbc" for the name.

7. Section 5.3.1:  Can somebody summerize for me the basis on which it was
decided to place the IV in the cipher text.  There are three alternatives
here and I would like to know the rational behind the decision.  1) Put the
IV in the EncryptionMethod element, 2) Prefix the IV to the CipherData, 3)
prefix one block of random data to the plain text and use an IV of zero
(tossing that block on decrypt).

8. Section 5.3.1: Should add the sentence "No parameterization exists for
this algorithm." or similar text someplace.

9. Section 5.2.2:  See comment 6 above - recomend inclusion of -cbc in the
name.

10. Section 5.2.2: ditto item 8.

11. Section 5.3.1:  There is nothing in theory that prevents the use of RSA
within an EncryptedData element, that is to encrypt the data directly.  Is
this a mode that we need to /should support?

12.  Section 5.3.1: change text to "at least eight octets long, containing
no zero octets and long enough.."

13.  Section 5.3.1: I suggest adding the following text. "This document
RECOMMENDS that rsa-v1.5 NOT be used for transport of AES keys as there are
some known attacks againist it [RSA-ATTACKS].  This document RECOMMENDS that
rsa-v1.5 be used for transport of 3DES keys for compatilibity with existing
cryptographic systems."  RSA-ATTACKS could either be a future document from
the S/MIME group or a reference to the appropriate section in V2.

14.  Section 5.3.2:  schema should be along the lines of:

<element name="RSA-OAEP" type ="RSA-OAEPType"/>
<complexType name="RSA-OAEPType">
  <sequence>
    <element name="DigestMethodAlgorithm" type="ds:AlgId" minOccurs="0"/>
    <element name="MaskGeneratorAlgorithm" type="ds:AlgId" minOccurs="0"/>
    <element name="PSourceAlgorithm" type="ds:AlgId" minOccurs="0"/>
  </sequence>
</complextType>

Define MaskGeneratorAlgorithm "rsa-oaep-mgf1" to be the MGF1 in RSA#1v2.0
and be the default value if unspecified.

Define PSourceAlgorithm "rsa-oaep-pSpecified" with content base64 value.
default for this algorithm is no P value specified.

Default for DigestMethodAlgorithm would be urn:sha-1.

15.  Section 5.3.2: I suggest adding the following text: "This document
RECOMMENDS that rsa-v2.0 be used for the transport of AES keys.  This
document RECOMMENDS that rsa-v2.0 NOT be used for transport of 3DES keys."

16.  Section 5.4, para 1:  "associatred" should be "associated"

17.  Section 5.4:  I don't like the implied schema for this algorithm.  I
suggest something along the lines of:

<complexType name="dhType">
  <sequence>
    <element name="OriginatorKey" type="ds:KeyValue" minOccurs="0"/>
    <element name="KeyDerivationAlgorithm" type="ds:AlgId" minOccurs="0"/>
    <element name="KeyWrapAlgorithm" type="ds:AlgId"/>
  </sequence>
</complexType>

18.  Add new section 5.4.3:  KeyDerivationAlgorithms.  Discussion is needed
on the list about the following

1) do we use the CMS version (which requires ASN encoding and mapping from
xml algorithm identifiers to OIDs) or do we define our own "non-standard"
method of doing it.

2) What CMS elements do we want to omit and why were they there to begin
with.
The elements used in CMS for key derivation are: a) ZZ (the dh-agreement
value), b) Nonce, c) Algorithm ID, d) resulting key size and e) counter.
The resulting key size was specifcally added to address attacks on RC2
dealing with the fact that it could be both 40-bit and 128-bit.  I don't
remember the specifics on the attack anymore but think it would also apply
to AES with 128 or 256 bit key size.

3)  What is the structure and elements for this.  I suggest the following:

<complexType name="xmlKeyDerivationType>
  <sequence>
    <element name="Nonce" type="ds:base64" minOccurs="0"/>
    <element name="DigestMethod" type="ds:AlgId" minOccurs="0"/>
    <element name="KeySize" type="integer" minOccurs="0"/>
  </sequence>
</complexType>

KM(counter) = Hash(ZZ | <AlgURN> | counter | Nonce | KeySize)

4) What is the default hash algorithm.  I recommend that we use SHA-1 for
3DES iff we use the CMS encoding of the data.  Otherwise SHA-256 allows for
a much better key as all bits are generated independently (rather than using
the counter to "re-generate" some dependent bits).

19. Section 5.4.1:  I suggest that the name X be altered to "Public".  I
have seen a number of different letters used for this value (note that the
CMS DH document uses ya and yb) and Public says what goes there and does not
lead into possible errors of x vs X.

20.  Section 5.5:  please change text from "secret" to "shared" in the first
sentence.

21.  Section 5.5.2:  The example has a typo "#ke-3des" should be "#kw-3des".

22.  Section 5.5.3:  This section should be omitted as we are not doing an
RC2 anyplace else.  If somebody defines RC2 as a block algorithm they can
defined the key wrap for it.

23.  Section 5.6.1:  Should we define a new id for SHA1 or use the one from
the signature draft.

jim

Received on Tuesday, 5 June 2001 05:21:48 UTC