RE: 2nd try at Algorithms Section

Donald,

Its always nice to be appreciated.

> -----Original Message-----
> From: xml-encryption-request@w3.org
> [mailto:xml-encryption-request@w3.org]On Behalf Of Donald E. Eastlake
> 3rd
> Sent: Wednesday, June 06, 2001 10:23 AM
> To: jimsch@exmsft.com
> Cc: xml-encryption@w3.org; lde008@dma.isgmot.com
> Subject: Re: 2nd try at Algorithms Section
>
>
>
> [I know there are later comments in this thread but I'm going to
> finish off this response before diving into them...]
>
> Hi Jim,
>
> It's great to get such extensive and detailed commentary!
>
> From:  "Jim Schaad" <jimsch5@home.com>
> Reply-To:  <jimsch@exmsft.com>
> To:  <xml-encryption@w3.org>, <Donald.Eastlake@motorola.com>
> Date:  Tue, 5 Jun 2001 02:21:19 -0700
> Message-ID:  <001701c0eda0$e1da3c20$0d00a8c0@soaringhawk.net>
>
> >Donald,
> >
> >Here are my comments on your draft.
> >
> >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.
>
> I believe that, consistent with the XMLDSIG draft, we should use all
> URLs that can point to documnetation.

Having looked at the digsig draft for the first time in a long while, I see
that these are consistant names and agree they are fine.  Joseph needs to
update the examples to use this name form.

>
> >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.
>
> I think you mean 5.2.1.
>
> There are reasons for tossing the silly parity bits. Their presence
> leads to additional complexity in generating them and sometimes in the
> harmful checking of them. (Note the famous case of the secure telnet
> implementation which generated DES keys with all zero parity bits but
> then called crypto routines which ignored the key if the parity was
> wrong and just encrypted with a zero DES key. This meant that 255 out
> of 256 times, you wre encrypting with a constant known key. Of course
> the data looked random and this implementation interoperated fine with
> itself,which was how it was normally used. It was in use for years
> before anyone noticed.) However, if it is really that inconvenient for
> many people to eliminate the parity bits due to the crypto library
> they are using or whatever, I'll change it.
>
> I see no harm in the one sentence which tell you what's going on with
> EDE. This document has some limited details on algorithms so someone
> generally familiar with modern crytography can tell what's going on,
> rather than a terse "algorihm X as defined in document Y".

Implementers please comment on this.  I know that it would lead to potential
problems when used with the Microsoft CryptoAPI as the existing code used
with CMS does not operate in this manner.

>
> >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.
>
> This is a spectrum. After all, why stop with 3des-ede-cbc? What about
> the padding? What about the type of CBC? As I recall, there are really
> four different ways to do CBC.  I really can't see any reason anyone
> would bother with other that EDE so I'm not willing to stick that in
> unless there is a clear consensus to do so.  I suppose we could add
> "-cbc" but I'm inclined to have it be the default and add a suffix
> if/when a different chaining mode algorithm is ever defined.

Honestly, I have no problems with specifing the padding mode as well.  I can
agree with omitting the -ede but would prefer to see the ECB as the omitted
chaining mode if there was one.  I can live with omitting the -cbc but do
not care for it.

>
> >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).
>
> I don't remember exactly but apparently it was felt to more tightly
> link the IV and the cipher text to avoid confusion or any temptation
> to use the same IV element for more than one ciphertext or
> something. It's also less verbose.  I really don't care on this point
> and would not mind an <IV/> parameter but was just following what the
> group wanted. But I don't like your option 3.
>
> >8. Section 5.3.1: Should add the sentence "No
> parameterization exists for
> >this algorithm." or similar text someplace.
>
> ? First sentence in the section says "...takes no explicit
> parameters."

Sorry -- I should have been more explict in saying what I wanted.  One of
the reasons for having people actually read specs.  I would like text to the
effect that no XML parameters are "allowed" with this algorithm identifier.

>
> >9. Section 5.2.2:  See comment 6 above - recomend inclusion
> of -cbc in the
> >name.
>
> See response above  :-)
>
> >10. Section 5.2.2: ditto item 8.
>
> Will do but if no explicit parameters are defined for an algorithm I
> don't see why anyone would be confused...
>
> >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?
>
> Generally adding RSA as a sort of block encryption algorithm for
> messages that might be large relative to the modulus would require
> defining the padding and formatting...
>
> Just allowing rsa-1_5 and rsa-oaep for encrypting data which is small
> enough to fit in place of the "key" as those algorithms are defined
> would be easy to add as an option but I question how useful it would
> be.
>
> >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.
>
> Hummm, a NOT RECOMMENDED here seems a bit strong... How about
> if we just
> say that RSA-OAEP is preferred for AES keys?

