http://issues.apache.org/bugzilla/show_bug.cgi?id=28872
-- dims On Mon, 10 May 2004 19:52:19 +1000, Berin Lautenbach <[EMAIL PROTECTED]> 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 > > <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] > >>><[EMAIL PROTECTED]> 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
