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