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/
