Ahmed, Zahid | 1 Mar 01:22 2002

RE: [ebxml-msg] RE: AS3?....


Yes, agreed that is ebXML transport neutral.

I question how viable FTP really is w.r.t. firewall, DMZ/network, 
and message authentication policies of many companies
though for ebXML type of transport option.

---Zahid

-----Original Message-----
From: Ralph Berwanger [mailto:rberwanger <at> bTrade.com]
Sent: Thursday, February 28, 2002 3:00 PM
To: Ahmed, Zahid; Greg Vesper; David Fischer; Jeff Lightcap;
ietf-ediint <at> imc.org <mailto:ietf-ediint <at> imc.org> 
Cc: Dave Bennett; ebxml-msg <at> lists.oasis-open.org; ebxml-dev <at> lists.ebxml.org;
Bill Morgan
Subject: RE: [ebxml-msg] RE: AS3?....

I think that we have managed to attribute a need for ebXML that simply
cannot be implied.  The ebXML Message Services were defined apart from any
transport protocol.  It would be wrong to attempt to justify a need for AS?
standards based on ebXML.  I am not sure there is a valid argument for
pursuing an AS2-like solution for FTP.  I am sure that anyone who tries to
use ebXML as the justification will be embarassed to know that ebXML Message
Service Specification will not promote the argument.  The specification is
very clear, it states: The ebXML architecture requires that the ebXML
Message Service protocol be capable of being carried over any available
communications protocol.  Therefore, this document does not mandate use of a
specific communications protocol. 

(Continue reading)

E.B. Dreger | 1 Mar 02:34 2002
Picon

Re: [ebxml-dev] RE: [ebxml-msg] RE: AS3?....


> Date: Thu, 28 Feb 2002 16:22:39 -0800
> From: "Ahmed, Zahid" <zahid.ahmed <at> commerceone.com>

> I question how viable FTP really is w.r.t. firewall, DMZ/network, 

Passive FTP in a restricted port range handles this nicely.

> and message authentication policies of many companies

IPSec or SSL-enriched FTP

> though for ebXML type of transport option.

I would, however, like to see the arguments for FTP.  Everyone
is familiar with HTTP.  There's S/MIME.  Yes, FTP works... but is
it really the best model for message passing?

Eddy

Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
--

Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist <at> brics.com>
To: blacklist <at> brics.com
Subject: Please ignore this portion of my mail signature.

(Continue reading)

Christian Putnam | 1 Mar 02:48 2002

FW: AS3?....

    I agree completely with bTrade's take on AS3.  I'll throw my two cents in here and make a couple of points:  One, AS3 doesn't exist as a standard. Two, It is misleading to use the term AS3 since users would infer that AS3 has a defined specification and interopability similar to AS1 and AS2. Three, the firewall issue that David Peet describes is a real problem with FTP.  Four, ebXML messaging will be the standand d'jour for B2B communications in a year or two so why muddy the waters with yet another standard.
 
    I believe that AS2 is finally getting traction in the marketplace.  AS1 will go nowhere-- Who wants their B2B transactions lost in SMTP never never land?  Instead of promoting new standards we (AS1/AS2 vendors) ought to focuse on promoting market adoption of AS2.
 
        "The disciples came to him privately, saying, "Tell us, what is the sign of your coming, and of the end of the world?"
 "You will hear of wars and rumors of wars; there will be famines, plagues, and earthquakes in various places; the                    sun will be darkened, the moon will not give her light, the stars will fall from the sky, the powers of the heavens  will be shaken; new unnecessary nonexistant communication stardards will deceive many; and then the end will come"."   -- Matthew 24 (mostly)
 
    Cheers,
 
    Christian Putnam
    CEO
    iSoft
 
 p.s.   ebXML messaging is going to be slow (to much parsing).
-----Original Message-----
From: David Peet [mailto:DPeet <at> bTrade.com]
Sent: Thursday, February 28, 2002 4:51 PM
To: Greg Vesper; David Fischer; Jeff Lightcap; ietf-ediint <at> imc.org
Cc: Dave Bennett
Subject: RE: AS3?....

Sent for Bill Morgan by David Peet:

 

 There currently is no "AS3".

For the past three years, bTrade has been facilitating a healthy exchange of opinions in this great debate.

Secure FTP is an established technology that leverages SSL to protect the session.

"SMIME-ing" the payload is easily achievable for a nested security schema, as is DES, 3DES, AES, PGP, etc.

Message Disposition Notifications are foreign to FTP servers and would thus present a formidable barrier to adoption by current S/FTP environments.

Finally, there is still the great firewall policy debates relating to exposing FTP ports to the Internet.

