RE: Decryption Transform

Should someone sign an encrypted "document"?

Example 1:

I am a corporation creating an XML file of tax reporting information with
sections inside specific to (which "selectively unfold" for) four different
taxing agents within one tax agency (eg, State of Michigan and agents for
corporate, payroll, motor fuels and sales tax.) Each agent can see some
general information available to the agency but not an outsider, while
being limited to opening only their specific tax information.

The agency wants some assurance that the file as a whole was signed and
dated by the appropriate and authorized submitter (on file submitter from
on file company).

This would seem to require a signature applied to an encrypted file.

Example 2:

A corporation wished to publish an XML file containing financial
information, both publicly disclosed and private, using XBRL. The file will
have some information anyone can see, and the rest is limited by audience -
the bank can see some, internal divisional managers can see some, outsiders
see only that which is meant for the publc. In addition, I want to have my
CPA examine the file as a whole and provide a signature stating that the
file as a whole is the same as the detail and summaires that the CPA firm
has provided selective assurance over. That would also require a signature
on the outside.

<eccn />




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-----


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


----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.

Received on Thursday, 5 July 2001 11:12:01 UTC