encryption profile

[Clemens Orthacker <clemens.orthacker@a-sit.at>]

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/