That is why Virtual Private Networks were created, to leverage the Internet for secure business communications without the risk of exposing FTP ports.

 

Those of us who have provided EDIINT solutions over the past two or three years have always understood these "FTP" challenges and have responded in kind to market demands.  To date, the market has demanded Secure FTP, AS1, and AS2. 

An AS3 offering can quickly be released by most of us, but adoption rates will not be nearly as high as AS1 or AS2, if AS3 gains traction at all.

However, AS3 offerings may provide a degree of consternation by those trying to simplify and consolidate secure Internet communications.

 

Regarding ebXML, the Message, Routing, and Transportation standard is agnostic to SMTP, HTTP, or FTP communications.

Furthermore, the ebXML protocol was carefully crafted to be neutral of all transport protocols.

HTTP, FTP, SMTP or any other "P" can be used within an ebXML framework.

 

By the way, did you hear about bTrade's AS4?

 

Bill Morgan

Executive Vice President,

Chief Solutions Officer

bTrade, inc.

www.bTrade.com

972.580.2900

 

-----Original Message-----
From: Greg Vesper [mailto:gvesper <at> cyclonecommerce.com]
Sent: Thursday, February 28, 2002 2:18 PM
To: David Fischer; Jeff Lightcap; ietf-ediint <at> imc.org
Cc: Dave Bennett
Subject: RE: AS3?....

 

I strongly suggest we take up the issue of demand.  Cyclone has been servicing market demand for this capability for several years in production hardened environments and would be happy to argue in favor of FTP as a valid transport for EDIINT.

 

Alternatively, the role of FTP within the ebXML standard could be elevated to achieve the same desired functionality with the advantage of what ebXML brings to the table.

 

Either way, the absence of FTP as a transport for secure B2B messaging is an obvious hole.  FTP is a valid transport with an enormous amount of existing infrastructure - it ought to be elevated in the appropriate standards, be it EDIINT, ebXML, or both.

 

I'm happy to actively participate in any initiatives in this regard.

Cheers,

-Greg.

 

Greg Vesper
Cyclone Commerce
Director, Product Management
480-627-1828

-----Original Message-----
From: owner-ietf-ediint <at> mail.imc.org [mailto:owner-ietf-ediint <at> mail.imc.org]On Behalf Of David Fischer
Sent: Thursday, February 28, 2002 12:38 PM
To: Jeff Lightcap; ietf-ediint <at> imc.org
Subject: RE: AS3?....

There is no proposed AS3 standard.  On several occasions, vendor's have requested an AS3 standard based upon FTP.  Thus far, we have not seen enough end-user demand to proceed with this, but if such demand becomes evident, we could.

 

Regards,

 

David Fischer

Drummond Group.

-----Original Message-----
From: owner-ietf-ediint <at> mail.imc.org [mailto:owner-ietf-ediint <at> mail.imc.org]On Behalf Of Jeff Lightcap
Sent: Thursday, February 28, 2002 12:47 PM
To: 'ietf-ediint <at> imc.org'
Subject: AS3?....

Anyone know what is proposed for AS3. Trailblazer Systems is implementing FTP with S/MIME. They also mention AS3 on their web site as a proposed standard: http://www.as400ftp.com/latestnews_detail.cfm?number=2

I can't find anything about this proposed standard anywhere except for the mention on the page indicated above.

Jeffrey Lightcap
Senior Application Engineer
Cleo Communications
www.cleo.com
jlightcap <at> cleo.com
1-815-654-8110 ext 2735

 

Jeff Lightcap | 1 Mar 03:21 2002

AS3?...

Well, it looks like I roused some bears out of hibernation with my question regarding AS3. All the points made are valid. The business issue is: Trailblazer Systems (AS400 specialists) have a FTP server implemented for Linens 'N Things that appears to use FTP/S/Mime (the wannabe AS3 according to Trailblazer). This presents a major complication for vendors/suppliers who need to communicate to many hubs (servers) using variants of secure IP protocols (AS1, AS2, FTP/SSL, etc).

Any one have experience with this server...Zmod Exchange from Trailblazer. There many of use who can produce solutions to work with this server but the suppliers to the retail supply chain should not have to put up with proprietary solutions.

Jeff Lightcap...Applications Engineer
Cleo Communications
jlightcap <at> cleo.com

David Fischer | 5 Mar 18:42 2002

Compression Order

We are beginning to implement the Compression Draft specification:
 
 
and an implementation decision has arisen.  When Compression is applied in concert with Signatures, which should be applied first?
 
    Compress + Sign    or
    Sign + Compress
 
        and
 
    Compress + Sign + Encrypt   or
    Sign + Compress + Encrypt
 
