RE: Signing and Encryption

Apologies if what I'm about to mention has already been discussed but I've
been away and am now only catching up on my email.

When discussing signing plus encryption, it is important to remember that
an XML Signature can have cover multiple digests.  Though this feature is
valuable for signing multiple unique resources, it is also useful for
signing different views of the same resource.  In particular, a single
XML Signature can cover both the plaintext and encrypted form of an XML
instance.

1.  Hash the plaintext.
2.  Encrypt the plaintext.
3.  Hash the encrypted version.
4.  Create a <SignedInfo> over both hashes (including the appropriate
transforms).
5.  Sign <SignedInfo> to get your signature value.

See "http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/0034.html" 
for a detailed explanation.  

This capability may suggest solutions in addition to those already being 
discussed in this thread.

Ed

----- Original Message -----
From: "Rich Salz" <rsalz@caveosystems.com>
To: "Joseph Ashwood" <jashwood@arcot.com>
Cc: "meadowsj" <meadowsj@nobs.ca.boeing.com>; <xml-encryption@w3.org>
> Most auctions work this way, don't they? In other words, an online
> market would just record bids and not disclose the buyer until the end.
But already in the physical world that is seperated, the bid amount is
seperated from the authentication. This would be a very good example of
where a detached signature would be useful. Regardless Franklin came up with
a good reference for this usefulness, fair exchange hadn't occured to me.

Now I guess the next question would be can the fair exchange (or a varient)
be performed with detached signatures at least as effectively as with
attached signatures. If you read the article it also gives possibilities for
when the opposite may be desirable, partial contractless verification (PSS
actually makes use of this in the top bit).

So to recap, I withdraw my position that we need not concern ourselves with
the order of signing and encryption (specifically because of contract
signing issues). And unfortunately this means this will be more difficult.
Maybe it would be most efficient to create a seperate wrapper for each of
these cases:
<exposedSignature> the encrypted data is signed below with the signature in
the clear
<hiddenSignature> the data within is signed, the signature is encrypted
<signThenEncrypt> the data within was signed before encrypting, the data is
encrypted
<encryptThenSign> the data was encrypted then signed, this is a dangerous
action

With the possibility of having more options if they are ever needed. It may
also be necessary to build markings at a later date that specify the various
methods mentioned on http://www.acm.org/crossroads/xrds7-1/contract.html (as
noted by Franklin).
                    Joe (Ashwood)