Introduction

XML Encryption will need to make use of ds:KeyInfo. Simple adoption can be possible except that there is one more key type available in the encryption context: KeyRetrievalMethod. This is just like a ds:RetrievalMethod, but it always retrieves a EncryptedKey. We then must ask ourselves how we extend the dsig schema.

But first, let's consider our options with *RetrievalMethod. We could be permissive, and just use ds:RetrievalMethod and state in natural language that the Type should always be http://www.w3.org/Encryption/2001/03#EncryptedKey. We could schema-redefine ds:RetrievalMethod such that the type is always fixed, or we can create a new element name derived from ds:RetrievalMethod but with the type set to a fixed value. While this is an open issue for consideration, let's assume the latter:

  <element name='KeyRetrievalMethod' type="xenc:KeyRetrievalMethodType" />
  <complexType name='KeyRetrievalMethodType'>
    <complexContent>
      <restriction base='ds:RetrievalMethodType'>
        <sequence>
          <element name="Transforms" type="ds:TransformsType" minOccurs="0"/> 
        </sequence>  
        <attribute name="URI" type="uriReference"/>
        <attribute name="Type" type="uriReference"
         use="fixed" value="http://www.w3.org/Encryption/2001/03/xmlenc#EncryptedKey"/>
      </restriction>
    </complexContent>
  </complexType>

and consider the question of if we have something like the above, how do we relate to the dsig schema?

Option1: Reuse ds:KeyInfo Element

The following schema fragment shows that a xenc instance will actually have a ds:KeyInfo

  <complexType name='EncryptedType' abstract='true'>
    <sequence>
      <element name='EncryptionMethod' type='ds:DigestMethodType' minOccurs='0'/>
      <element ref='ds:KeyInfo' minOccurs='0'/>
      <element ref='xenc:CipherData'/>
    </sequence>
    <attribute name='Id' type='ID' use='optional'/>
  </complexType>

as shown in the following instance:

<?xml version="1.0" encoding="UTF-8"?>
<EncryptedData xmlns="http://www.w3.org/Encryption/2001/03/xmlenc#"
               xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
               xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
               xsi:schemaLocation="http://www.w3.org/Encryption/2001/03/xmlenc#
                                   01-19-xmlenc-schema.xsd">
    <EncryptionMethod Algorithm="foo"/>
    <ds:KeyInfo>
        <enc:KeyRetrievalMethod URI="http://someKey"
        Type="http://www.w3.org/Encryption/2001/03/xmlenc#EncryptedKey"/>
    </ds:KeyInfo>
    <CipherData>1234</CipherData>
</EncryptedData>

This has the following features:

• The instance requires alternating prefixes. (Some would argue distracting, others would argue informative).
• The relationship between ds:KeyInfo and enc:KeyRetrievalMethod is not well defined in the schema. We're just taking advantage of the big ANY placeholder in ds:KeyInfo, which is a weak relationship.
• See Schema Best Practices: Hide (Localize) Versus Expose Namespaces, Element versus Type, and Variable Content Containers

Option2: Reuse ds:KeyInfo Type

The following schema fragment shows that a xenc instance will have a enc:KeyInfo which is based on ds:KeyInfoType.

  <complexType name='EncryptedType' abstract='true'>
    <sequence>
      <element name='EncryptionMethod' type='ds:DigestMethodType' minOccurs='0'/>
      <element name='KeyInfo' type='ds:KeyInfoType' minOccurs='0'/>
      <element ref='xenc:CipherData'/>
    </sequence>
    <attribute name='Id' type='ID' use='optional'/>
  </complexType>

as shown in the following instance:

<?xml version="1.0" encoding="UTF-8"?>
<EncryptedData xmlns="http://www.w3.org/Encryption/2001/03/xmlenc#"
               xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
               xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
               xsi:schemaLocation="http://www.w3.org/Encryption/2001/03/xmlenc#
                                   01-19-xmlenc-schema.xsd">
    <EncryptionMethod Algorithm="foo"/>
    <KeyInfo>
        <KeyRetrievalMethod URI="http://someKey"
        Type="http://www.w3.org/Encryption/2001/03/xmlenc#EncryptedKey"/>
    </KeyInfo>
    <CipherData>1234</CipherData>
</EncryptedData>

This has the following features:

• No need to alternate prefixes.
• At the instance processing level (enc:)KeyInfo is now a new element, though its relationship is explicit in the schema. Like option1, KeyRetrievalMethod's relationship to its parent element still relies upon the ANY (weak relationship).
• See Schema Best Practices: Hide (Localize) Versus Expose Namespaces, Element versus Type, and Variable Content Containers

Option3: Extend ds:KeyInfo Type

The following schema fragment shows that a xenc instance will actually have a ds:KeyInfo

  <complexType name='EncryptedType' abstract='true'>
    <sequence>
      <element name='EncryptionMethod' type='ds:DigestMethodType' minOccurs='0'/>
      <element ref='xenc:KeyInfo' minOccurs='0'/>
      <element ref='xenc:CipherData'/>
    </sequence>
    <attribute name='Id' type='ID' use='optional'/>
  </complexType>
  ...
    <element name='KeyInfo' type='xenc:KeyInfoType'/>
    <complexType name='KeyInfoType'>
      <complexContent>
        <extension base='ds:KeyInfoType'>
          <sequence>
            <element ref='xenc:KeyRetrievalMethod' minOccurs='0'/>
          </sequence>
        </extension>
      </complexContent>
    </complexType>

as shown:

<?xml version="1.0" encoding="UTF-8"?>
<EncryptedData xmlns="http://www.w3.org/Encryption/2001/03/xmlenc#"
               xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
               xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
               xsi:schemaLocation="http://www.w3.org/Encryption/2001/03/xmlenc#
                                   01-19-xmlenc-schema.xsd">
    <EncryptionMethod Algorithm="foo"/>
    <KeyInfo>
        <KeyRetrievalMethod URI="http://someKey"
        Type="http://www.w3.org/Encryption/2001/03/xmlenc#EncryptedKey"/>
    </KeyInfo>
    <CipherData>1234</CipherData>
</EncryptedData>

This has the following features:

• Similar to option 2
• But the relationship between (enc:)KeyInfo and ds:KeyInfo is now strong defined!
• Unfortunately, the (enc:)KeyRetrievalMethod matches both the ANY production in   ds:KeyInfoType and the KeyRetrievalMethod production in xenc:KeyInfoType. (See enc-example.xml and  01-19-xmlenc-schema.xsd).
  • Attempts to redefine ds:KeyInfoType to prevent this seem overly complex.
  • In this application, this might not be the biggest problem, but (a) either I'm not understanding the best way to do this or (b) the use of ANY in the dsig schema is preventing a whole slew of applications from extending its types in a coherent manner.