W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2000

Re: Combining signing and encrypting

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Tue, 28 Nov 2000 15:21:31 -0500
Message-Id: <4.3.2.7.2.20001128150341.01f615e0@rpcp.mit.edu>
To: david.solo@citicorp.com, MARUYAMA@jp.ibm.com, hal@finney.org
Cc: xml-encryption@w3.org
A nice solution would be if you could nest these things and just
unwrap them:

<Signature>
   <Encrypted>
      <Signature/>
   <Encrypted/>
</Signature>

However, since we permit detached Signatures and Encryption we 
might need some sort of attribute that describes which processing
 level you are in.  (layer="0" type decorations happen which is ugly...) 

So Hiroshi recommended (1) process signatures first and always decrypt
all elements unless a SignatureProperty says not to. Hiroshi mentioned
this really isn't a transform and could perhaps be represented as a
SignatureProperty, but I think it is a transform of sorts. There's an
implicit transform added to the Transforms semantic to always try to
decrypt first unless one is told not to. I have concerns about this
because it alters the semantics of Transform (implicit meaning,
countered in a SignatureProperty) which means a change to the Signature
spec, chasing these fragments/links, and the data model can get pretty 
complex. 

Hal suggested that Signatures over data to be encrypted also be
encrypted (I presume this is the case for document for which only parts
of which are encrypted). Any time a Signature is visible in an instance,
it can be validated without concern for encryption. I think I like this.
(Does this mean the Signature is part of that EncryptedData under the
same key, or there are two EncryptedDatas under the same key (or even
different keys?)). My concern is that it seems to disallow arbitrarily
complex assertions, but then again, that's probably a positive for many
reasons.... 

As an aside, I was thinking along the line of an inverse of Hiroshi:
always process Signature first and decrypt only where instructed to.
Unfortunately, subsequent encryption will invalidate the Signature. If
the author wishes to ensure that this does not happen, he needs to
provide a decrypt transform. If someone other than the author wants to
encrypt, he violates the Signature and things get confusing from what
I can see. Regardless here examples under the policy that (1) do 
Signatures first and any of the decryptions they specify and 
then (2) decrypt all others.

<!-- XML Instance -->

<eg:root ns:eg="http://example.org/instance">
   <eg:a>...</eg:a>
   <eg:b>...</eg:b>
   <eg:c>...</eg:c>
   <eg:e>...</eg:d>
</eg:root>


<!-- author: encrypt b then sign root and encrypted element
             via enveloped signature -->
<!-- consumer: validate signature then decrypt -->

<eg:root ns:eg="http://example.org/instance"
         ns:xmlenc="http://www.w3.org/2000/11/xmlenc#"
         ns:xmldsig="h&dsig;>
   <eg:a>...</eg:a>
   <xmlenc:EncryptedData>
      ab323432c....
   </xmlenc:EncryptedData>
   <xmlenc:EncryptionInfo Id="b">...</xmlenc:EncryptionInfo>
   <eg:c>...</eg:c>
   <eg:e>...</eg:d>
   <dsig:Signature >
      <dsig:SignedInfo>
         <dsig:Reference URI="">
         <dsig:Transforms>
            <dsig:Transform Algorithm="&dsig;enveloped-signature"/>
         </dsig:Transforms>...
      </dsig:SignedInfo>...
   </dsig:Signature>
</eg:root>


<!-- author: sign root then encrypt b -->
<!-- consumer: validate signature which automagically decrypts b
               in order to restore the root as signed -->

<eg:root ns:eg="http://example.org/instance"
         ns:xmlenc="http://www.w3.org/2000/11/xmlenc#"
         ns:xmldsig="h&dsig;>
   <eg:a>...</eg:a>
   <EncryptedData ns:xmlenc="http://www.w3.org/2000/11/xmlenc#">
      ab323432c....
   </EncryptedData>
   <xmlenc:EncryptionInfo Id="b">...</xmlenc:EncryptionInfo>
   <eg:c>...</eg:c>
   <eg:e>...</eg:d>
   <dsig:Signature ns:xmldsig="h&dsig;">
      <dsig:SignedInfo>
         <dsig:Reference URI="">
         <dsig:Transforms>
            <dsig:Transform Algorithm="&xmlenc;decrypt">
               <xmlenc:Decrypt data="#b"/>
            </dsig:Transform>
            <dsig:Transform Algorithm="&dsig;enveloped-signature"/>
         </dsig:Transforms>...
      </dsig:SignedInfo>...
   </dsig:Signature>