Different companies have presented valid business cases for each alternative. 
 
The advocates for Signing first desire the signature to be over readable text (you know what you are signing -- which is why we never Sign after Encrypting).
 
The advocates for Compressing first desire performance improvements.  In this case, Compression is compared as just another encoding scheme so it is really still plain text.
 
Discussions thus far have resulted in a consensus that the implementors should be able to apply these functions in either order when sending.  When receiving, the implementations should be able to process either case.
 
We are looking for further discussions. . .
 
Regards,
 
David Fischer
Drummond Group.
joe mcverry | 5 Mar 20:10 2002

Re: Compression Order


Signatures tend to be small - don't they?

Joe

> David Fischer wrote:
> 
> We are beginning to implement the Compression Draft specification:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
> 
> and an implementation decision has arisen.  When Compression is
> applied in concert with Signatures, which should be applied first?
> 
>     Compress + Sign    or
>     Sign + Compress
> 
>         and
> 
>     Compress + Sign + Encrypt   or
>     Sign + Compress + Encrypt
> 
> Different companies have presented valid business cases for each
> alternative.
> 
> The advocates for Signing first desire the signature to be over
> readable text (you know what you are signing -- which is why we never
> Sign after Encrypting).
> 
> The advocates for Compressing first desire performance improvements.
> In this case, Compression is compared as just another encoding scheme
> so it is really still plain text.
> 
> Discussions thus far have resulted in a consensus that the
> implementors should be able to apply these functions in either order
> when sending.  When receiving, the implementations should be able to
> process either case.
> 
> We are looking for further discussions. . .
> 
> Regards,
> 
> David Fischer
> Drummond Group.

--

-- 
----------- 
Joe McVerry
American Coders Ltd.
POBox 97462
Raleigh, NC   27624  USA
919.846.2014 (voice/fax)
http://www.americancoders.com
Home Of OBOE - an EDI and EDI/XML Translator
    and xBaseJ - xBase Database Engine For Java

Kit (Christopher) Lueder | 5 Mar 20:46 2002
Picon

Re: Compression Order


I think the issue is not the size of the signatures (which may be small), but
the size of the document being signed, which may be enormous. Compressing the
document prior to signing it means less processing overhead when performing the
signature operation. (This is a benefit for compressing first.)

But I lean toward the Signing First approach. Another benefit of that is you can
uncompress it and make it readable and not violate the signature. If you
compress first, uncompressing it means you are no longer looking at a signed
document.

Kit Lueder.
MITRE.

joe mcverry wrote:
> Signatures tend to be small - don't they?
> Joe
> 
> > David Fischer wrote:
> >
> > We are beginning to implement the Compression Draft specification:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
> >
> > and an implementation decision has arisen.  When Compression is
> > applied in concert with Signatures, which should be applied first?
> >
> >     Compress + Sign    or
> >     Sign + Compress
> >
> >         and
> >
> >     Compress + Sign + Encrypt   or
> >     Sign + Compress + Encrypt
> >
> > Different companies have presented valid business cases for each
> > alternative.
> >
> > The advocates for Signing first desire the signature to be over
> > readable text (you know what you are signing -- which is why we never
> > Sign after Encrypting).
> >
> > The advocates for Compressing first desire performance improvements.
> > In this case, Compression is compared as just another encoding scheme
> > so it is really still plain text.
> >
> > Discussions thus far have resulted in a consensus that the
> > implementors should be able to apply these functions in either order
> > when sending.  When receiving, the implementations should be able to
> > process either case.
> >
> > We are looking for further discussions. . .
> >
> > Regards,
> >
> > David Fischer
> > Drummond Group.

--

-- 
    _/    _/             Kit C. J. Lueder       
   _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
  _/_/_/    _/  _/_/_/ 7515 Colshire Dr        Cell: 703-577-2463
 _/   _/   _/    _/   Mailstop W658           FAX:  703-883-3383
_/    _/  _/    _/   McLean, VA 22102-7508   Mail: kit <at> mitre.org
Worse than an unanswered question is an unquestioned answer.

David Fischer | 5 Mar 21:20 2002

RE: Compression Order


Yes, signatures are small but the effort to create them is directly related to
the size of the file being signed.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: owner-ietf-ediint <at> mail.imc.org
[mailto:owner-ietf-ediint <at> mail.imc.org]On Behalf Of joe mcverry
Sent: Tuesday, March 05, 2002 1:10 PM
To: David Fischer
Cc: ietf-ediint <at> imc.org
Subject: Re: Compression Order

Signatures tend to be small - don't they?

Joe

