ebXML Security & W3C Ongoing work

["Miller, Robert (GEIS)" <Robert.Miller@geis.ge.com>]

Hi team,

I've been doing some research on XML security, and came across a W3C Working
Draft
entitled "XML-Signature Core Syntax and Processing" whose URL is:
     http://www.w3.org/TR/2000/WD-xmldsig-core-20000104

This document would seem to be a good substitute for the X12 and UN/EDIFACT
Security
capability embodied in the security envelopes of X12.56 and IISO 9735 (-6, I
believe)

I was impressed with the overall capabilities defined, especially in the
ability to control what
is and is not signed - much more flexible than what is provided in X12 &
UN/EDIFACT.
I had some concerns about efficiency, and so undertook a short
correspondence with one
of the authors, who provided some relief for those concerns.

I believe this work will address several XML/EDI security concerns when it
is completed and
implementations of its capabilities become available.  If others concur, I
recommend we 
bring it to the attention of the ebXML team concerned with security
(&envleoping & transport).
If they like it, we should make use of it in our Technical Architecture
model.

Cheers,
               Bob
  


----------------------------------------------------------------------------
-----------------------------------------------

Hi Mark,

That's a good answer.  I only hope the third party implementors of the
specifications will
know of this concern up front, and will build this capability into the
products they target
for use in the XML/EDI marketplace.  As we develop our ebXML specifications,
I will try
to get visibility of these ideas in our technical models.  If you have any
third party 
implementors on your team, ou might share these ideas with them also.

Thank you for your contributions,

Cheers,
               Bob

	-----Original Message-----
	From:	Mark Bartel [SMTP:mbartel@JetForm.com]
	Sent:	Tuesday, January 11, 2000 9:28 AM
	To:	'Miller, Robert (GEIS)'
	Subject:	RE: ebXML Technical Architecture

	Hi Robert,

	I believe the workgroup answer would be that such issues are outside
of our
	scope.  We're trying to provide a small core that can be built upon
to
	provide more complex behaviours.  And pragmatically speaking, we're
tight on
	time despite limiting our scope.

	A few points, however:
	* implementations can cache resources locally
	* implementations can cache resource locator/resource digest pairs
locally,
	and therefore bypass calculating the digest on commonly computed
values
	* applications can create assertions and sign them; one such
assertion could
	be "this document validates against this DTD/Schema"

	Adding these ideas together should allow a low-cost solution.

	Hope this helps,

	-Mark

	 -----Original Message-----
	From: 	Miller, Robert (GEIS) [mailto:Robert.Miller@geis.ge.com] 
	Sent:	Monday, January 10, 2000 5:00 PM
	To:	Mark Bartel
	Subject:	RE: ebXML Technical Architecture

	Hi Mark

	Yours was the first reply.  I suppose that works, but it sounds too
	expensive.  My assumption is
	that the Schema/DTD is [very]large compared to the core document,
and has
	been registered
	and stored in a repository.  I would expect that the registration
process
	has computed a digital
	signature for the Schema/DTD, based on some key other than the key
being
	used by the
	creator of a the core document.  Thousands/millions of documents
would be
	created (by many
	senders for delivery to many recipients) based upon the same
Schema/DTD.
	Both sender
	and recipient would likely maintain local copies of the Schema/DTD,
and of
	its associated 
	metadata, including the digital signature for the Schema/DTD as
computed by
	a third party.

	When a new Schema/DTD is downloaded, full verification of the
Schema/DTD
	signature is
	appropriate.  When a Schema/DTD is referenced in a core document,
and a
	downloaded 
	copy of the Schema/DTD is available, and the Reference DigestValue
matches
	the 
	previously verified Schema/DTD DigestValue metadata value, a frugal
sender
	or recipient
	would want to omit full verification in day to day operations. 

	As I read the draft XML-Signature document, the sender's key is used
to
	develop the
	Schema/DTD DigestValue, and full verification of the Schema/DTD is
performed
	for each
	new document reference to the same Schema/DTD.  I think the XML/EDI
	community needs
	a less expensive answer than this.  Do you have a long answer that's
