Re: AW: encryption profile

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

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/