[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: encryption profile
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]