Re: Suggestions for requirements ...

At 04:52 PM 10/27/2000 -0400, Joseph M. Reagle Jr. wrote:
>At 15:36 10/22/2000 -0700, Steve Wiley wrote:
>>Attached is a short paper regarding our experiences with XML encryption.
>
>Thanks for the well thought out requirements. Two questions:
>
>>http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/att-0011/01-myproof-xml-encryption-position.html#Nested 
>>Encryption
>>It is possible that a user may want to apply selective or full encryption 
>>to a target document that has already had some selective encryption applied
>
>Is this requirement is in opposition to your detached document requirement 
>which asks that the original tags not be altered. So basically, one should 
>have the option not to change the original tag structure?

Yes, it would be in opposition if it was the same implementation.  The 
requirement is as you
surmised. "one should have the option not to change the original tag 
structure".  I did not intend
this to be a requirement of XML Encryption.  The requirement is that an 
implementation should
be able to have a requirement and have the ability to implement the 
requirement "the original
document structure not be changed".  Other implementations could require 
"the use of additional
tags".  The XML Encryption requirement would be that "an implementation be 
able to require
either the preservation or change of the original document".  I believe 
that a <Reference XPath>
attribute is necessary to allow "the option not to change the original tag 
structure".


>>http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/att-0011/01-myproof-xml-encryption-position.html#Mutiple 
>>Encryptions
>
>What exactly do you mean by an encryption/decryption protocol [1]?

A set of rules for encryption and decryption that guarantee the integrity 
of the document.
a. The document can be restored to its original pre-encryption form.
b. That all the information originally encrypted by a single key can be 
retrieved.  (But not
necessarily with that key alone.)

The example below shows how information may be hidden by later 
encryptions.  I believe
that the integrity of a document that allows multiple encryptions and 
multiple encryption
keys requires that a precise set of rules and procedures be followed by the 
entities that
are performing encryption or decryption.  I think that this fits the 
definition of a protocol.
Let me know if you differ.  I don't mind being corrected or using different 
terms to avoid
confusing issues.  I give a fairly detailed example scenario below.


>I expect we'll define a
>1) syntax for representing decrypted information and the (optional?) 
>information that can be used to decrypt it
>2) process for encrypting data into the representation syntax, and a 
>process for decrypting it, but no "protocol" in my understanding [1,2] ...?

Unless I misunderstand, I don't think this is enough.  Although we could be 
thinking the
same thing and its my use of the term "protocol" that is causing 
confusion.  Again, see the
scenario below.


>http://www.landfield.com/rfcs/rfc2828.html
>    $ protocol
>       (I) A set of rules (i.e., formats and procedures) to implement and
>       control some type of association (e.g., communication) between
>       systems. (E.g., see: Internet Protocol.)
>       (C) In particular, a series of ordered steps involving computing
>       and communication that are performed by two or more system
>       entities to achieve a joint objective. [A9042]

Here is a possible scenario.  A company has a employee data base that is
stored as a single XML document.  They encrypt salaries with Key S, names
and addresses with key N, and medical information with key M.  This all
works fine.  The accounting department gets Key S, the benefits department
gets Key N and key M, etc.  Each department can get the information they
need.

This company has a security assurance group and they have established some
requirements for this document.
1. No matter how many encryption-decryption processes are performed on the
    document it must always be possible to restore the document to its original
    form.
2. The document must be restored to its original form and re-encrypted
    with new keys every two years or sooner if necessary.  This document is
    expected to last many years and may need to be re-encrypted with stronger
    encryption or new algorithms.
3. Nested or overlapping encryption is allowed.
4. Any individual or set of allowed fragment types may be encrypted.  The
     allowed fragment types are:
     a. Entire XML elements.
     b. The CDATA content of an element.
     c. The CDATA content of an element attribute.
5. Any user of the document must be able to tell if  they are denied any
    information when they decrypt.  That is, the application performing
    decryption must warn the user if it is not able to decrypt all information
    because of missing keys.