</eg:root>

<!-- author: encrypt b, sign root, encrypt e -->
<!-- consumer: validate signature which automagically decrypts e, decrypt b -->
<!-- this means any subseqent encryptions need to be part of the
     signature, kind of stinks -->

<eg:root ns:eg="http://example.org/instance"
         ns:xmlenc="http://www.w3.org/2000/11/xmlenc#"
         ns:xmldsig="h&dsig;>
   <eg:a>...</eg:a>
   <EncryptedData ns:xmlenc="http://www.w3.org/2000/11/xmlenc#">
      ab323432c....
   </EncryptedData>
   <xmlenc:EncryptionInfo Id="b">...</xmlenc:EncryptionInfo>
   <eg:c>...</eg:c>
   <EncryptedData ns:xmlenc="http://www.w3.org/2000/11/xmlenc#">
      ab323432c....
   </EncryptedData>
   <xmlenc:EncryptionInfo Id="e">...</xmlenc:EncryptionInfo>
   <dsig:Signature ns:xmldsig="h&dsig;>
      <dsig:SignedInfo>
         <dsig:Reference URI="">
         <dsig:Transforms>
            <dsig:Transform Algorithm="&xmlenc;decrypt">
               <xmlenc:Decrypt data="#e"/>
            </dsig:Transform>
            <dsig:Transform Algorithm="&dsig;enveloped-signature"/>
         </dsig:Transforms>...
      </dsig:SignedInfo>...
   </dsig:Signature>
</eg:root>


<!-- author: encrypt b, sign root, encrypt e, sign root -->
<!-- consumer: validate signature which automagically decrypts b,
               validate signature which automagically decrypts e -->
<!-- Again, this demonstrates a counterintuitive fact that it's
     the subsequent encryptions that have to be represented in
     the signature -->

<eg:root ns:eg="http://example.org/instance"
         ns:xmlenc="http://www.w3.org/2000/11/xmlenc#"
         ns:xmldsig="h&dsig;>
   <eg:a>...</eg:a>
   <EncryptedData ns:xmlenc="http://www.w3.org/2000/11/xmlenc#">
      ab323432c....
   </EncryptedData>
   <xmlenc:EncryptionInfo Id="b">...</xmlenc:EncryptionInfo>
   <eg:c>...</eg:c>
   <EncryptedData ns:xmlenc="http://www.w3.org/2000/11/xmlenc#">
      ab323432c....
   </EncryptedData>
   <xmlenc:EncryptionInfo Id="e">...</xmlenc:EncryptionInfo>
   <dsig:Signature ID="first" ns:xmldsig="h&dsig;>
      <dsig:SignedInfo>
         <dsig:Reference URI="">
         <dsig:Transforms>
            <dsig:Transform Algorithm="&xmlenc;decrypt">
               <xmlenc:Decrypt data="#e"/>
            </dsig:Transform>
            <dsig:Transform Algorithm="&dsig;enveloped-signature"/>
         </dsig:Transforms>...
      </dsig:SignedInfo>...
   </dsig:Signature>
   <dsig:Signature ID="second" ns:xmldsig="h&dsig;>
      <dsig:SignedInfo>
         <dsig:Reference URI="">
         <dsig:Transforms>
            <dsig:Transform Algorithm="&xmlenc;decrypt">
               <xmlenc:Decrypt data="#e"/>
            </dsig:Transform>
            <dsig:Transform Algorithm="&xmlenc;decrypt">
               <xmlenc:Decrypt data="#b"/>
            </dsig:Transform>
            <dsig:Transform Algorithm="&dsig;enveloped-signature"/>
         </dsig:Transforms>...
      </dsig:SignedInfo>...
   </dsig:Signature>
</eg:root>

__ 
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Tuesday, 28 November 2000 15:23:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:18 GMT