> David Fischer wrote:
>
> We are beginning to implement the Compression Draft specification:
>
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
>
> and an implementation decision has arisen.  When Compression is
> applied in concert with Signatures, which should be applied first?
>
>     Compress + Sign    or
>     Sign + Compress
>
>         and
>
>     Compress + Sign + Encrypt   or
>     Sign + Compress + Encrypt
>
> Different companies have presented valid business cases for each
> alternative.
>
> The advocates for Signing first desire the signature to be over
> readable text (you know what you are signing -- which is why we never
> Sign after Encrypting).
>
> The advocates for Compressing first desire performance improvements.
> In this case, Compression is compared as just another encoding scheme
> so it is really still plain text.
>
> Discussions thus far have resulted in a consensus that the
> implementors should be able to apply these functions in either order
> when sending.  When receiving, the implementations should be able to
> process either case.
>
> We are looking for further discussions. . .
>
> Regards,
>
> David Fischer
> Drummond Group.

--
-----------
Joe McVerry
American Coders Ltd.
POBox 97462
Raleigh, NC   27624  USA
919.846.2014 (voice/fax)
http://www.americancoders.com
Home Of OBOE - an EDI and EDI/XML Translator
    and xBaseJ - xBase Database Engine For Java

James M Galvin | 5 Mar 23:08 2002
Picon

Re: Compression Order


I'm not aware of any technical reason (security-related or otherwise)
why you would have to choose one over the other however, semantically,
the reasoning that applies to sign before encrypting applies here also.

If you sign the compressed (encrypted) form instead of the original
"text", then strictly speaking the only security service available to
you is origin authentication.  It would be *wrong* to associate or infer
or in any way tightly-couple any authorization semantics with the
signature.  It would be *wrong* to associate or infer or in any way
tightly-couple any characteristic or attribute that suggests the entity
that created the signature had any knowledge whatsoever of the actual
content that was signed.

I would expect this to be an issue in most business applications and
contexts.

Jim

--
James M. Galvin <galvin <at> acm.org>

On Tue, 5 Mar 2002, David Fischer wrote:

    Date: Tue, 05 Mar 2002 11:42:50 -0600
    From: David Fischer <david <at> drummondgroup.com>
    To: ietf-ediint <at> imc.org
    Subject: Compression Order

    AS3?...We are beginning to implement the Compression Draft
    specification:

    http://www.ietf.org/internet-drafts/draft-ietf-ediint-compre
    ssion-00.txt

    and an implementation decision has arisen.  When Compression
    is applied in concert with Signatures, which should be
    applied first?

        Compress + Sign    or
        Sign + Compress

            and

        Compress + Sign + Encrypt   or
        Sign + Compress + Encrypt

    Different companies have presented valid business cases for
    each alternative.

    The advocates for Signing first desire the signature to be
    over readable text (you know what you are signing -- which
    is why we never Sign after Encrypting).

    The advocates for Compressing first desire performance
    improvements.  In this case, Compression is compared as just
    another encoding scheme so it is really still plain text.

    Discussions thus far have resulted in a consensus that the
    implementors should be able to apply these functions in
    either order when sending.  When receiving, the
    implementations should be able to process either case.

    We are looking for further discussions. . .

    Regards,

    David Fischer
    Drummond Group.

Kepa Zubeldia | 6 Mar 04:11 2002

Re: Compression Order


What if you need more than one signature?  Common situation in 
healthcare.  It would have to be

sign - sign - sign - compress - encrypt

So you know what you are signing at each step, before it turns into "mush".

Kepa

David Fischer wrote:

> We are beginning to implement the Compression Draft specification:
> 
>  
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt
> 
>  
> 
> and an implementation decision has arisen.  When Compression is applied 
> in concert with Signatures, which should be applied first?
> 
>  
> 
>     Compress + Sign    or
> 
>     Sign + Compress
> 
>  
> 
>         and
> 
>  
> 
>     Compress + Sign + Encrypt   or
> 
>     Sign + Compress + Encrypt
> 
>  
> 
> Different companies have presented valid business cases for each 
> alternative. 
> 
>  
> 
> The advocates for Signing first desire the signature to be over readable 
> text (you know what you are signing -- which is why we never Sign after 
> Encrypting).
> 
>  
> 
> The advocates for Compressing first desire performance improvements.  In 
> this case, Compression is compared as just another encoding scheme so it 
> is really still plain text.
> 
>  
> 
> Discussions thus far have resulted in a consensus that the implementors 
> should be able to apply these functions in either order when sending.  
> When receiving, the implementations should be able to process either case.
> 
>  
> 
> We are looking for further discussions. . .
> 
>  
> 
> Regards,
> 
>  
> 
> David Fischer
> 
> Drummond Group.


Gmane