You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Raul Benito <ra...@r-bg.com> on 2004/10/26 14:17:59 UTC
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:davanum@gmail.com]
> Sent: vrijdag 22 oktober 2004 15:02
> To: security-dev@xml.apache.org
> 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, maarten.gerbrands@nc3a.nato.int
> <ma...@nc3a.nato.int> 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/
>
RE: xmlsec-library lacks support for modification of existing
signatures in XML
Posted by Raul Benito <ra...@r-bg.com>.
> 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:raul-info@r-bg.com]
> Sent: dinsdag 26 oktober 2004 14:18
> To: security-dev@xml.apache.org
> Cc: security-dev@xml.apache.org; dims@apache.org
> 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:davanum@gmail.com]
>> Sent: vrijdag 22 oktober 2004 15:02
>> To: security-dev@xml.apache.org
>> 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, maarten.gerbrands@nc3a.nato.int
>> <ma...@nc3a.nato.int> 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/
>>
>
RE: xmlsec-library lacks support for modification of existing signatures in XML
Posted by ma...@nc3a.nato.int.
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. :( ");
}
}
-------------------------------------------------------------------
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 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.
Maarten Gerbrands
Communication Networks Branch,
Communication and Information Systems Division
NATO C3 Agency
-----Original Message-----
From: Raul Benito [mailto:raul-info@r-bg.com]
Sent: dinsdag 26 oktober 2004 14:18
To: security-dev@xml.apache.org
Cc: security-dev@xml.apache.org; dims@apache.org
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:davanum@gmail.com]
> Sent: vrijdag 22 oktober 2004 15:02
> To: security-dev@xml.apache.org
> 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, maarten.gerbrands@nc3a.nato.int
> <ma...@nc3a.nato.int> 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/
>