XMLEnc: some reactions to issues by Clemens

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

Clemens,
 
I have read again the contents of the wiki....please find below  
intermixed my first reactions to some of your issues:

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?

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

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....

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 (?)



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/encryption_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.
>