RE: Decryption Transform

I would agree with Joe and John that you should never sign an encrypted
document.  It's like signing a blank check.  

Having said that, I could see an application signing an encrypted document
similar to a notary function. This notary function would stamp the document
to the effect that the document was issued (passed through) by the
application at this time and this date.  

Other than that I don't see any value in signing encrypted documents.  It
does not prove anything except time and date.  It does not validate content,
nor the signer, nor does it provide integrity.

 

-----Original Message-----
From: Joe Meadows [mailto:joe.meadows@boeing.com]
Sent: Tuesday, July 03, 2001 2:36 PM
To: Joseph M. Reagle Jr.
Cc: John Cowan; John Cowan; imamu@jp.ibm.com; maruyama@jp.ibm.com;
xml-encryption@w3.org
Subject: Re: Decryption Transform


At 22:17 7/2/2001, John Cowan wrote:
>I am arguing that the whole verify-decrypt-verify scenario is bad practice:
>it comes about only if people sign encrypted material, *which they should
>never do*.  We may need it nonetheless to compensate for pre-existing
>bad practice.

I'd also disagree with this. I can imagine encrypting a document, sending it
to a second party, having them sign the encrypted document, and pass it on
to
a third party. Seems like there were some sensible non-repudiation schemes
built
on this sort of logic in the past (the intermediate party doesn't know what
I
sent,
but given appropriate plain text or keys, can verify later if a contract
dispute
comes up). I realize I'm being light on details - blame it on really sunny
weather
in the pacific northwest [it's oh so unusual!]..

Cheers,
Joe

Received on Thursday, 5 July 2001 09:39:13 UTC