Re: Signing and Encryption

>We don't, because of the above rule [1], any information that is signed if
>any portion of it is later encrypted the entire signed data (including
>signature) needs to be encrypted, otherwise you are altering the data,
which
>should and will invalidate the signature.

I agree that signature needs to be encrypted, but I'm not sure why entire
signed data also needs to be encrypted.  Encrypting any portion of signed
data will make signature invalid, but to recover the signature, we
introduce EncryptedReference element.  The element can be used as follows
(I wrote before that the element may appear within ds:SignaturePropery
element, but I changed my mind ...).

Suppose you sign the following document, which contains an already
encrypted element:

  <order Id="order">
    <item>
      <title>XML and Java</title>
      <price>100.0</price>
      <quantity>1</quantity>
    </item>
    <cardinfo>
      <name>Your Name</name>
      <expiration>04/2002</expiration>
      <number>5283 8304 6232 0010</number>
    </cardinfo>
    <EncryptedData xmlns="http://www.w3.org/2000/11/temp-xmlenc" Id="enc1">...</EncryptedData>
  </order>

The resulting document would be as follows:

  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      ...
      <Reference URI="#order">
        <Transforms>
          <Transform Algorithm="
http://www.w3.org/2000/11/temp-xmlenc#decrypt">
            <EncryptedReference xmlns="
http://www.w3.org/2000/11/temp-xmlenc" URI="#enc1"/>  <!--
EncryptedReference element is used here -->
          </Transform>
          <Transform Algorithm="
http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
        </Transforms>
        ...
      </Reference>
    </SignedInfo>
    <SignatureValue>...</SignatureValue>
    <Object>
      <order Id="order">
        <item>
          <title>XML and Java</title>
          <price>100.0</price>
          <quantity>1</quantity>
        </item>
        <cardinfo>
          <name>Your Name</name>
          <expiration>04/2002</expiration>
          <number>5283 8304 6232 0010</number>
        </cardinfo>
        <EncryptedData xmlns="http://www.w3.org/2000/11/temp-xmlenc" Id="enc1">...</EncryptedData>
      </order>
   </Object>
  </Signature>

Also suppose you encrypt cardinfo element next.  The resulting document
would be as follows:

  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      ...
      <Reference URI="#order">
        <Transforms>
          <Transform Algorithm="
http://www.w3.org/2000/11/temp-xmlenc#decrypt">
            <EncryptedReference xmlns="
http://www.w3.org/2000/11/temp-xmlenc" URI="#enc1"/>
          </Transform>
          <Transform Algorithm="
http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
        </Transforms>
        ...
      </Reference>
    </SignedInfo>
    <SignatureValue>
      <EncryptedData xmlns="http://www.w3.org/2000/11/temp-xmlenc" Id="enc3">...</EncryptedData>  <!-- signature value is also encrypted -->
    </SignatureValue>
    <Object>
      <order Id="order">
        <item>
          <title>XML and Java</title>
          <price>100.0</price>
          <quantity>1</quantity>
        </item>
        <EncryptedData xmlns="http://www.w3.org/2000/11/temp-xmlenc" Id="enc2">...</EncryptedData>
        <EncryptedData xmlns="http://www.w3.org/2000/11/temp-xmlenc" Id="enc1">...</EncryptedData>
      </order>
    </Object>
  </Signature>

A recipient of this document (e.g., bookstore) needs to decrypt the
EncryptedData element created after signing for validating the signature.
The first Transform is inserted for such purpose; the Transform decrypts
all EncryptedData elements in an input except the ones specified by
EncryptedReference elements.  Inserting this Transform enables to validate
signature even if encryption was done after signing, and hence if there is
a possibility that encryption is done after signing, a signer should insert
this Transform just before the Transform for canonicalization.

[1] http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0082.html

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
E-mail: imamu@jp.ibm.com



From: "Joseph Ashwood" <jashwood@arcot.com> on 2001/01/26 09:16 AM

Please respond to "Joseph Ashwood" <jashwood@arcot.com>

To:   <xml-encryption@w3.org>
cc:   Takeshi Imamura/Japan/IBM@IBMJP
Subject:  Re: Signing and Encryption




----- Original Message -----
From: "Takeshi Imamura" <IMAMU@jp.ibm.com>
To: "Joseph Ashwood" <jashwood@arcot.com>
Cc: <xml-encryption@w3.org>

> >If this signature does not verify
> >with the ciphertext still encrypted it should be considered tampered
with
> >(although at a later date it may be untampered through the removal of
the
> >encryption).
>
> According to [1], encryption after signing requires signature value to be
> encrypted.  If doing so, we don't have to try to verify signature.  This
is
> because we can see whether signature contains encrypted data by examining
> whether signature value is encrypted.
>
> Anyway, this solution raises another problem.  If signature contains
> multiple encrypted data, how do we distinguish encrypted data before
> signing and ones after signing?

We don't, because of the above rule [1], any information that is signed if
any portion of it is later encrypted the entire signed data (including
signature) needs to be encrypted, otherwise you are altering the data,
which
should and will invalidate the signature.

> >3.7 The EncryptedReference element
> >
> >The EncryptedReference element provides a way to indicate
> >that data, over which an XML Digital Signature (xmlns:ds) has
> >been computed, was encrypted.  In essence, it indicates the data
> >should not be decrypted prior to signature verification.
> >This element may only appear within a ds:Reference element
> >within a ds:Signature element. ...

If we maintain a strict definition of encryption with regard to signing, in
such a way that encryption of a portion of the signed data without
encrypting the entire signed contents and signature invalidates the
signature, then this rule becomes unnecessary, from the simple fact that
any
encryption added to the signed data that does not include the signature
itself tampers with the signature data, and therefore invalidates the
signature.

Basically I'm just siggesting that the rule be that if the signed data is
altered in any way, the signature should become mathematically invalid
(this
includes anyone encrypting portions of it). This is the general intention
with signatures anyway, we are simply considering changing the rule when
encryption becomes involved. I'm sorry but as a cryptanalyst I can see no
reason to introduce an extra rule that may by it's presence weaken the
encryption and signature.
                            Joe

> [1] http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0072.html
> [2]
>
http://lists.w3.org/Archives/Public/xml-encryption/2000Dec/att-0024/01-XMLEn

cryption_v01.html
>

Received on Friday, 26 January 2001 02:07:38 UTC