AW: encryption profile

["Huehnlein, Detlef" <Detlef.Huehnlein@secunet.com>]

Hi Clemens,

to define a DSS-like interface for encryption  
(of (parts of) XML documents or other binary data)
is a great idea and I hope that we will be able 
to standardize such an interface in DSS-X soon. 

Below you will find some questions and comments concerning
the raised issues. 

> 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. 

The necessity of the first two use cases is clear to me, but
I'm not sure, whether we really need the third use case (INSERT).
It seems to me that one may first insert the binary data into an XML-document 
and then get the relevant parts encrypted (as in the first use case, REPLACE).

Is there a particular reason, why we need to support the third use 
case in the interface? It seems that an interface, which only covers 
the first two cases might be equally powerful, but considerably 
simpler and more DSS-like.  

> 
> 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.

Yes, therefore it might be better to define a separate encryption 
protocol. However I'm not sure, whether this would cause a conflict
with the defined scope of DSS-X.   

> 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.

Wouldn't it be possible to use the URI
http://www.w3.org/TR/xmlenc-core/ for XMLEnc and
urn:oid:1.2.840.113549.1.7.3 (i.e. the OID of EnvelopedData)
or (as the encryption-context is clear) even urn:ietf:rfc:3369 for 
CMS-encryption?

> EP3. DSS Core should define a <dss:KeySelectorType> (right 
> now, it is inline in <dss:KeySelector>), so 
> EncKeySelectorType could extend it.

Yes, but the Core should stay fixed, right? 

> 
> EP4. Should <dss:IntendedAudience> be used to specify the 
> encryption keys to be used (in addition/alternative to 
> EncKeySelector)?

This would imply that the encryption service needs to 
have this "directory capability". Hence this should probably
better be optional. 

> EP5. alternative propositions for element/type names: 
>  - SimpleContentType
>  - ComplexContentType
>  - InsertContentType (Base64Content)
>  - CipherData
>  - EncryptedDataDocument

If we would confine ourselves to the first two use cases 
(REPLACE, CREATE) then (as far as I see it right now) we do
not need these additional structures. The Input and Output
objects would be entire documents. 

Best regards,
   Detlef

--
Dipl. Inform. (FH)
Dr. rer. nat. Detlef Hühnlein
Partner
secunet Security Networks AG
Sudetenstraße 16
96247 Michelau
Telefon +49 9571 896479
Mobil   +49 171  9754980
detlef.huehnlein@secunet.com
www.secunet.com