Before you can begin sharing documents using AS2, you need to make a number of decisions—some internal and some in conjunction with your trading partners.

1. Firewall Security
   First, it is important to realise that running AS2 software means you are allowing receipt of transactions or documents from the Internet. You need to consider how to secure this “doorway” against malicious attacks. The most common approach is the use of a firewall, which looks at incoming transactions and filters them according to the rules you define. Two ways you might configure your firewall are:
   
   
   • Allow each trading partner to send AS2 on a specific “port”, or network address. The firewall can be configured to accept transactions for that port only from specific sources (such as the IP address of a particular trading partner). This is a very safe approach but considerably increases the overhead involved in setting up a new partner.
   • Use a DMZ (or de-militarised zone): all AS2 traffic comes in on a port through the firewall, but the computer running AS2 can only talk to other computers in your organisation through a further firewall. This configuration eliminates the need to set up a separate security solution for each trading partner, but makes up for the lower security of letting any traffic into the computer running AS2 by isolating it from other computers.
     
     
2. Digital Certificates
   The next step is to decide how to manage the digital certificates you will be using. You can either generate your own certificates or use one of the Certificate Authorities (CAs), such as Verisign and Entrust, to manage the process for you. As well as handling the routine administration of certificates, the checks run by CAs provide additional assurance to trading partners that the holder of a certificate is who they claim to be. On top of that, CAs can “revoke” a certificate before it expires if it is “compromised” and will advise you to change your certificate if they suspect it has been compromised. CA certificates also contain an expiration date that will prompt the CA to verify the identity of your trading partner on a regular basis, increasing the security of the system still further. Clearly, you will need to pay an annual fee for the CA’s services.
   
   The alternative to using a CA is to get everyone to “self-generate” certificates, allowing them to set their own expiration dates. This simplifies the management headache but does reduce the security of the system, since no organisation is “policing” the system and confirming that a certificate does belong to the person it appears to come from. Moreover, if you have many trading partners, adding and updating certificates can become a significant burden. The self-generated certificate model is currently more common in B2B as many B2B software applications include a certificate self-generation capability.
   
   If your trading partners set the rules, you may need to support both models, with some partners asking you to use a certificate from a CA, while others will accept self-generated certificates.
   
   Whichever route you choose, you must be careful not to lose access to your private key (by forgetting your own password, for instance), since neither a CA nor a system that self-generates certificates can retrieve it. In these circumstances, you will need to generate a new certificate and distribute it to all your trading partners, and you or your partners may need to re-send some documents if they were sent using the old key.
   
   
3. HTTP Protocol
   A third decision is whether or not to use the secure HTTP protocol. If you are already using digital certificates to sign your messages through encryption, this is probably not necessary, since layering encryption does not usually strengthen security, while it increases the overhead of transmission. Secure HTTP can be used if the content is not already encrypted, but GXS recommends encrypting all content using digital certificates as a matter of course, since this allows you and your trading partners to confirm that content has really been sent by the organisation named on the document, as well as ensuring confidentiality by preventing data from being intercepted in transit.
   
   
4. Receipts
   A more complex decision is which of the five options for handling receipts (known as message disposition notification or MDN) you should use. The choices are:
   
   
   • No receipt: this is a poor choice, since it generates no audit trail
   • Plain receipt: returned immediately to signify that a message has been received, but not signed by the recipient
   • Signed receipt: returned immediately and signed. This provides the strongest audit trail, since it not only confirms that the message was received but also that the receiver was probably the intended recipient, since they had access to the private key of the intended recipient
   • Asynchronous plain receipt: the same format as the plain receipt but sent later rather than immediately
   • Asynchronous signed receipt: the same format as the signed receipt but, again, sent later rather than immediately
   
   The document the sender sends specifies the form of receipt you must send back, so you need to make sure your software can support all five options. You can make this choice yourself when sending documents—although your trading partners may ask you to request a particular form of receipt to ensure their own audit trail meets their needs. The form of receipt needs to be specified for each partner when you set up your AS2 software.
   
   
5. Encryption Algorithm
   The next step is to decide on an encryption algorithm from those supported by your AS2 software. Options include, but are not limited to: no encryption, triple DES, RC2 40, and RC2 128. Algorithms using 128 bit keys (Triple DES and RC2 128) are much stronger and therefore more secure. Of course, it’s essential that the software used by your trading partner can support the algorithm you intend to use, so you need to confirm which algorithms your partners can handle before you begin live trading. AS2 indicates the encryption method in the message headers, making it easy for your software to determine which decryption algorithm to apply.
   
   
6. Signature Algorithm
   A final choice is the signature algorithm to be used. AS2 offers options: no signature, SHA-1 and MD5. Again, using signatures will make the process more secure since they make it much easier to prove that the person it appears to come from really sent a message. The AS2 standard recommends using SHA-1 but you should also support MD5 in case any of your trading partners are using it.
   
   Of course, you also need to have reached agreement about the content of the document you are sending, by developing implementation guides for EDI messages or creating schemas for XML documents. For example, you and your partner need to know that you are sending an invoice, that the first data item is the invoice number and is so many characters long, that the second data item is the date, that the third data item is the sender’s supplier number and so on.
   
   Once you have made these choices, you need to configure them into your AS2 software (see box). The best AS2 solutions will allow you to set each option on a partner-by-partner basis in the trading partner’s profile, which will also include the address (a web URL) of their AS2 server. In addition, you will need to load your partner’s certificate into your AS2 software to give you access to their public key, used for encrypting the messages you send to them and for validating messages they send to you.

The final step before you attempt live trading is to verify that both partners have configured their systems correctly by sending a test document. Of course, you will need to reload your partner’s certificate and retest the configuration each time a partner’s certificate expires.