AW: [dss-x] Re: AW: encryption profile

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

Hi Clemens,

for the encryption protocol / profile I would like to 
propose to discuss / consider the following issues:
1. a) The "SimpleContent" and "ComplexContent" choices in the EncryptRequest should
      be part of the InputDocuments-element (either directly - if 
      we could manage the change the DSS-Core at this point or define a 
      new dsse:InputDocuments-element, which especially contains these 
      alternatives - or as child of the Other-element). 
   b) In a similar fashion the documents to be decrypted (either EncryptedDataDocument
      or CipherData) in DecryptRequest should be part of the (redesigned?) InputDocuments-element.
2. It might be better to derive the dsse:SimpleContentType from 
   dss:DocumentBaseType instead of xs:base64Binary. Furthermore it
   should be discussed, whether this also should happen for the CipherDataType
   or whether our CipherDataType might better be derived from xenc:CipherDataType. 
3. "SimpleContent" and "ComplexContent" might be renamed to
   "OpaqueData" and "StructuredData" respectively. 
4. a) The encryptionAlgorithm-Attribute in EncryptRequestType should be 
      renamed to ContentEncryptionMethod to better reflect the fact that
      it specifies the (usually symmetric) algorithm to encrypt the content. 
   b) Furthermore it should be discussed whether having a URI here is sufficient
      for all cases. How would we distinguish between 2-key Triple-DES and 3-key 
      Triple-DES in this case or define a specific IV to be used for encryption? Hence 
      we should think about using an element of type xenc:EncryptionMethodType here,
      which contains among other optional elements the URI for the algorithm. 
   c) In a similar fashion it might be necessary to explicitely specify the KeyEncryptionMethod
      as one could want to use OAEP instead of PKCS#1 v1.5 for the same RSA-certificate,
      which would be specified in the ds:KeyInfo within the EncKeySelector-element.
5. Within the EncKeySelectorType (should it better be called RecipientsKeyInfo?) it would
   be nice, if one could use other elements directly without having the Other-element 
   (cf. #1). Furthermore the certValidation-Attribute should probably better be specified as URI
   to allow (e.g. in profiles) different (and more sophisticated) verification policies, which
   might include returning a more comprehensive verification report structure as optional output.
6. Should it be possible to explicitely specify the key which shall be used for decryption 
   (as some sort of optional KeySelector-element) in the DecryptRequest-element?

I'm looking forward to further discussing the above issues. 

Best regards,
   Detlef 
   

> -----Ursprüngliche Nachricht-----
> Von: Clemens Orthacker [mailto:clemens.orthacker@a-sit.at] 
> Gesendet: Dienstag, 16. Oktober 2007 10:24
> An: dss-x@lists.oasis-open.org
> Betreff: [dss-x] Re: AW: encryption profile
> 
> Hi Detlef,
> 
> Am Montag, 15. Oktober 2007 schrieben Sie:
> > 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.
> >
> 
> Thanks a lot for your interest and the comments.
> 
> > Below you will find some questions and comments concerning 
> the raised 
> > issues.
> >
> > [...]
> >
> > 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.
> 
> I think there are two arguments for the INSERT use case: 
> First, one might want to keep the content to be encrypted out 
> of the target document's context. For XML content to be 
> encrypted, for example, consider contained ID attributes that 
> conflict with the target document or certain namespace issues. 
> Second, to facilitate transmission, the inserted content 
> (e.g. a logo image) could be referenced (see the schema for 
> details) and cached for later re-use. 
> (Further, we might allow SwA references in the request 
> element holding the content to be encrypted, which of course 
> is outdated and using MTOM transport we anyway could include 
> the content in the target document. Still this would allow 
> for some backwards compatibility...) Anyway, I'm quite 
> convinced that there are many cases where it makes no sense 
> to include the plaintext data in the target document which 
> justifies the INSERT use case. (Probably we should make it 
> optional - a profile to the encryption protocol? however, 
> there is not much overhead in implementing it, so I advocate 
> leaving it in.)
> 
> > 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.
> 
> I should have mentioned this on yesterday's telcon. The TC 
> has to decide. I will post a message on that specific issue 
> on the list. Probably we could decide on this on the next meeting.
> 
> > 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?
> 
> I just noticed there was some discussion on this in the 
> former DSS TC, so I wanted to have this discussed here. I 
> think instead of http://www.w3.org/TR/xmlenc-core/ we should 
> use the xenc namespace URI http://www.w3.org/2001/04/xmlenc#
> 
> > Yes, but the Core should stay fixed, right?
> 
> We're currently discussing several additions/amandements to 
> the Core. I will post a message on that issue as well.
> 
> > > 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.
> 
> Right.
> 
> > > 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.
> 
> We still would need them (encryption of non-XML binary data, 
> XMLEnc referenced cipher data via xenc:CipherReference, ...)
> 
> 
> Thank you
> Clemens
> 
> 
> -- 
> Clemens Orthacker  A-SIT, Graz University of Technology
> Inffeldgasse 16a, 8010 Graz, Austria
> Tel: +43 316 873 5512         Web: http://www.a-sit.at/
>