more
	affordable than
	your short answer?  If not, might your team consider the development
of such
	an answer?
	      
	Cheers,
	              Bob

	> -----Original Message-----
	> From:	Mark Bartel [SMTP:mbartel@JetForm.com]
	> Sent:	Monday, January 10, 2000 1:33 PM
	> To:	'Miller, Robert (GEIS)'
	> Subject:	RE: ebXML Technical Architecture
	> 
	> Hi Robert,
	> 
	> Since I'm only back at work today and you sent this email almost a
week
	> ago,
	> I would assume that your questions have been answered.  But I'll
give you
	> the quick answer, just in case, which is that we're assuming that
the DTD
	> or
	> Schema will be included as a resource in the signature if
conformance to
	> said DTD or Schema is required.  So core XML dsig behaviour will
verify
	> the
	> DTD or Schema, but the application is responsible for ensuring
that the
	> data
	> signed matches/conforms to the DTD/Schema.
	> 
	> -Mark Bartel
	> Senior Software Developer
	> JetForm Corporation
	> 
	>  -----Original Message-----
	> From: 	Miller, Robert (GEIS)
[mailto:Robert.Miller@geis.ge.com] 
	> Sent:	Tuesday, January 04, 2000 5:16 PM
	> To:	mbartel@JetForm.com; jboyer@uwi.com;
bfox@Exchange.Microsoft.com
	> Subject:	ebXML Technical Architecture
	> 
	> Hi folks,
	> 
	> I chair an ebXML (group formed by UN/CEFACT - OASIS to investigate
use of
	> XML for Electronic Data Interchange (EDI) http://www.ebXML.org )
team
	> which
	> is charged with defining the ebXML Technical Architecture.  One
topic of
	> interest and concern is Electronic Signatures, and I observe that
you are
	> co-authors of a working draft on that topic.
	> 
	> I quickly scanned the draft, and am pleased with the quality of
the work.
	> I
	> also Chair the ANSI X12C Subcommittee on Communications and
Controls, and
	> am
	> a participant in X12C/TG6 Security Task Group which developed the
security
	> envelopes for X12 and helped develop the security envelopes for
	> UN/EDIFACT.
	> As I try to relate my EDI environment knowledge to the XML
environment in
	> which I am but a novice, I find myself faced with some
security/legal
	> concerns that simply do not exist in the EDI environment.
	> 
	> In particular, an EDI document references a published standard,
whereas an
	> XML document references a DTD (or Schema perhaps) that is not
published,
	> and
	> may be dynamic.  If an XML/EDI document were to be signed by an
	> XML-Signature, my quick read and general intuition says the
signature
	> would
	> apply to the characters comprising the XML/EDI document, not
including any
	> characters referenced through pointers, as for example the
characters
	> which
	> make up the DTD (or Schema) when it is included by reference.
	> 
	> If faced with a legal challenge regarding the semantic intent of a
	> received
	> XML/EDI document, the XML-Signature can provide assurance that the
signed
	> information was unchanged and authorized.  But the semantic
meaning of the
	> information is defined by the metadata in the (unverifiable) DTD.
	> 
	> It would seem that the solution would be to glean the
signature/hash from
	> a
	> signed DTD and include that signature/hash in the XML/EDI
document, so
	> that
	> the parties could verify that the DTD referenced by the originator
was in
	> fact the DTD referenced by the recipient.  I expect that a
recipient would
	> want verification that the included signature/hash matched the
	> signature/hash of the included content.  Of course, this could be
	> accomplished outside XML-Security, but it seems to me that it
should be a
	> 'built-in' feature of XML-Security.  
	> 
	> How would your team propose that the capability I've described
above be
	> provided, given the XML-Signature capabilities defined in your
draft
	> document?  Is
	> this problem of interest to you, or is the problem in our court to
	> address?
	> 
	> Thank you,
	> 
	>   Bob Miller
	>     615-371-6037


  Bob Miller
    615-371-6037