Re: XMLEnc: some reactions to issues by Clemens

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

Juan Carlos, all,

Thanks for the input.

Am Donnerstag, 23. Oktober 2008 17:47 schrieben Sie:
> 1. You mention: "EncryptedDocument inheritance? Find a way to include it
> as DocumentWithSignature document child"
>
> This happens when you encrypt and generate an enveloped signature. My
> question is, why the tag <dsse:EncryptedDocument> should appear as child
> of the <dss:DocumentWithSignature>? to make it clear that this document
> contains encrypted parts? is not this clear from the fact that the
> document comes from a previous request that asks for this? this document
> will contain xenc:EncryptedData elements containing the encrypted
> parts.... could you please provide rationale for the need of this element?

First, EncryptedDocument contains information on where in the document 
encrypted data or keys are placed. This information is used in the decrypt 
request to designate the parts to be decrypted. The idea here is to allow 
for 'round-trip' support, ie. the EncryptedDocument can be directly passed to 
decrypt request. Of course these parts could be left away, assuming the 
application knows what it requested. 
The more important reason for EncryptedDocument is the grouping of the 
document itself and a requested referenced cipher data (referenced via a URI 
which might not be unique for the entire response, so this is the cleanest 
and most readable solution). The alternative would be to put the cipherdata 
in a seperate optional output and retrieve it via its URI. 

 
> An alternative would be to swap the order of InLineXML and
> EncryptedDocument in your example. That would solve the xml schema
> problems.

We should not mix up payload content and protocol data. The content of 
InlineXML is not validated.

> If not, then we should go for some changes, and I presume that if we do
> not want to touch the core, we should maybe define a new
> DocumentWithSignatureAndEncryptedParts, whose type could be an extension
> of dss:DocumentType for allowing this tag....

I tried to use as many original core types as possible, and therefore did not 
go for this solution, which is of course perfectly valid. It would however 
propose EncryptedDocumentWithSignature not to extend DocumentType, but simply 
to be of type EncryptedDocumentType. (I don't quite understand why the core's 
DocumentWithSignature has and not is a Document.)

Another alternative would be to make EncryptedDocumentType extend DocumentType 
(with the required Inline/Escaped/Base64XML child, which EncryptedDocument 
might not contain under very special circumstances, but which could then 
simply be empty) and introduce an abstract DocumentType in the core. No 
backwards compatibility issues here.

I will think some more about the pros and cons of each approach. 


>
> 2. In the second issue you write: "By default, sign before encryption.
> Introduce dsse:DetachedSignature element to change default behaviour.
> dss:SignedReferences (other elements?) imply signature operation (and
> new element is ignored?)"
>
> My understanding is that there is a need for something to indicate taht
> first is the signature and afterwards comes the encryption when no
> SignedReference or other optional input of the SignRequest is
> required... we always may define an empty element (<SignFirst> or the
> like) or even an attribute of EncryptionContent (?)

Since the document order of optional input _elements_ defines the processing 
order, I would propose to use an element for this, too. Further, this is only 
relevant if the application requests a default (detached) signature, that's 
why I proposed <DetachedSignature/>. The only problem is what to do when the 
request contains <DetachedSignature/> and further signature configurations 
(such as SignedReferences). I would propose to ignore <DetachedSignature/> in 
such a case.


Regards,
Clemens


>
>
>
> 4. Insertion of xmlenc-decrypt
>
> Actually, it seems to me that the xmlenc-decrypt states that one should
> make usage of the dt:Except as soon as there are parts of a signed
> document that are encrypted after the generation of the signature....
> (see http://www.w3.org/TR/xmlenc-decrypt#sec-purpose)
>
>
> [?] You also mention:"discuss use case enveloping signature prior to
> encryption"
> Is this not leading to the usage of xmlenc-decrypt transformation?
>
>
> Regards
>
> Juan Carlos.
>
> Clemens Orthacker escribió:
> > Juan Carlos, Detlef, all,
> >
> > The remaining encryption profile work items are listed below.
> >
> > EncryptionProfile I
> >
> > 1. finalize encrypt schema: see updated issues in
> > http://wiki.oasis-open.org/dss-x/Encryption_profile
> >
> > 2. decrypt schema (not yet started)
> >
> > - How to specify what parts of input to decrypt?
> >
> > - How to integrate decryption with verification (see xmlenc-decrypt)?
> > Specify DecryptRequest/Response only?
> >
> > 3. en/decryption processing (not yet started, probably the most
> > difficult section, kick-off after decrypt schema finished)
> >
> > I will try to finalize the schema (1. and 2.), so that we can focus on
> > remaining issues (most probably how to integrate EncryptedDocument
> > with the existing dss:DocumentBaseType) and on the processing section.
> > I am not an expert in DSS processing, probably we could sketch the
> > changes to the basic processing during the call? In this case, please
> > revise the DSS (basic) processing for the next call! Please also have
> > a look at
> > http://www.oasis-open.org/apps/org/workgroup/dss-x/download.php/28617/enc
> >ryption_profile_0.4.xsd
> >
> > EncryptionProfile II
> >
> > 1. start/finalize processing section
> >
> > 2. impact on other profiles?
> >
> > EncryptionProfile III
> >
> > 1. finalize draft profile document for balloting
> >
> > Am Dienstag, 21. Oktober 2008 schrieb Juan Carlos Cruellas:
> > > Dear Clemens,
> > >
> > >
> > >
> > > Next conf call is the first of the two ones devoted to the encryption
> > >
> > > profile. I think that it would be helpful to think in advance on the
> > >
> > > issues that you would like to be discussed (and eventually agreed if
> > >
> > > required) on this profile so that at the meeting we could see effective
> > >
> > > progress...Could you please let us know how do you think that we could
> > >
> > > get the maximum benefit of the next call, ie, maybe by enumerating the
> > >
> > > issues that you would like to be discussed in the next conf call, or
> > > any
> > >
> > > other suggestion that you may have?
> > >
> > >
> > >
> > > Thank you very much
> > >
> > >
> > >
> > > Regards
> > >
> > >
> > >
> > > Juan Carlos.