EDI FAQS

Q: What are EDI and AS2? What do all of these funny acronyms stand for and what do they mean? EDI Electronic Data Interchange. It is a general term for the transfer of documents between trading partners, and the standards that are adhered to. It is also represented as EDIINT (EDI over the Internet). AS2 Applicability Statement 2. A specific secure transportation standard for EDI, namely EDI over HTTP. S/MIME Secure Multi-Purpose Internet Mail Extensions. It is the set of standards used for encryption and signing of a message/document. This governs not only the functions of signing and encryption, but also provides standards for the formatting of the final message so that a compliant reader will be able to easily identify the structure of the message. HTTP HyperText Transfer Protocol. It is a very flexible client-server protocol that is the backbone of the world wide web. SMTP Simple Mail Transfer Protocol. It is used to send email messages from one party to another. FTP File Transfer Protocol. It is a protocol governing file transfer and file management.

Q: What about AS1 and AS3? Both are similar to AS2 in the three principles they adhere to, but the communication protocol is different in each. AS1 is EDI over SMTP, while AS3 is EDI over FTP. Both AS1 and AS3 are also supported in IP*Works! EDI, but are not discussed specifically in this FAQ.

Q: Why do we even need to use AS2? Isn't SSL supposed to be securing the data? There are three primary purposes for the AS2 protocol 1) Confidentiality By encrypting a message, you are guaranteeing that only the intended recipient of the message will be able to decrypt it. This is also provided by an SSL communication, but only during the actual internet transfer. With AS2, the document itself is encrypted rather than just the transfer. 2) Authentication By signing a message, you are guaranteeing that only you could have sent this message to the recipient. This can also be provided in SSL by requiring client authentication. 3) Non-Repudiation By signing a receipt for the transaction, both parties have irrefutable evidence that the transaction has occurred. This functionality is not provided by SSL. In short, AS2 can allow two parties to communicate with each other without needing to vouch for the integrity of the other party (or their AS2 configuration).

Q: What is eBusinessReady (Drummond Group / DGI) Certification, and why is it so important? The Drummond Group is an independent organization that provides e-BusinessReady certification for applications that claim to support AS2 standards. Rather than hold compliant applications to a public standard, Drummond Group goes one step further and certifies that every application in its certification program has undergone compliance testing with every other application in that same program. You can be certain that any two applications that are e-BusinessReady certified have already successfully communicated with one another in compliance testing. Moreover, many companies are requiring that their trading partners adopt a solution that is certified by the Drummond Group.

Q: What happens during this transaction anyway? For all of its complexity in terms of its applications, AS2 boils down to two basic parts. A document is sent from an AS2 sender to an AS2 receiver via HTTP, and the receiver acknowledges the transfer by giving the sender a receipt. Step 1: AS2 Sender transmits document to AS2 Receiver The document is first prepared by the AS2 Sender. While you will generally establish the format of the document with your trading partner, the actual contents of the document are independent of the AS2 protocol itself. You can trade baseball statistics in text files, and it is still technically AS2. The sender of the document then optionally (but usually) S/MIME signs the document. The purpose of the signing of the document is three-fold. First, it establishes without a doubt that the AS2 Sender is the true sender of the document; only the sender of the document is capable of generating a signature that can be decrypted with the public key of the sender. Second, because the signature is created based on the contents of the document, you are guaranteed that the integrity of the document was preserved. If some nefarious third party intercepted the data and altered its contents, the signature and the document would not match. Third, by establishing that the AS2 Sender is the true sender of the document, the Receiver also establishes that the Sender *must* have knowingly sent the document. The sender cannot later deny that the document was sent if a signature is available stating otherwise. The sender of the document then optionally (but again, usually) S/MIME encrypts the document. Encryption is done one-way so that only the receiver of the message is capable of decrypting the message; not even the sender of the message can decrypt the document once encrypted. An appropriate analogy would be one involving an opened combination padlock. Anyone with the public key (the padlock) is capable of encrypting a document (closing the padlock), but only the owner of the private key (the combination to the padlock) can decrypt it. The message is then sent over HTTP or HTTPS to a server that the receiver is hosting. Generally, HTTPS is only used if S/MIME encryption is not, but it is possible to choose any option. It is of note that the encryption used by the S/MIME encryption is stronger than that used in HTTPS, but HTTPS encryption is less processor intensive and uses temporary session keys that expire after the session. Step 2: AS2 Receiver acknowledges the document with a receipt After the transfer of the document, a receipt is sent to the sender. The receipt is always signed for the same reasons that the document is, but it can be transferred a number of ways. The AS2 sender determines this when the document is sent. A synchronous receipt is one that is sent over the same HTTP/HTTPS connection before the connection is closed. This is the easiest option for the sender, and is generally not a problem for smaller documents that are very quickly processed. An asynchronous receipt is sent separately, and if this option is used, the HTTP/HTTPS connection is closed almost immediately after the transfer of the document. An asynchronous receipt can be sent a few ways, the most common of which are HTTP, HTTPS and email (SMTP). If HTTP or HTTPS is used, the AS2 Sender provides the HTTP server for the AS2 Receiver to connect to. If SMTP is used, the AS2 Sender provides an email address which the AS2 Receiver should send to.

