More XML Encryption questions and issues ...

Hello, all. A few thoughts about the XML Encryption work, with some initial
thoughts from Joseph Reagle (JR>) added.

1. Do we need to worry about patents? (We assume not, as no one would want to
pay royalties for using the algorithms). From JR>We would be asking for
disclosures in the typical ways to try to prevent design bias and submarine
patents, but the fact that you ask the question recognizes the stickiness of
this issue.

2. Do we need to strongly consider the new AES (www/nist.gov/aes/)? Work with
Triple DES? Should it be method agnostic? From JR> Signature was agnostic, but
specied one Mandatory to support algorithm for interoperability purposes. I hope
we can do the same (given export issues). AES would probably be a good choice,
but the WG should decide this.

3. How about export rules? If we are not algorithm agnostic, how do we handle
the commercial requirements of the US, the limitations placed on what can go
outside of the US, and the needs of those outside the US?

4. Are different methods required for streaming XML (as may be used in
continuous auditing) versus "Archived" or file-oriented (XPath node sets)? From
JR> I don't know, I lump that in the parsers question we need to discuss.
Basically, could a XPat/SAX parser implement this?

5. How do different proposals effect processing speed, data size (transmission
speed, potential problems with limited memory in WAP/PDA devices), speed of
encryption/decryption, complexity of parser programming needed to manage
[recognizing encrypted data, knowing how to handle encrypted data, can it be
decrypted, should it be decrypted, should the decrypted results be left in cache
or memory]?

6. How will time/date authentication be handled? Will PMI also be required in
some cases?

7. How will tracking the original specified recipient be handled? (This order is
real, signed, and encrypted, but wasn't really for you originally.)

8. What type of user interface will be required for a non-technical end user to
specify element-wise encryption? Will it have certain standardized attributes?

9. Do you compress then encrypt, or encrypt then compress ... (we think to
compress then encrypt improves performance - but it's all about implementation.
Hackers do not attack encryption algorithms, they attack the implementation. If
someone can adjust a SSL session to change the establishment of the encryption
process, they don't need to see the data at all.)

10. How can you validate an XML file against a DTD/Schema when the elements and
attributes are hidden?

11. How can you convince people the encryption doesn't hide a virus? JR> I don't
think the standard could, though applications could try.

12. Will encryption and decryption be possible using XSL and other XML-standard
tools, or will programmatic tools be required?

13. Can we convince companies to throw in a red herring into their general XML
files to that encrypted XML files don't stand out like a sore thumb?

14. Can we ensure that no one makes changes to namespaces?

15. Would passwords be available for individuals, groups, companies, devices,
roles, mailing lists?

16. Do we move beyond elements and attributes to other information? If we have
an attribute lang="en" and wish to lock people out by the value of the
attribute, do we need to do element values as well for consistency?

Eric E. Cohen
Tools chair, XBRL.org
PricewaterhouseCoopers LLP.
eric.e.cohen@us.pwcglobal.com

also o/b/o
Dr. Aaron James Ferguson
PricewaterhouseCoopers LLP.
----------------------------------------------------------------
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 Friday, 20 October 2000 16:45:50 UTC