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-info@r-bg.com" <ra...@r-bg.com> on 2004/05/09 21:12:51 UTC
test_sixteen_external_dsa in,org.apache.xml.security.test.interop.BaltimoreTest
Hi,
My patch don't handle well this test case. It seems that it take on
account that the signed info is going to be c14n, reparsed & reimported.
But this is not alway the case. The SignedInfo is not c14n and
reimported if the c14n method is "safe". As stated in the second
paragraph of this mail
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001OctDec/0054.html.
And also in the REC
http://www.w3.org/TR/xmldsig-core/#sec-CanonicalizationMethod-NOTE, it
saids clearly that the above behavior is not always but only for
arbitrary c14n methods.
What do you think is the good behavior? For me it is weird to have a
test case that relays in this kind of unstandard behavior. And the parse
and imports is a very wasteful process that need to be only done with
insecure c14n. But if you think that the test is correct I can correct
my patch and send it back again.
Regards
Re: test_sixteen_external_dsa in,org.apache.xml.security.test.interop.BaltimoreTest
Posted by "raul-info@r-bg.com" <ra...@r-bg.com>.
raul-info@r-bg.com wrote:
> Hi,
>
> My patch don't handle well this test case. It seems that it take on
> account that the signed info is going to be c14n, reparsed &
> reimported. But this is not alway the case. The SignedInfo is not c14n
> and reimported if the c14n method is "safe". As stated in the second
> paragraph of this mail
> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001OctDec/0054.html.
> And also in the REC
> http://www.w3.org/TR/xmldsig-core/#sec-CanonicalizationMethod-NOTE, it
> saids clearly that the above behavior is not always but only for
> arbitrary c14n methods.
>
> What do you think is the good behavior? For me it is weird to have a
> test case that relays in this kind of unstandard behavior. And the
> parse and imports is a very wasteful process that need to be only done
> with insecure c14n. But if you think that the test is correct I can
> correct my patch and send it back again.
>
> Regards
>
It seems that I'm wrong. After reading the spec better it seems is
needed to c14n the xmlsignedinfo. Perhaps there is a way of avoiding the
c14n & reimport because it only make one test case fail. If anyone has
any idea...
Regards
Re: test_sixteen_external_dsa in,org.apache.xml.security.test.interop.BaltimoreTest
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
Cool, I will add tomorrow night.
Thanks!
Cheers,
Berin
Davanum Srinivas wrote:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=28872
>
> -- dims
>
> On Mon, 10 May 2004 19:52:19 +1000, Berin Lautenbach
> <be...@wingsofhermes.org> wrote:
>
>>Yah. I wanted to have another look tonight (just got to my computer)
>>and come back formally on that on the list.
>>
>>(Mind you - we really should look at integrating 23 into the unit tests.)
>>
>>Cheers,
>> Berin
>>
>>
>>
>>
>>Davanum Srinivas wrote:
>>
>>>ok. So, Raul needs to know that we need to pass 16 for us to accept
>>>the patch. right?
>>>
>>>-- dims
>>>
>>>On Mon, 10 May 2004 18:01:22 +1000 (EST), Berin Lautenbach
>>><be...@wingsofhermes.org> wrote:
>>>
>>>
>>>>Dims,
>>>>
>>>>Yup, but (my understanding) merlin16 is deprecated, but not incorrect.
>>>>The later tests are more stringent, but we still should be able to
>>>>validate 16 (notwithstanding cert validity and access to pothole.com,
>>>>which no longer exists).
>>>>
>>>>I.e. - if we are failing validation of 16 in unit tests, then we have a
>>>>problem. Moving to the later tests is a separate issue.
>>>>
>>>
>>>>>From Raul's perspective, 16 is one of *the* tests in our unit testing that
>>>
>>>>very strongly exercises the various requirements of XMLDSIG. It's one of
>>>>the few tests I have found that really tests some of the more arcane
>>>>aspects of the standard. It is very possible (as we see here :>) for 16
>>>>to fail, but everything else (in our database) to come up fine. So I
>>>>always treat 16 as my litmus test. If I can pass that, then I'm fairly
>>>>happy. If I can't, then I need to do some more work :>.
>>>>
>>>>Cheers,
>>>> Berin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Looks like merlin-xmldsig-sixteen has been deprecrated....and we are
>>>>>WAY behind the times, we need to update to latest interop tests
>>>>>
>>>>>-
>>>>>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002AprJun/att-0016/01-merlin-xmldsig-twenty-three.tar.gz> -
>>>>>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2003JulSep/att-0018/phaos-xmldsig-three.zip>
>>>>>details are at:
>>>>>http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html
>>>>>
>>>>>thanks,
>>>>>dims
>>>>>
>>>>>On Sun, 09 May 2004 21:12:51 +0200, raul-info@r-bg.com
>>>>><ra...@r-bg.com> wrote:
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>> My patch don't handle well this test case. It seems that it take
>>>>>> on
>>>>>>account that the signed info is going to be c14n, reparsed &
>>>>>>reimported. But this is not alway the case. The SignedInfo is not c14n
>>>>>>and
>>>>>>reimported if the c14n method is "safe". As stated in the second
>>>>>>paragraph of this mail
>>>>>>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001OctDec/0054.html.
>>>>>>And also in the REC
>>>>>>http://www.w3.org/TR/xmldsig-core/#sec-CanonicalizationMethod-NOTE, it
>>>>>>saids clearly that the above behavior is not always but only for
>>>>>>arbitrary c14n methods.
>>>>>>
>>>>>> What do you think is the good behavior? For me it is weird to have
>>>>>> a
>>>>>>test case that relays in this kind of unstandard behavior. And the
>>>>>>parse and imports is a very wasteful process that need to be only done
>>>>>>with insecure c14n. But if you think that the test is correct I can
>>>>>>correct my patch and send it back again.
>>>>>>
>>>>>>Regards
>
>
>
Re: test_sixteen_external_dsa in,org.apache.xml.security.test.interop.BaltimoreTest
Posted by Davanum Srinivas <da...@gmail.com>.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28872
-- dims
On Mon, 10 May 2004 19:52:19 +1000, Berin Lautenbach
<be...@wingsofhermes.org> wrote:
>
> Yah. I wanted to have another look tonight (just got to my computer)
> and come back formally on that on the list.
>
> (Mind you - we really should look at integrating 23 into the unit tests.)
>
> Cheers,
> Berin
>
>
>
>
> Davanum Srinivas wrote:
> > ok. So, Raul needs to know that we need to pass 16 for us to accept
> > the patch. right?
> >
> > -- dims
> >
> > On Mon, 10 May 2004 18:01:22 +1000 (EST), Berin Lautenbach
> > <be...@wingsofhermes.org> wrote:
> >
> >>Dims,
> >>
> >>Yup, but (my understanding) merlin16 is deprecated, but not incorrect.
> >>The later tests are more stringent, but we still should be able to
> >>validate 16 (notwithstanding cert validity and access to pothole.com,
> >>which no longer exists).
> >>
> >>I.e. - if we are failing validation of 16 in unit tests, then we have a
> >>problem. Moving to the later tests is a separate issue.
> >>
> >>From Raul's perspective, 16 is one of *the* tests in our unit testing that
> >>very strongly exercises the various requirements of XMLDSIG. It's one of
> >>the few tests I have found that really tests some of the more arcane
> >>aspects of the standard. It is very possible (as we see here :>) for 16
> >>to fail, but everything else (in our database) to come up fine. So I
> >>always treat 16 as my litmus test. If I can pass that, then I'm fairly
> >>happy. If I can't, then I need to do some more work :>.
> >>
> >>Cheers,
> >> Berin
> >>
> >>
> >>
> >>
> >>
> >>>Looks like merlin-xmldsig-sixteen has been deprecrated....and we are
> >>>WAY behind the times, we need to update to latest interop tests
> >>>
> >>>-
> >>>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002AprJun/att-0016/01-merlin-xmldsig-twenty-three.tar.gz> -
> >>>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2003JulSep/att-0018/phaos-xmldsig-three.zip>
> >>>details are at:
> >>>http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html
> >>>
> >>>thanks,
> >>>dims
> >>>
> >>>On Sun, 09 May 2004 21:12:51 +0200, raul-info@r-bg.com
> >>><ra...@r-bg.com> wrote:
> >>>
> >>>>Hi,
> >>>>
> >>>> My patch don't handle well this test case. It seems that it take
> >>>> on
> >>>>account that the signed info is going to be c14n, reparsed &
> >>>>reimported. But this is not alway the case. The SignedInfo is not c14n
> >>>>and
> >>>>reimported if the c14n method is "safe". As stated in the second
> >>>>paragraph of this mail
> >>>>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001OctDec/0054.html.
> >>>>And also in the REC
> >>>>http://www.w3.org/TR/xmldsig-core/#sec-CanonicalizationMethod-NOTE, it
> >>>>saids clearly that the above behavior is not always but only for
> >>>>arbitrary c14n methods.
> >>>>
> >>>> What do you think is the good behavior? For me it is weird to have
> >>>> a
> >>>>test case that relays in this kind of unstandard behavior. And the
> >>>>parse and imports is a very wasteful process that need to be only done
> >>>>with insecure c14n. But if you think that the test is correct I can
> >>>>correct my patch and send it back again.
> >>>>
> >>>>Regards
Re: test_sixteen_external_dsa in,org.apache.xml.security.test.interop.BaltimoreTest
Posted by Davanum Srinivas <da...@gmail.com>.
Looks like merlin-xmldsig-sixteen has been deprecrated....and we are
WAY behind the times, we need to update to latest interop tests
- http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002AprJun/att-0016/01-merlin-xmldsig-twenty-three.tar.gz
- http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2003JulSep/att-0018/phaos-xmldsig-three.zip
details are at: http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html
thanks,
dims
On Sun, 09 May 2004 21:12:51 +0200, raul-info@r-bg.com
<ra...@r-bg.com> wrote:
>
> Hi,
>
> My patch don't handle well this test case. It seems that it take on
> account that the signed info is going to be c14n, reparsed & reimported.
> But this is not alway the case. The SignedInfo is not c14n and
> reimported if the c14n method is "safe". As stated in the second
> paragraph of this mail
> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001OctDec/0054.html.
> And also in the REC
> http://www.w3.org/TR/xmldsig-core/#sec-CanonicalizationMethod-NOTE, it
> saids clearly that the above behavior is not always but only for
> arbitrary c14n methods.
>
> What do you think is the good behavior? For me it is weird to have a
> test case that relays in this kind of unstandard behavior. And the parse
> and imports is a very wasteful process that need to be only done with
> insecure c14n. But if you think that the test is correct I can correct
> my patch and send it back again.
>
> Regards
>
>