W3C home > Mailing lists > Public > xml-encryption@w3.org > April 2000

Re: XML Encryption, Requirements and design considerations

From: by way of <Malte.Borcherding@brokat.com>
Date: Wed, 19 Apr 2000 10:28:27 -0400
Message-Id: <3.0.5.32.20000419102827.01a017f8@localhost>
To: xml-encryption@w3.org
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 Wednesday, 19 April 2000 10:28:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:12:57 UTC