Re: XML Encryption, Requirements and design considerations

Malte, Christian,

Thank you for your comments.

1. I agree with Malte that CMS does not restrict the content type
   to envelopedData.  That eliminates one of the reasons that we
   favor the XML syntax over CMS.

2. However, it looks to me that CMS does not allow you to use
   a content-encryption key encrypted by a shared symmetric key
   (correct me if I am wrong).  If we want to support this requirement
   as Christian pointed out, we may need non-CMS format
   (the 'XML' syntax) anyway.

3. I agree that if an XML syntax is to be defined, algorithm
   identifiers should follow the convention of the ones for XML
   digital signature.  For example,
    <xenc:Object
Algorithm="http://www.w3.org/2000/04/xmlenc/des-cbc-pcks5padding"
               KeyID="http://www.company.com/keyIDs/#27813638176"
               IV="k0xDDAKBgNV=="
               Encoding="base64">




Hiroshi

--
Hiroshi Maruyama
Manager, Internet & Language Technology, Tokyo Research Laboratory
+81-46-273-4576 (will be changed to +81-46-215-4576 from April 24)
maruyama@jp.ibm.com



From: Malte Borcherding <Malte.Borcherding@brokat.com> (by way of "Joseph M.
      Reagle Jr." <reagle on 2000/04/19 11:28 PM

To:   xml-encryption@w3.org
cc:    (bcc: Hiroshi Maruyama/Japan/IBM)
Subject:  Re: XML Encryption, Requirements and design considerations




Hiroshi,

thank you for starting the discussion. We are also currently defining an XML
encryption structure, motivated by the requirement that intermediary should
not
have access to sensitive information, but needs to have access to the rest of
the document. We also came up with the alternatives of simply using a CMS
(PKCS#7) structure, and alternatively a similar XML structure.

The XML structure which defines the encryption algorithms, paramaters and
related information looks as follows:

<!ELEMENT EncryptionInfo
  (SubjectKeyIdentifier, KeyEncryptionAlgorithm,
   KeyEncryptionAlgorithmParameter?,
   ContentEncryptionAlgorithm,
   ContentEncryptionParamenter?,
   EncryptedKey)>

I believe it would be too clumsy to put all this information into attributes
of
an object. What is missing (as mentioned in previous discussions on the XML
Signature list) are URIs for the algorithms.

As for the CMS content, I think it is not useful to follow the restrictions
of
the appplication/pkcs7-mime type if this would mean that all encryped
information requires a MIME header. Regarding the encryption format
restrictions
mentioned in your paper, to my understanding, RFC 2311  (which is referenced
in
http://www.isi.edu/in-notes/iana/assignments/media-types/application/pkcs7-mi
me)
does not restrict the encryption format to enveloped data:

"
2.4 General Syntax

   The PKCS #7 defines six distinct content types: "data", "signedData",
   "envelopedData", "signedAndEnvelopedData", "digestedData", and
   "encryptedData". Receiving agents MUST support the "data",
   "signedData" and "envelopedData" content types. Sending agents may or
   may not send out any of the content types, depending on the services
   that the agent supports.
"

Malte

Hiroshi Maruyama wrote:
>
> I think it is our responsibility to start the discussion.  The motivation
> of XML encryption originally came from the needs for transcoding,
> where an intermediary ("transcoding proxy") modifies the contents
> according to the client's profile, such as the screen size of the client
> device and the end-user's preference.  However, it turned out through
> many discussions with customers, we found that it is common that
> some part of a document need access control and encryption is the
> natural way to achieve such access control.
>
> Based our experiences in XML parser, XML signature, and customer
> engagements, we wrote a short paper (attached below) on the
> requirements and design considerations of XML encryption.  I hope
> this will stimuate the discussion!
>
> Hiroshi

--
---------------------------------------------------------------
Malte Borcherding              Technical Research Manager
BROKAT Infosystems AG          Voice: (+49)711-78844 231
Industriestr. 3                Fax:   (+49)711-78844 779
70565 Stuttgart                WWW:   http://www.brokat.com
Germany                        email: Malte.Borcherding@brokat.com

Received on Thursday, 20 April 2000 06:47:52 UTC