6. The decrypt application must warn the user if they are about to perform
    an action that will destroy of inhibit the integrity of the document.  For
    example if they are decrypting in a order that may make it difficult to
    restore the document to its original form.

The IS department was given the task to design a set of rules that encryption
and decryption entities must follow to meet the above requirements.  Note that
this is only one example of many possible protocols.  This is the set of rules
they designed.

1. The only encryptions allowed will be:
    a. The encryption of an entire XML element.
    b. The encryption of the CDATA of an XML element.
    c. The encryption of the CDATA of an XML element attribute.
2. The document will contain a single <Encryption> element which will contain
    a single <EncryptionInfos> element.  Each time an encryption is performed
    on a fragment or set of fragments one <EncryptionInfo> element will be
    appended to the end of the list of <EncryptionInfo>s contained by the
    <EncryptionInfos> element.  The order if the <EncryptionInfo>s must be
    preserved.
3. The <EncryptionInfo> element will contain all information needed to decrypt
    the fragments that were encrypted in the encryption that created the
    <EncryptionInfo> element.
4. The <EncryptionInfo> element will contain one or more <Reference> elements
    that will uniquely identify all the fragments that were encrypted.  The
    references must identify the exact set of fragments at the time of the
    encryption.  Note, that the reference(s) may only identify the exact 
set if
    the document is in a certain state.  If any later encryptions were 
performed
    they may hide fragments that were already encrypted.
5. There are only two encryption procedures allowed:
    a. When an entire element is encrypted it is replaced by an
       <EncryptedContent> element.  The <EncryptedContent> element will have
       a unique 'Id' attribute that will be referenced by the <Reference 'URI'>
       attribute in its <EncryptionInfo> element which resides elsewhere in
       the document <Encryption> element.
    b. When the CDATA of an element or an attribute is encrypted the element
       will be left intact.  Only the CDATA will be replaced.  The CDATA will
       be replaced by a 64base encoding of the cypher text.  This type of
       encryption will be referenced using the <Reference 'XPath'>
       attribute in its <EncryptionInfo> element which resides elsewhere in
       the document <Encryption> element.  A <Reference 'URI'> can not be used
       because a previous encryption could have already encrypted the CDATA
       and assigned an 'Id' attribute to the element.
6. Two decryption procedures will be allowed:
    a. The original document may only be decrypted in reverse order of the
       encryptions.  This is accomplished by only decrypting using the last
       <EncryptionInfo>.  Once the decryption is completed the <EncrytionInfo>
       element is deleted.  Then the process is repeated until the required
       document state is reached.
    b. Copies of the document may be decrypted in any manner the user chooses.
       The decryption application must warn the user that if they do not follow
       the procedure above:
         i.   They may not retrieve all the original information.
         ii.  They may destroy the integritiy of the document.  That is, this
              decryption may succeed but any subsequent decryptions may fail.
         iii. They may not be able to repair the document or ever be able
              to restore it to its original state.

Example Scenarios:
1. The benefits department has keys N (employee name and address) and key
    M (employee medical info).  There are several legal disputes in process
    and the legal department wants all information about those individuals
    kept from the regular employees in the benefits department.  So they
    apply key K to the document.  Now the benefits depart needs updated
    information on some employees.  They make a copy of the document and
    apply their N and M keys to the document.  The decrypt applications
    gives them the warning that they are decrypting out of sequence.  But
    since they got the information they required, and since the document
    is a copy, every thing is OK.
2. The same situation as above except it is the accounting department
    and they need to tally all salaries.  They apply their S key and get
    the warning that there is missing information because they
    applied decryption out of sequence.  The application tells them
    that key L was used to encrypt the entire elements of certain
    employees.  The accounting department then makes request to the
    legal department to release the salary information that is hidden
    by the L key encryption.  The legal depart issues a sanitized
    report to accounting with the required salary information.

Steve Wiley


>__
>Joseph Reagle Jr.
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
>

Received on Saturday, 28 October 2000 13:41:27 UTC