RE: Decryption Transform

On your first example I agree that an entity should sign the document to
confirm it came from the organization.  The question is which entity and
what does that entity represent?  I think this is like a corporate seal
where the signature would be validated back to a corporate entity (the
certificate would belong to an entity with the appropriate authority to sign
for the corporation.  In most cases it would have to be an executive who in
normal course of duties would sign for the corporation on such matters as
signing legal documents and contracts.  An executive could delegate this
authority to an application as long as the executive was responsible for the
application.  That is the executive was the sponsor of the application in
receiving a certificate from the CA.  In my opinion any certificate issued
must be linked to a person authorized to perform the functions and tasks
associated with the certificate and the applications associated with the
certificate.  

On your second example, it's a bit more nebulous.  Since parts of the
document are public, parts are confidential and parts are sensitive, who
signs the whole document?  You could segment the signatories to each level
of security such that each part has been signed as a whole, i.e. public
component is signed by the CPA to indicate that the information is true and
an executive could sign the confidential parts, etc.

AS a CPA you may not want to sign an entire document that the document is
true if you cannot validate parts of the document.  I would not recommend it
to anyone.

Cheers


-----Original Message-----
From: eric.e.cohen@us.pwcglobal.com
[mailto:eric.e.cohen@us.pwcglobal.com]
Sent: Thursday, July 05, 2001 8:10 AM
To: xml-encryption@w3.org
Subject: 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 12:18:41 UTC