> I was afraid that the state machine was intended to prevent this usage.
> However the API methods, neither the javadocs mention anything about this
> intended limitation. I have experienced this as very confusing. I think
> the
> least thing what could be done, is inlude this in the javadoc comment at
> every method relying on certain state of the state machine.
>
> The way is state machine is currently used is done the following way:
> -------------------------------------------------------------------
> public void changeSomethingInSignatureElement {
> if (this._state == MODE_SIGN) {
> /* Normal operation: change something in signature */
> }
> }
> -------------------------------------------------------------------
>
>
> I think the following way would be better. This prevents giving the
> impression the method has done the "change" successfully.
> -------------------------------------------------------------------
> public void changeSomethingInSignatureObjectElement {
> if (this._state == MODE_SIGN) {
> /* Normal operation: change something in siganture */
> }
> else {
> throw SomeException("Failed, I am in SIGN-mode. :( ");
> }
> }
I agree completely with you, the second one is the good one. And it is the
way it should be from now on. I will take a look and fix it(if you have
some patches of course don't hesitate to send it) in the CVS but it will
be post 1.2., sorry.
> -------------------------------------------------------------------
>
> Good idea, to include a method like "copyForModifing", but it involves
> quite
> a lot of changes.
>
> What about to including a method like "public void setState(int mode)" in
> the org.apache.xml.security.utils.ElementProxy class?
>
> Example:
> -------------------------------------------------------------------
> /**
> * @arg mode Should be one of the following values: MODE_CREATE,
> MODE_DECRYPT, MODE_ENCRYPT, MODE_PROCESS, MODE_SIGN, MODE_UNKNOWN,
> MODE_VERIFY
> */
> public void setState(int mode) {
> this._state = mode;
> }
> -------------------------------------------------------------------
>
> This allows the programmer the override the default state, so he should be
> aware what he is doing.
>
> Current state is automatically defined by the ElementProxy. If the
> ElementProxy is constructed from a blanc XML-document, it will be in mode
> MODE_CREATE, if constructed from an existing signature it is set to
> MODE_PROCESS.
>
I'm not against it but I think it will become irrelevant when we migrate
our API to JSR105.
> I think the assumption: "an application can be only interested in signing
> and doing modification in a xmlsec-signature, if it is created from
> scratch"
> is wrong.
>
> Simple example:
>
> A system consists in two parts.
> The first part assembles an unsigned XMLSignature. It will put 500
> references into it.
> The first part will send the unsigned xml-sec-signature to the second part
> in XML.
> The seconds parts verifies the references inserted by the first part and
> will sign the XMLSignature.
>
> The second part is currently not able to sign the signature, because the
> XMLSignature will be MODE_PROCESS at the second part. The request to sign
> the XMLSignature will be ignored by the library. I think has actually lead
> to a more insecure operation.
>
> It's not very difficult to make up a few more cases where you want sign a
> XMLSignature, or to update the hash value of a Reference in a
> XMLSignature,
> without starting from scratch.
>
>
I don't think is a good overall architecture to send a semi valid xml
signature over the wire, but perhaps there are some case where is needed
(that i don't realize right now). But then if you don't want a copy method
I should add a constructor that creates the object in MODE_CREATE but read
from an xml dom.
Regards, and thank you for your suggestions they were appreciated indeed.
> Maarten Gerbrands
> Communication Networks Branch,
> Communication and Information Systems Division
> NATO C3 Agency
>
>
>
> -----Original Message-----
> From: Raul Benito [mailto:[EMAIL PROTECTED]
> Sent: dinsdag 26 oktober 2004 14:18
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: xmlsec-library lacks support for modification of existing
> signatures in XML
>
>>
>> Thanks for you reply Davanum.
>>
>> I would like to contribute and submit a patch, but before doing that, I
>> think it is necessary to discuss these changes. I need some more
>> background
>> information about the existing code. Please, developers, give me some
>> info
>> about the states defined in the
>> org.apache.xml.security.utils.SignatureElementProxy class.
>> I need to know what the purpose of this state-machine is, since the
>> usage
>> of
>> these states in derived classed are restricting the functionality I am
>> looking for.
>> Raul Benito, I believe you are the author of this SignatureElementProxy
>> class, perhabs you can answer some of my questions?
>>
> Im'm not the author of it. The @author tag is filled by the CVS with the
> last guy who has commit the file.
> Anyhow I can try to answer your questions.
> Regarding the state machine I think was dessign to not permit what you are
> trying. i.e. that a xml readed signature can be modified by the program
> without sending an exception.
> And that's good idea, to catch problems when you think you are verifying
> something that you have recived when in reality what are you doing is just
> verifing something that you have created.
> Anyhow perhaps you can do a copyForModifing method, that copy everything
> and put the signature to MODE_SIGN again.
>
> Hope it helps you,
> Regards,
> Raul
>
>> Maarten Gerbrands
>> Communication Networks Branch,
>> Communication and Information Systems Division
>> NATO C3 Agency
>>
>>
>> -----Original Message-----
>> From: Davanum Srinivas [mailto:[EMAIL PROTECTED]
>> Sent: vrijdag 22 oktober 2004 15:02
>> To: [EMAIL PROTECTED]
>> Subject: Re: xmlsec-library lacks support for modification of existing
>> signatures in XML
>>
>> Maarten,
>>
>> I'd encourage you to submit patches for portions of the toolkit that
>> you think need more work...As usual, it's a work in progress and more
>> hands are needed to make it more useful :) i will let others answer
>> the specific questions.
>>
>> -- dims
>>
>>
>> On Fri, 22 Oct 2004 13:11:42 +0200, [EMAIL PROTECTED]
>> <[EMAIL PROTECTED]> wrote:
>>> I am developing an editor for "XML Security Labels". A "XML Security
>> Label"
>>> includes the W3C XML Signature standard.
>>> I am using your Java library as a toolkit for the creation,
>>> verification
>> and
>>> modifications of the XML signatures.
>>> I find some parts of the library very inflexible, particularly the
>> Manifest
>>> class and Reference classes.
>>> In order to use References the developer is forced to use the Manifest
>>> class.
>>>
>>> Mainly the Manifest and Reference objects (classes) are limiting the
>>> flexibility in my opinion.
>>> . There is no possibility to remove existing references.
>>> . It is not possible to create a Reference without inserting it into
>>> the
>>> Manifest (since the Reference constructors are protected) . If the
>> manifest
>>> is generated from a XML-document, adding References will be ignored
>> without
>>> throwing an Exception. The "addDocument", method simply returns.
>>> . Regenerating the digest values of the References will be ignored if
>>> the
>>> Manifest have been constructed from an existing XML-document.
>>>
>>> Conclusion:
>>> Library can generate XML signatures and store it in XML.
>>> The stored signature can be verified without any problem.
>>> (This is where all the sample scripts and tests are based on as well.)
>>> If a more complex path is required, for example creation of the
>>> signature,
>>> modify the signature, resign the signature, it seems to be nearly
>>> impossible.
>>>
>>> Can somebody please explain to me why this state-machine (MODE_SIGN,
>>> MODE_CREATE) in the ElementProxy objects exists and what the benefits
>>> are?
>>> For what reason are the constructors of the Reference object not made
>>> public, and why does the Reference need to be constructed with a
>>> Manifest
>>> instead of a more abstract object or interface?
>>>
>>> Maarten Gerbrands
>>> Communication Networks Branch,
>>> Communication and Information Systems Division
>>> NATO C3 Agency
>>>
>>>
>>
>>
>> --
>> Davanum Srinivas - http://webservices.apache.org/~dims/
>>
>
