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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


Subject: RE: [ebxml-msg] ds:Signature Algorithm


Yes, there are good use cases.  But we can't cover everything. . .

The group decided not to discuss multiple signatures at all in the spec.  I
suppose we could change all the SHALLs to SHOULDs in section 4.1.3 (Signature
Generation) but I would expect interoperability problems with doing things not
in the spec.  We started considering all the problems with Signature ordering
and decided not to go down that path.

If we exclude all Signature elements, all we are missing is the case of signing
over another Signature (I sign then my boss signs) and we don't have to worry
about signature ordering.  If you want to create a signature over something
else, you could, just by changing the Transform for your one Signature.
However, if something else signs afterwards, your signature would be broken (the
end would not know to exclude the new signature when validating yours).

Does everyone still agree?

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
Sent: Tuesday, October 23, 2001 5:40 PM
To: 'David Fischer'; Christopher Ferris (E-mail)
Cc: ebXML Msg
Subject: RE: [ebxml-msg] ds:Signature Algorithm



David,

What was the rationale behind excluding ALL signature elements?

I thought there were two distinct use cases that applied to
the cases:
	a) to sign over existing signatures
		- e.g., useful when you want to prove party P1 (who has the
first
		signature) did sign a document in the event P1 denies it
later (right!)

	b) to exclude existing signatures because verifying data integrity
of the document
		is the primary purpose and proving somebody actually did
sign the document
		is not necessary.
This is a business decision, and excluding one or the other use case doesn't
make sense to me.

Cheers,
-Suresh



-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Tuesday, October 23, 2001 5:04 PM
To: Christopher Ferris (E-mail)
Cc: ebXML Msg
Subject: [ebxml-msg] ds:Signature Algorithm


Chris,

Since we are deciding to exclude ALL signature elements, shouldn't we get
rid of
the
http://www.w3.org/2000/09/xmldsig#enveloped-signature algorithm and just
use:

   <XPath> not(ancestor-or-self::ds:Signature) </XPath>

which would exclude ALL ds:Signature elements?  Or better yet:

   <XPath> not(ancestor-or-self::ds:Signature |

ancestor-or-self::*[@soap:actor="http://oasis-open.org/committees/ebxml-msg/
next
MSH"] |

ancestor-or-self::*[@soap:actor="http://schemas.xmlsoap.org/soap/actor/next"
] )
</XPath>

Regards,

David Fischer
Drummond Group.


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



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


Powered by eList eXpress LLC