Like any other ASx file transfer, AS2 file transfers typically require both sides of the exchange to trade SSL certificates and specific "trading partner" names before any transfers can take place. AS2 trading partner names can be any valid phrase.
Unlike any other ASx file transfer, AS2 file transfers offer several "MDN return" options instead of the traditional options of "yes" or "no". Specifically, the choices are:
Return Synchronous MDN via HTTP(S) (a.k.a. "AS2 Sync") - This popular option allows AS2 MDNs to be returned to AS2 message sender clients over the same HTTP connection they used to send the original message. This "MDN while you wait" capability makes "AS2 Sync" transfers the fastest of any type of ASx file transfer, but it also keeps this flavor of MDN request from being used with large files (which may time out in low bandwidth situations).
Return Asynchronous MDN via HTTP(S) (a.k.a. "AS2 Async") - This popular option allows AS2 MDNs to be returned to the AS2 message sender's server later over a different HTTP connection. This flavor of MDN request is usually used if large files are involved.
Return (Asynchronous) MDN via Email - This rarely-used option allows AS2 MDNs to be returned to AS2 message senders via email rather than HTTP. Otherwise, it is similar to "AS2 Async (HTTP)".
Do not return MDN - This option works like it does in any other ASx protocol: the receiver of an AS2 message with this option set simply does not try to return an MDN to the AS2 message sender.
AS2 with Synchronous MDN via HTTP(S)
You encrypt a data file with the public key on your partner's SSL certificate and sign it with the private key of your organization's SSL certificate as you bundle everything into an AS2 message. (Both the encryption and signing steps are optional, but should be used when possible.)
You send the AS2 message to your partner's AS2 server AND WAIT UNTIL YOUR PARTNER RETURNS AN "MDN" RESPONSE. (Credentials and cleartext message headers may be protected with SSL transport in this step.)
Your partner will retrieve your AS2 message off his/her AS2 server. (Credentials and cleartext message headers may be protected with SSL transport in this step.)
If the message is encrypted, your partner will decrypt it using the private key on his/her SSL certificate. If the message is signed, your partner will validate your signature using the public key on your SSL certificate. Your partner will also use the contents of the AS2 message to verify that the data file they now have is identical to the data file you sent them.
If you requested an MDN delivery receipt for your data file, your partner will calculate a cryptographic hash from the data file they received, sign the hash (and some other information) with the private key on their SSL certificate and create an MDN delivery receipt message.(The signing step is optional and controlled by the original message sender.)
Your partner will send his/her MDN delivery receipt message back as a response to your still-waiting AS2 "send message and get MDN" request. Once you receive this response (or time out while waiting) you will close your connection. (Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
You will inspect your partner's MDN delivery receipt message, making sure that you can verify his/her signature using the public key on your partner's SSL certificate and that the cryptographic hash calculated from your partner's copy of your data file matches the same hash calculation from your original data file.
AS2 with Asynchronous MDN via HTTP(S)
You encrypt a data file with the public key on your partner's SSL certificate and sign it with the private key of your organization's SSL certificate as you bundle everything into an AS2 message. (Both the encryption and signing steps are optional, but should be used when possible.)
You send the AS2 message to your partner's AS2 server and close the connection. (Credentials and cleartext message headers may be protected with SSL transport in this step.)
Your partner will retrieve your AS2 message off his/her AS2 server. (Credentials and cleartext message headers may be protected with SSL transport in this step.)
If the message is encrypted, your partner will decrypt it using the private key on his/her SSL certificate. If the message is signed, your partner will validate your signature using the public key on your SSL certificate. Your partner will also use the contents of the AS2 message to verify that the data file they now have is identical to the data file you sent them.
If you requested an MDN delivery receipt for your data file, your partner will calculate a cryptographic hash from the data file they received, sign the hash (and some other information) with the private key on their SSL certificate and create an MDN delivery receipt message. (The signing step is optional and controlled by the original message sender.)
Your partner will send his/her MDN delivery receipt message back by posting it to your AS2 server.(Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
You will retrieve your partner's MDN delivery receipt message off your AS2 server. (Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
You will inspect your partner's MDN delivery receipt message, making sure that you can verify his/her signature using the public key on your partner's SSL certificate and that the cryptographic hash calculated from your partner's copy of your data file matches the same hash calculation from your original data file.
AS2 with (Asynchronous) MDN via Email
You encrypt a data file with the public key on your partner's SSL certificate and sign it with the private key of your organization's SSL certificate as you bundle everything into an AS2 message. (Both the encryption and signing steps are optional, but should be used when possible.)
You send the AS2 message to your partner's AS2 server and close the connection. (Credentials and cleartext message headers may be protected with SSL transport in this step.)
Your partner will retrieve your AS2 message off his/her AS2 server. (Credentials and cleartext message headers may be protected with SSL transport in this step.)
If the message is encrypted, your partner will decrypt it using the private key on his/her SSL certificate. If the message is signed, your partner will validate your signature using the public key on your SSL certificate. Your partner will also use the contents of the AS2 message to verify that the data file they now have is identical to the data file you sent them.
If you requested an MDN delivery receipt for your data file, your partner will calculate a cryptographic hash from the data file they received, sign the hash (and some other information) with the private key on their SSL certificate and create an MDN delivery receipt message. (The signing step is optional and controlled by the original message sender.)
Your partner will send his/her MDN delivery receipt message to an email server via SMTP. Often, this will be your partner's local email server. (Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
If the MDN delivery receipt message were sent to your partner's local email server, it will now deliver it to your email server using the SMTP protocol. Along the way your partner's MDN delivery receipt message may traverse several intermediate email servers as it is relayed across the Internet or corporate email infrastructure.(The cleartext MDN delivery receipt message is rarely protected with SSL transport if relay servers are involved.) This step will be skipped if the MDN delivery receipt message was delivered directly to your email server in step #6.
You will retrieve your partner's MDN delivery receipt message off your local email server using the POP3 protocol. (Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
You will inspect your partner's MDN delivery receipt message, making sure that you can verify his/her signature using the public key on your partner's SSL certificate and that the cryptographic hash calculated from your partner's copy of your data file matches the same hash calculation from your original data file.
