OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-poc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [issue - XMLDSIG] Digital Signature update with IBM XML DSIG Sign ingclass

Posting on behalf of Ralph. 

-----Original Message-----
From: Ralph Berwanger
To: Sid' 'Askary (E-mail)
Cc: Wei Wang
Sent: 4/17/01 1:12 PM
Subject: Digital Signature update with IBM XML DSIG Signing class

        The following information is the result of our exercising the
IBM signing tool.  I would share it directly with the POC group;
however, for reasons that I don't understand I am not able to post to
the POC listserv.  
We are in discussions with IBM regarding their signing class (XSS4).
Based on those discussions there are still two outstanding issues.  The
following details the issues.  It may be that we have not implemented
the class correctly; however, similar results are being recorded by
(1)  Digest values.  We have run the same baseline document through the
signing tool twice.  One time the document contains the XPATH transform
within the Signature element as defined in the specification.  This
transform should prompt the class to ignore the Signature ,
TraceHeaderList , and Via elements and all their descendants.  The same
document was presented to the signing class a second time, this version
deleted the XPATH statement forcing the digest domain over the entire
document.  Two different digest values should have been returned--both
cases returned the same digest value.  I have passed copies of the data
onto Chris Ferris at Sun.  He is testing the document using his code.  I
expect similar results.
(2) Namespace.  The specification requires that the signature elements
be qualified within a namespace designated as 'ds:'.   This caused
improperly identified tags to be generated by the signing tool when a
signature is generated for a template file.  The tool performed its
tasks and inserted <KeyInfo> and its children, but identified them as
residing with the default namespace.  We are treating this as a bug.
Our solution (aligned with similar findings at Sun) is to declare the
Signature element within the default namespace rather than the namespace
identified in the specification.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC