Thanks!
Cheers,
BerinDavanum Srinivas wrote:
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
