[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: encryption profile
Hi all, Here are some comments to the encryption profile proposal I uploaded last week http://www.oasis-open.org/apps/org/workgroup/dss-x/document.php?document_id=25384 (please note that the document contains comments which can be read by enabling 'show comments' in MS word) Section 1.5 (Overview) gives a short overview of the protocol's capabilities. Summarizing, an encryption request consists of one or many encryption keys and an arbitrary number of data to be encrypted (contents). All data contained in the request is to be encrypted for all recipients (ie., using all specified encryption keys). There are three basic use cases that can be arbitrarily combined: - parts of a provided XML document can be encrypted and REPLACED by the resulting xenc:EncryptedData elements - provided arbitrary (binary) data can be encrypted according to [XMLEnc] or [CMS] encryption syntax standards (or any other standard to be defined) (CREATE). - provided arbitrary (binary) data can be encrypted according to [XMLEnc] and INSERTED in a provided XML document. There are some issues that need further discussion: EP1. Encryption profile as new protocol. I propose to define <EncryptRequest> and <DecryptRequest> messages of type <EncryptRequestType> and <DecryptRequestType>, respectively. Both types extend <dss:RequestBaseType>. I think there is no need for a combination of signing- and encryption requests. An implementation of the encryption protocol should not be required to implement the signing part as well. EP2. URI (urn) identifiers for XMLEnc and CMS encryption need to be defined. (To my knowledge they don't exist.) Austrian CCE encryption could be included as well. EP3. DSS Core should define a <dss:KeySelectorType> (right now, it is inline in <dss:KeySelector>), so EncKeySelectorType could extend it. EP4. Should <dss:IntendedAudience> be used to specify the encryption keys to be used (in addition/alternative to EncKeySelector)? EP5. alternative propositions for element/type names: - SimpleContentType - ComplexContentType - InsertContentType (Base64Content) - CipherData - EncryptedDataDocument EP6. namespace declarations for (payload) content. The encryption protocol defines XPath expressions to select parts of content XML documents. In order to keep the namespace declarations (for these XPath expressions) out of the context of the element the XPath expression appears within, <SelectorNamespace> elements define the namespaces used in the XPath expression. ('request'-context and 'payload'-context should not be mixed up.) Further, implementations might not even have access to the context of the element the XPath expression appears within ([1]). Alternatively, the namespaces for the XPath expressions have to be inferred from the XML document (which is a non trivial task). Could <NamespaceType> be useful for DSS Core as well? EP7. <dss:InputDocuments> contains <Other> of type <dss:AnyType>. If it contained <xs:any> directly, the unnecessary <dss:Other> could be avoided. This way, the encryption content elements (<SimpleContent>,<ComplexContent>) could be included as childs of <dss:InputDocuments>. Thanks, Clemens [CMS] http://www.ietf.org/rfc/rfc3852.txt [XMLEnc] http://www.w3.org/TR/xmlenc-core/ [1] usually, web services are implemented using XML data bindings, which generate source code from XML schema. -- Clemens Orthacker A-SIT, Graz University of Technology Inffeldgasse 16a, 8010 Graz, Austria Tel: +43 316 873 5512 Web: http://www.a-sit.at/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]