I am fine with SUGGEST rather than RECOMMEND.

>
> >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>
>
> You are quite right that the digest function parameter
> element shouldn't
> be the somewhat weird OAEP I had defined. I was already going
> to change
> it to <DigestMethod/> for commonality. I'm not sure if it's worth
> having a default here.

No problems with this.

>
> >Define MaskGeneratorAlgorithm "rsa-oaep-mgf1" to be the MGF1
> in RSA#1v2.0
> >and be the default value if unspecified.
>
> I wanted to avoid a whole new category of algorithms. I don't see any
> evidence of a new mask generator with noticeable
> deployment. Permitting this adds to the complexity of implementaion...
> (If it was added to the syntax, it should be MaskGeneratorMethod.)

My label is incorrect.  I would like to see it added so that the algorithm
does not need to be redone later if a new MG comes into effect.  I do
however think it should be defaulted to MG1 normally.

>
> >Define PSourceAlgorithm "rsa-oaep-pSpecified" with content
> base64 value.
> >default for this algorithm is no P value specified.
>
> With DigestMethod being a paremeter element that could take content
> for some hypothetical parameterized digest function, we do need a
> separate element here.  What's wrong with just <P/>?

I was just moving the ASN concepts over directly from the PKCS#1 document.
My assumption is that they felt methods of getting P other than directly
specified were at least possible if not probable.  This would be the only
reason for going with a Method/algorithm rather than directly with P.
Working group call.

>
> >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."
>
> First part fine. But if someone is useing 3DES, what's wrong with
> transporting a 3DES key with rsa-oaep?

There is nothing wrong with it.  However, if we think OAEP should be use for
3DES then I believe that v1.5 should be eleminated altogether.

>
> >16.  Section 5.4, para 1:  "associatred" should be "associated"
>
> Sorry, maybe I'll actually spell check the next version...
>
> >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>
>
> Why call it OriginatorKey instead of simply KeyInfo for commonality?

Clarity -- I have no problems with KeyInfo.  Type should have been KeyInfo.

>
> I'm not sure why this is a type. Algorithms are not elment nemaes but
> attribute values. But maybe I'm confused.
>
> I assume by derivation algorithm you mean how to get the key from the
> shared secret produced by the agreemnt algorithm?  As with the MGF, I
> don't see sufficient motivation to add a new category of algorithms.

Assuming you don't think the derivation algorithm will ever be shown as
bad -- then you don't need this.

>
> Why does it need a KeyWrap Algorthm?

You still need to know how to encrypt the data with the derived key.  This
is the key wrap algorithm.  I.e. you need someplace to specify you are using
#kw-aes or #kw-3des.

>
> >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.
>
> Obviously I think we should do our own derivation.  Otherwise we would
> be requiring real ASN encoding. (XMLDSIG has some vestigial ASN but it
> can all be handled with big hex constants.)
>
> >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.
>
> Currently the key size is included in the algorithm URI but I guess
> there can be algorithms for which the key size is a parameter or
> something so adding a key size integer to the concatenated elements
> seems reasonable.
>
> >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).
>
> I don't see the coupling to CMS encoding.  As far as I'm concerned, we
> should be avoiding ASN.1 and using string/XML encoding where we can.
> Perhaps there should be no default and specification of a DigestMethod
> be required.

The reason that I put the coupling in is merely to say.  If we use the CMS
encoding, lets use the CMS hash function (i.e. re-use code).  If we don't
use the CMS encoding, SHA-256 provides better security and should be used.

>
> >20.  Section 5.5:  please change text from "secret" to
> "shared" in the first
> >sentence.
>
> How about if I say "shared secret"...

This is fine.

> >23.  Section 5.6.1:  Should we define a new id for SHA1 or
> use the one from
> >the signature draft.
>
> Multiple ids for the same thing = bad.

Yeah.

>
> >jim
>
> Thanks,
> Donald
>

jim

Received on Wednesday, 6 June 2001 14:32:23 UTC