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 Monday, 12 March 2001 10:25:21 UTC