RE: DH Key agreement in XMLEnc

Yongge,

I am afraid that you missed several key points to the proposal that I had.
See comments.

> -----Original Message-----
> From: Yongge Wang [mailto:ywang@certicom.com]
> Sent: Thursday, March 15, 2001 4:13 PM
> To: jimsch@exmsft.com
> Cc: xml-encryption@w3.org; 'Simon Blake-Wilson'
> Subject: RE: DH Key agreement in XMLEnc
>
>
>
> Hi, jim,
>
> On Thu, 15 Mar 2001, Jim Schaad wrote:
> > I disagree with the syntax defined below, and if my
> proposed syntax were to
> > be used then the question of dhStatic, dhEphem ... vanishes.
>
> I agree with this point. That is, dhEphemStatic and dhStaticStatic
> be combined in one (note that these two schemes are the only practical
> ones). But this unification can easibly be achieved by changing
> the element name "xenc:DHEphem" to something like
> "xenc:DHInitiator".
>
> > What I believe the correct concept is (and I have no idea
> of the correct way
> > to put this into schema):
> >
> > An algorithm of urn:ansi-x9-42:dh-kdf-sha1 which has the syntax of:
> >
> > <element name="DH">
> >   <complexType>
> >     <sequence>
> >       <element name="Originator Key" type=ds:KeyInfo minOccurs=0/>
>
> That might be: "OriginatorKey"

Since spaces are not allowed in tag names -- yes it would be combined.

>
> >       <element name="Party A Info" type=CryptoBinary minOccurs=0/>
>
> This is not enough. The Recipient has no idea what this CryptoBinary
> is about. The recipient might have several DSA keys.
> As in my proposal, you still need a "ds:KeyInfo" (or directly
> a "ds:DSAKeyValue") element to specify the recipient's key used.

On the contrary it is enough.  The recipient's key is specified in the
KeyInfo structure which is part of the EncryptedKey element (just like it is
for RSA or any other algorithm).  This syntax is for the additional
non-standard parameters for DH and comes as the children of the
EncryptionMethod element.