Q: What kind of certificate will I need? Should I purchase one from a CA (VeriSign, Thawte, etc.)? Technically speaking, you can use any X.509 certificate containing a private key, even a self-signed one . You will need to negotiate with your trading partner what kind of certificate that you can use. If your trading partner requires that your certificate be signed by a trusted authority, then you should obtain one from a Certificate Authority. Otherwise, you can use the CertMgr component in our IP*Works! EDI toolkit to generate your own self-signed certificate. A demo application provided in the package can do this for you.

Q: What do I need to get from my trading partner? Your trading partner should be providing you with a few details. Most importantly, you'll need the public key of your trading partners certificate, which will be provided to you in CER or PEM format. Your trading partner will also provide you with an AS2 Identifier (a name, really) to be used in you communication.

Q: When one of these properties calls for a certificate, what do I use? If you are an AS2 Sender: The SigningCert properties are used to set your private key certificate. The RecipientCert property is used to set the public key of your trading partner's encryption certificate. The ReceiptSignerCert is used to set the public key of your trading partners' signing certificate. Quite often, this is the same certificate as the encryption certificate - check with your trading partner to be sure. If you are an AS2 Receiver: The Cert properties are used to set your private key certificate. The SignerCert property should be set to the public key for your trading partner.

Q: When I'm asked to use a private key, how do I set it? What are my choices? You're given 4 choices to use for your private key: PFX File Using this choice allows you to specify a PFX file (may also be a p12 extension) for the certificate. The advantage to this approach is that it is not necessary to install the certificate. You will need to specify the following properties: CertStoreType Set to "sstPFXFile" CertStore Set to the path and name of your PFX file CertStorePassword Set to the password for your certificate (leave blank if you do not have a password) CertSubject Set to the subject of the certificate. The special value "*" can be used as well to pick a random certificate from the file. Most pfx's will only have one private key certificate (although you can have multiple), so "*" is a good value if you are certain there is just one certificate. PFX blob Using this option allows you to use a certificate directly from memory. This is a valuable option for those who do not intend to store the certificate at all on the machine. You will need to set the following properties: CertStoreType Set to "sstPFXBlob" CertStore Set to the string representing the certificate. If this string is not Base 64 encoded, you will want to use the CertStoreB property in .NET to hold a binary value. User/Machine certificates (.NET only) Windows allows you to install certificates on your machine, in your registry. User certificates are certificates that have been installed for the given user account, while machine certificates are installed for use in any account. You will need to set the following properties: CertStoreType Set to "sstUser" or "sstMachine" CertStore Set to the name of the certificate store. Most commonly, private keys are kept in the "My" store, but you can configure it otherwise. CertSubject Set to the subject of the certificate. The special value "*" can be used as well to pick a random certificate from the store. Unless you know you have only one certificate installed in that store, you'll want to set the subject explicitly. JKS Store (Java only) In Java, your certificates are always kept on file. You will need to set the following properties: CertStoreType Set to "sstUser" CertStore Set to the path and name of your certificate store CertStorePassword Set to the password for your certificate (leave blank if you do not have a password) CertSubject Set to the subject of the certificate. The special value "*" can be used as well to pick a random certificate from the store, but again, unless you know you have only one certificate installed in that store, you'll want to set the subject explicitly.

Q: When I'm asked to use a public key, how do I set it? These are going to be sent to you as .CER files or .PEM's. You can simply read the contents out of the file and assign it to the object. Public key certificates are either DER (binary) or Base64 encoded. It doesn't matter how your certificate is encoded - the object will recognize both types, but if you are using a DER encoded certificate in .NET, you will want to assign the value to the byte array property (RecipientCertB, SignerCertB, etc.) to account for all the bytes.

Q: What should I be setting for AS2 Identifier? Your AS2 Identifier can be negotiated with your trading partner, but there's no standard for this. Common practices include your name, your company's name, or some other unique name. The only thing you really need to worry about here is to keep it consistent - your trading partner is going to look as this and be able to tell that it refers to you.

Q: Should I do a synchronous or asynchronous MDN? This is something that you can negotiate with your trading partner, but it is generally left up to the sender to specify (A receiver that implements the AS2 protocol must be prepared to do whatever the sender indicates here). The difference between the two is notable: A synchronous transaction is one in which the receipt that confirms the arrival of a document is sent over the same connection that was established to send the document. This is generally the easier of the two to configure, and is best to use when the expected response is going to be near immediate. An asynchronous transaction is one in which confirmation of the arrival of a document is sent over a separate connection, one that is determined by the sender. This is going to be useful when the document transferred is larger or may take more time to process, because the same connection does not need to be left alive while processing continues. This requires a bit more work from the sender, at least during set up, because a means of receiving these receipts must be set up (a web server or mail server), and the retrieval of the receipts needs to be coordinated with the sending program.

Print this post