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"

>       <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.

>     </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?

> 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?

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.


>       <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 Thursday, 15 March 2001 19:13:15 UTC