Re: Proposed work item: DerivedKey

Magnus

Thank you for your suggestion regarding DerivedKey work  for  
chartering future XML Security work.

The XML Security Specifications Maintenance WG discussed your  
proposal [1] and reached the conclusion that this work is already  
possible under the draft charter that we have been developing [2],  
since this charter includes review of use cases and requirements for  
XML Signature and developing corresponding updates. We only discussed  
the chartering issues in the WG, not the technical issue itself.

Thanks

regards, Frederick and Thomas

Frederick Hirsch, Nokia, Chair XML Security Specifications  
Maintenance WG
Thomas Roessler, W3C

[1] http://www.w3.org/2007/12/18-xmlsec-minutes-public.html#item04

[2] http://www.w3.org/2007/xmlsec/wiki/charter



On Dec 4, 2007, at 9:12 AM, ext Magnus Nyström wrote:

>
> All,
>
> If there will be work done to revise the existing XML Digital  
> Signature specification and the XML Encryption specification, I'd  
> like to propose one additional work item: Introduction of a new  
> <ds:KeyInfo> alternative called DerivedKey.
>
> The use case for this is when you are authenticating or encrypting  
> information based on a key derived from some other information and  
> want to convey this information to the recipient of your message.  
> One example is when doing passphrase-based cryptography. RSA  
> Laboratories published an XML version of PKCS #5 earlier this year,  
> and while the schema introduced in that amendment to PKCS #5 is  
> sufficient to cover the basic case of an item encrypted with a  
> passphrase-derived key, it does not in itself suffice when there  
> are multiple items encrypted (or authenticated) with that key,  
> since there is no straightforward way to refer to derived keys.
> WS-I BSP also recommends forward cross-referencing when multiple  
> items have been encrypted with a key, and exemplify with the  
> EncryptedKey type and its <xenc:ReferenceList> element, so this is  
> another reason for doing this.
>
> In essence, this is about creating an equivalent to  
> <xenc:EncryptedKey> but for derived key. A possible schema approach  
> - clearly for discussion if this is considered interesting enough  
> to qualify as a work item - is shown below, building on the  
> existing EncryptedKeyType type. I have also included a simple example.
>
> -- Magnus
> --
> <element name="DerivedKey" type="xmlsec:DerivedKeyType"/>
> <complexType name="DerivedKeyType">
>    <sequence>
>      <element name="KeyDerivationMethod"  
> type="xmlsec:KeyDerivationMethodType" minOccurs="0"/>
>      <element ref="xenc:ReferenceList" minOccurs="0"/>
>      <element name="CarriedKeyName" type="string" minOccurs="0"/>
>    </sequence>
>    <attribute name="Id" type="ID" use="optional"/>
>    <attribute name="Type" type="anyURI" use="optional"/>
> </complexType>
>
> <complexType name="KeyDerivationMethodType">
>    <sequence>
>      <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
>    </sequence>
>    <attribute name="Algorithm" type="anyURI" use="required"/>
> </complexType>
>
> <!-- In addition, an identifier is required for cross-referencing, -->
> <!-- similar to http://www.w3.org/2001/04/xmlenc#EncryptedKey",  
> e.g.: -->
> <!-- http://xxxxxx/#DerivedKey -->
> --
>
> <xmlsec:DerivedKey
>    xmlns:xmlsec="http://xxxxxx#"
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
>
> xmlns:pkcs-5="http://www.rsasecurity.com/rsalabs/pkcs/schemas/ 
> pkcs-5v2-0#"
>    Id="Passphrase1">
>    <xmlsec:KeyDerivationMethod Algorithm="http:// 
> www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
>      <pkcs-5:PBKDF2-params>
>        <Salt>
>          <Specified>Df3dRAhjGh8=</Specified>
>        </Salt>
>        <IterationCount>2000</IterationCount>
>        <KeyLength>16</KeyLength>
>        <PRF/>
>      </pkcs-5:PBKDF2-params>
>    </xmlsec:KeyDerivationMethod>
>    <xenc:ReferenceList>
>      <xenc:DataReference URI="#ED"/>
>    </xenc:ReferenceList>
> </xmlsec:DerivedKey>
> --
>
>

Received on Tuesday, 8 January 2008 16:18:27 UTC