PartyAInfo is a base64 encoded blob (that's what CryptoBinary means) that
can contain a string of bytes randomly generated by the originator so that
the key agreement does not always end-up with the same key everytime in the
static-static case.  This is a standard field straight out of X9.42

>
> >     </sequence>
> >   </complexType>
> > </element>
> >
> > Note that more elements might need to be added depending on how the
> > algorithm is fully specified.  I think that in some cases
> it might be
> > necessary to include the key size element for algorithms like RC2.
>
> That information might be already included in identifier for RC2
> if it was defined somewhere else?

I am looking at the CMS version of the X9.42 specification.  We explicitly
put in both the algorithm and the key size (and made it fixed for RC2) in
the key derivation function.  Note that for RC2 this is necessary becase the
actual key size and the effective key size may not be the same.  Only the
effective key size needs to be specified in the RC2 algorithm parameters
since the actual key size is the size of the data that comes out of the key
wrap (or key derivation) code.
>
> > The example given below then becomes:
> >
> > <xenc:ENcryptedKey NameKey="Content Key"
> >             xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc'>
> >    <xenc:EncryptionMethod
> xenc:algorithm="urn:ansi-x9-42:dh-kdf-sha1"
> >             xmlns:dh='urn:ansi-x942:dh-kdf-sha1'>
>
> it might be not necessary to have a new namespace for the DH
> key exchange?

It might not be necessary to have a new name space, but it does not hurt to
show what would happen if it did occur.

>
> I partially agree with the policy of putting the DHkey exchange
> information in the "xenc:EncryptedKey" element. But that
> might make some
> additional complexity to the current definition or some
> semantic-syntac conflict.

Creating a new EncryptedKey element for every algorithm is asking for
trouble.  This means that the code needs to recognize, parse and treat as
equivant every different structure defined for every algorithm that comes
along.  I don't want to define a new EncryptedKey structure for EC, for
AES-KeyWrap, for RSAv1.5, for RSAv2.0, for RSAv9.9.  This is what the
EncryptionMethod URI is for, it allows for an ANY structure to be placed as
a child of that element that contains all necessary information for dealing
with the new algorithm that is not part of the standard structure (the
identification of the recipient key).

Not keeping everything uniform is what is going to cause complexity.

>
>
> >       <dh:OriginatorKey>
> >          <ds:KeyValue>...<ds:KeyValue/>
> >       </dh:OriginatorKey>
> >    </xenc:EncryptionMethod>
> >    <ds:KeyInfo xmlns:ds='...'>
> >       <ds:KeyName>John Doe Public Key</ds:KeyName>
> >    </ds:KeyInfo>
> > </xenc:EncryptedKey>
> >
> > Note that with this syntax the difference between
> ephemeral-static and
> > static-static is just what is placed in the OriginatorKey
> structure.  The
>
> Agree with the effort to do this.
>
> Thanks for your input!
> Yongge
>
> > algorithm itself does not need to state this information.
> The algorithm
> > would then define what items are required for support in
> OriginatorKey.
> >
> > jim
> >
> >
> > > -----Original Message-----
> > > From: xml-encryption-request@w3.org
> > > [mailto:xml-encryption-request@w3.org]On Behalf Of Yongge Wang
> > > Sent: Monday, March 12, 2001 7:24 AM
> > > To: xml-encryption@w3.org
> > > Cc: Simon Blake-Wilson
> > > Subject: DH Key agreement in XMLEnc
> > >
> > >
> > > In the following we give an example definition of DH (ECDH)
> > > key agreement
> > > in XML-Encryption. The schema definition is based on [1].
> > > In [2] and [3], several versions of DH (ECDH) key
> agreement protocol
> > > have been defined: dhStatic, dhEphem, dhEphem-Static (dhOneFlow),
> > > and so on. Based on the experience in CMS [4], we only define
> > > dhEphem-Static
> > > for XML-Enc. (note that the content-encryption key length
> > > is uniquely determined by the content-encryption method,
> thus it is
> > > not necessary to explicitely specify the value of keydatalen
> > > as in [2,3])
> > >
> > > Algorithm Identifiers:
> > >   DH key agreement with Key Derivation Function (kdf)
> defined in 7.7.2
> > >   of [2] based on SHA-1:
> > >              urn:ansi-x9-42:dh-emph-static-kdf-sha1
> > >   ECDH key agreement with Key Derivation Function (kdf)
> > > defined in 5.6.3
> > >   of [3] based on SHA-1:
> > >              urn:ansi-x9-63:ecdh-emph-static-kdf-sha1
> > >
> > > The DHKeyAgreement element is used to transport content encryption
> > > keys from the originator to the recipients.
> > >
> > > <element name="DHKeyAgreement">
> > >   <complexType>
> > >     <sequence>
> > >       <element ref="xenc:ReferenceList" minOccurs=0/>
> > >       <element ref="xenc:DHEphem"/>
> > >       <element ref="ds:KeyInfo" minOccurs=0/>
> > >     </sequence>
> > >     <attribute name="Id" type="ID"  use="optional"/>
> > >     <attribute name="NameKey" type="string" use="optional"/>
> > >     <attribute name="Algorithm" type="uriReference"
> use="required"/>
> > >   </complexType>
> > > </element>
> > >
> > > The semantics of the elements are the same as that in the
> > > "xenc:EncryptedKey" key element in [1] except "xenc:DHEphem".
> > >
> > > The DHEphem element is used to transport ephemeral
> > > keys. This element is mandatory.
> > >
> > > <element name="DHEphem">
> > >   <complexType>
> > >     <sequence>
> > >       <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
> > >       <element ref="ds:KeyValue">
> > >     </sequence>
> > >     <attribute name="Id" type="ID" use="optional"/>
> > >   </complexType>
> > > </element>
> > >
> > > We give one example in the following: In this example, the
> > > data is encrypted using a symmetric key known by the
> > > identifier "Content Key".  This key is computed by the recipient
> > > through an emphemeral-static DH-key agreement primitive.
> > > (that is, the originator's ephemeral key and recipient's
> static key).
> > > The recipient's static key is a public key known as "John Doe
> > > Public Key".
> > >
> > > <xenc:DHKeyAgreement NameKey="Content Key"
> > >            Algorithm=" urn:ansi-x9-42:dh-emph-static-kdf-sha1"
> > >            xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc'>
> > >    <xenc:DHEphem>
> > >      <ds:KeyValue namespace="...">
> > >        <ds:DSAKeyValue>
> > >           <P>...</P>
> > >           <Q>...</Q>
> > >           <G>...</G>
> > >           <Y>...</Y>
> > >         </ds:DSAKeyValue>
> > >      </ds:KeyValue>
> > >    </xenc:DHEphem>
> > >    <ds:KeyInfo xmlns:ds='...'>
> > >      <ds:KeyName>John Doe Public Key</ds:KeyName>
> > >    </ds:KeyInfo>
> > > </xenc:DHKeyAgreement>
> > >
> > > <xenc:EncryptedData
> > > xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc'>
> > >   <xenc:EncrpytionMethod
> xenc:Algorithm="urn:nist-gov:aes-128-cbc">
> > >     <s0:IV xmlns:s0='http://somens'>ABCD</s0:IV>
> > >   </xenc:EncryptionMethod>
> > >   <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
> > >     <ds:KeyName>Content Key</ds:KeyName>
> > >   </ds:KeyInfo>
> > >   <xenc:CipherText>DEADBEEF</xenc:CipherText>
> > > </xenc:EncryptedData>
> > >
> > > For DH key agreement, the <ds:P>, <ds:Q>, and <ds:G>
> elements' values
> > > are the same for the ephemeral key and the static key.
> For ECDH key
> > > agreement, the <ecds:ECCParameters> (see [5]) element's
> > > values are the same
> > > for the ephemeral key and the static key. Thus for the reason
> > > of simplicity
> > > and bandwith, the "xenc:DHEphem" element could be defined to
> > > be equivalent to <ds:Y> or <ecds:ECCPublicKey> element:
> > >
> > > <element name="DHKeyAgreement">
> > >   <complexType>
> > >     <sequence>
> > >       <element ref="xenc:ReferenceList" minOccurs=0/>
> > >       <element name="xenc:DHEphem"  type="ds:CryptoBinary"/>
> > >       <element ref="ds:KeyInfo" minOccurs=0/>
> > >     </sequence>
> > >     <attribute name="Id" type="ID"  use="optional"/>
> > >     <attribute name="NameKey" type="string" use="optional"/>
> > >     <attribute name="Algorithm" type="uriReference"
> use="required"/>
> > >   </complexType>
> > > </element>
> > >
> > >
> > >
> > > [1] XML Encryption Syntax and Processing. Dillaway, Fox, Imamura,
> > >     LaMacchia, Maruyama, Schaad, Simon. December 2000.
> > > [2] ANSI X9.42
> > > [3] ANSI X9.63
> > > [4] RFC 2630 (CMS)
> > > [5] ECDSA with XML-Signature Syntax. Blake-Wilson and Wang.
> > > IETF Draft.
> > >
> > > Security Considerations:
> > >
> > > The issue of making DH (ECDH) key agreement secure (e.g.,
> to be secure
> > > against small subgroup attacks) is an application level problem
> > > which is not addressed here.
> > >
> > >
> > >
> >
> >
>
>

Received on Friday, 16 March 2001 03:12:37 UTC