Re: Combining signing and encrypting

Regarding combining signature and encryption, David Solo writes:

>An alternative suggestion, made originally by Jim Schaad, is to define a
"don't
>decrypt" transform.  Coupled with a rule that says, in general "decrypt
then
>verify", this would allow the signer to indicate an exception.  An
implication
>of this is that signing applications need to be encryption aware.

I like Jim Schaad's idea.  This is an elegant way to handle
signature/encryption
interdependency.  One may object to put this information in <Transform>
because it is not actually a transformation.  Instead,
I would like to propose to use the <SignatureProperty>
element to convey this information as in the following example:


  <Signature Id="sig1" xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod
        Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026">
      </CanonicalizationMethod>
      <SignatureMethod Algorithm
="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
      <Reference URI="#order135">
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
        <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
    <Object>
      <SignatureProperties>
        <SignatureProperty Target="#sig1">
          <xenc:NoDecrypt Target="#enc1" xmlns:xenc
="http://www.w3.org/2000/10/xmlenc" />
        </SignatureProperty>
      <SignatureProperties>
    </Object>
  </Signature>
        :
  <DecryptionInfo xmlns="http://www.w3.org/2000/10/xmlenc" Id="enc1">
    <EncryptionMethod Algorithm="http://www.w3.org/2000/10/xmlenc#rsa"/>
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
      <X509Data>...</X509Data>
    </KeyInfo>
    <ReferenceList>
      <Reference URI="#encryptedData11"/>
    </ReferenceList>
  </DecryptionInfo>
        :
  <PurchaseOrder Id="order135">
    <Item>  ... </Item>
    <Payment>
      <EncryptedData xmlns="http://www.w3.org/2000/10/xmlenc"
                     Id="encryptedData11">
        k0xFFH56...
      </EncryptedData>
    </Payment>
  </PurchaseOrder>


Here, the <PurchaseOrder> is first encrypted in its <Payment>
part and signed.  The signing application must know
that there is an encrypted portion in the content to be signed,
and put an appropriate <xenc:NoDecrypt> element in the
<SignatureProperty> element.

The verifier should look at this information and decide
which part needs to be decrypted first.  If there is no
explicit <xenc:NoDecrypt> element, the default assumption
is to decrypt all the encrypted portions before verification.

Hiroshi

--
Hiroshi Maruyama
Manager, Internet Technology, Tokyo Research Laboratory
+81-46-215-4576
maruyama@jp.ibm.com



From: david.solo@citicorp.com@w3.org on 2000/11/21 03:41

Please respond to david.solo@citicorp.com

Sent by:  xml-encryption-request@w3.org


To:   xml-encryption@w3.org
cc:
Subject:  Combining signing and encrypting



XML Signing and Encrypting

At the workshop, I promised to send a couple paragraphs on minimum
requirements
around handling documents with both encryption and signatures (sorry about
the
delay, I've been moving and on vacation).

In general, both signature and encryption operations may be performed on an
XML
document.  Depending on the usage case (see below), a signature may be
applied
to plaintext or ciphertext portions of documents.   To verify a signature,
the
recipient must know whether to decrypt before or after signature
verification
(possibly differently for different encrypted portions).  In order to
enable
efficient and automated signature validation, a goal of the design should
be to
allow well-behaved applications to indicate to the verifier/recipient how
to
unambiguously figure out in which order to perform decryption and signature
validation operations (ill-behaved applications may always cause things to
break). [Note: the suggestion is to add this last sentence to the
requirements
document.]

Some examples of usage include:
- Initial device generates transaction information with certain encrypted
elements.  Intermediate application constructs full transaction and signs
it or
adds signature to original transaction (source authentication).  Result is
that
signature covers ciphertext and recipient must verify, then decrypt.

- Signed document/transaction is received and must be archived.  Sensitive
information in document is to be protected by encrypting while allowing
search/filter on plaintext elements.  Result is that elements must be
decrypted
before verification.

- Signed transactions are passed within a department/workgroup environment
with
a secured network.  Certain transactions must be forwarded outside the
department at which time sensitive data is encrypted.  Recipient must
decrypt,
then verify

- A document is generated from a collection of XML document, some of which
contain encrypted portions.  The new document is signed.  Recipient must
verify
signature prior to any decryption.

- Various multiple combinations based on the earlier sign/encrypt thread.

Possible approaches
Its probably a reasonable assumption that in many cases, the application
will
have a priori knowledge of how to handle the document (e.g., its always
decrypt/verify).  I'm not sure if there's a way to indicate this in a
schema
description.
An alternative suggestion, made originally by Jim Schaad, is to define a
"don't
decrypt" transform.  Coupled with a rule that says, in general "decrypt
then
verify", this would allow the signer to indicate an exception.  An
implication
of this is that signing applications need to be encryption aware.

Received on Tuesday, 28 November 2000 02:29:01 UTC