Signature/Encryption Interdependency

• Problem Statement (David Solo)
  • Which <EncryptedData> needs to be decrypted before signature verification?

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 
               :
  <ds:Reference URI="#order" /> 
</ds:Signature>
               :

<Order Id="order">
           :
  <xenc:EncryptedData> ... </xenc:EncryptedData> (encrypted BEFORE signing)
  <xenc:EncryptedData> ... </xenc:EncryptedData> (encrypted AFTER signing)
  <xenc:EncryptedData> ... </xenc:EncryptedData>
           :
</Order>

Proposed Solutions - 1

• Application always knows the order
  • Works for closed systems only
• Try every combination of decryption until some veryfication succeeds or all verifications fail
  • Too expensive computationally

Proposed Solutions - 2

• Decrypt Transform (Ed Simon)
• • The signer must know which part(s) will be encrypted BEFORE signing

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 
               :
  <ds:Transform Algorithm="http://www.w3.org/2000/10/xmlenc#decrypt">    <xenc:Reference URI="#encData2"/>
     <xenc:Reference URI="#encData3"/>
  </ds:Transform>
</ds:Signature>
               :

<Order Id="order">
           :
  <xenc:EncryptedData id="encData1"> ... </xenc:EncryptedData>
  <xenc:EncryptedData id="encData2"> ... </xenc:EncryptedData>
  <xenc:EncryptedData id="encData3"> ... </xenc:EncryptedData>
           :
</Order>

Proposed Solutions - 3

• NoDecrypt Transform (Jim Schaad)
  • The signature verifier must be encryption-aware ("default decrypt")
  • Unclear when to decrypt in the transform sequence

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 
               :
  <ds:Transform Algorithm="http://www.w3.org/2000/10/xmlenc#noDecrypt">    <xenc:EncryptedReference URI="#encData1"/>
  </ds:Transform>
</ds:Signature>
               :

<Order Id="order">
           :
  <xenc:EncryptedData id="encData1"> ... </xenc:EncryptedData>
  <xenc:EncryptedData id="encData2"> ... </xenc:EncryptedData>
  <xenc:EncryptedData id="encData3"> ... </xenc:EncryptedData>
           :
</Order>

Our Proposal

• Decrypt-But Transform
• • The verifier semantics stays unchanged
  • Explicitly specify decrypt in the transform sequence (e.g., before XPath)
  • Closed application does not need to use this

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 
               :
  <ds:Transform Algorithm="http://www.w3.org/2000/10/xmlenc#decrypt">    <xenc:EncryptedReference URI="#encData1"/>
  </ds:Transform>
</ds:Signature>
               :

<Order Id="order">
           :
  <xenc:EncryptedData id="encData1"> ... </xenc:EncryptedData>
  <xenc:EncryptedData id="encData2"> ... </xenc:EncryptedData>
  <xenc:EncryptedData id="encData3"> ... </xenc:EncryptedData>
           :
</Order>

Discussions

• Node-set as both input and output
• • Serialized into an octet stream in order to apply XML Encryption ... This needs to be InfoSet-preserving!
  • If the octet stream is not well-formed (e.g., list of elements), wrap it with <Dummy>...</Dummy>
  • • XML Community needs a clear concept of "Parsing a Node-Set in a Context"
• One decryption at a time
• • NonDecrypt URIs are evaluated each time decryption is done, because decryption result may contain nested EncryptedData
• Applications should be aware that plaintext guessing attacks may be possible if
• • Digest value is not protected properly, AND
  • Entropy of digested data is small

Parse a Node-Set In Context

• Parse as if it is an external entity
  • e.g., wrap it with <Dummy> ... </Dummy>
• "Context" includes
  • Namespace delcarations in ancestor
  • Character encoding
  • DTD information
  • • External entity
    • Default attributes
    • ID attributes
    • Attribute types (e.g., NMTOKEN is normalized)
    • Data types and constraints if schema is in use