[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XMLEnc: some reactions to issues by Clemens
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]