The PostalOne! web application implements a Public Key Infrastructure (PKI), where its application servers use certificate-based server authentication and establish at least 56-bit strong encryption with users. The authentication assures clients they are connecting with the PostalOne! Web site. Encrypted connections take place using https, that is, Secure Sockets Layer (SSL)-protected http.

PostalOne! uses VeriSign as the Certificate Authority (CA) for digital certificates on our servers. These certificates became effective with the 3.1.9 production release. The root certificate to establish the trust chain for VeriSign is already installed in most browsers.

Server-Based Secure Sessions

When a user connects to PostalOne! using the Internet, the PostalOne! server will establish a secure session with the user to begin the log on process. The PostalOne! server extends the SSL session to the user. After accepting the certificate from the PostalOne! server, establishing the secure session, the user may send their authenticating log on ID and password within that secure session.

• If PostalOne! cannot confirm the log on ID and password, the secure session will end.
• After a successful log on, the server-based secure session persists throughout the active session. The user may view data securely within the limits of their log on ID access control.
• Any time there are 15 minutes of inactivity, the PostalOne! session will automatically expire, logging the user out.
  

A user's signing certificate will not be required for client authentication. This follows the online banking model and meets ease-of-use considerations for both customer and postal clients.

Manual File Transfers

Within the SSL session, the user may initiate manual file uploads of Mail.dat files to the PostalOne! Java server using the PostalOne! Java applet in a separate secure https session. Because the user has already logged on through the web into a secure session, no further authentication is needed. The log on ID and password uniquely identify the PostalOne! customer and their access rights.

The PostalOne! PARTICIPANT AGREEMENT signed by the customer governs how information, such as Mail.dat files, is transmitted electronically to the Postal Service. In Section 1.5, Signature, the agreement states that:

Participant agrees that transmissions of files and documents to PostalOne! computer system(s), originating from its computer system(s) and identified as Participant's through the use of electronic signatures, digital certificates, passwords, or other means that USPS adopts to uniquely identify the Participant, shall be sufficient to verify that Participant originated the document and that the document is valid, accurate, and binding upon the Participant.

Barring any legal requirement, the "use of electronic signatures, digital certificates, passwords, or other means" is sufficient to establish that the participant originated the Mail.dat document during the secure session. This usage conforms to the practice that the document is sent in an encrypted session established through server-initiated SSL authenticated by user log on ID and password. Authentication ensures identity and origin; moreover, the Participant Agreement ensures non-repudiation, although not based on a client authentication certificate. Whereas there is no current necessity, if there were a legal requirement or other business need applied at a later date, the participant might need to obtain a user's signing certificate.

There will be no receipt process for file transfers in PostalOne!, since in the PARTICIPANT AGREEMENT Section 2.2, Verification, it states that:

Upon proper receipt of any document, the USPS shall make available the status of received document, and this shall constitute evidence that the document was properly received.

Participants may view the status of a mailing job in PostalOne!, where they may also view information and obtain reports within their secure session. Upon receipt of Mail.dat files, the target insert rate into the PostalOne! database is 240 MB in 20 minutes.

Authentication Required for Unattended File Transfers

Clients performing batch file transfers will need to obtain SSL certificates. PostalOne! provides a Java application for customers to download and install on their server that allows scheduling job transfers in off-peak hours and without human intervention. The customer server and the PostalOne! server establish mutual authentication and then conduct the transfers through the Java application. The batch file transfer customer is not logging on through the secure web site so their server needs its own SSL certificate to establish 2-way SSL.

Full batch file transfer customers must also download either the Java 2 SDK, Standard Edition, version 1.3, or the Java 2 Runtime Environment, Standard Edition, version 1.3, and install them on the server that will transfer the files. Both the software developer's toolkit and the runtime environment are available without charge from Sun Microsystems, Inc.

The full batch file transfer process in PostalOne! uses SSL version 3.0 to transfer files securely over the Internet, but outside the web application. SSL is a secure enhancement to the standard Transmission Control Protocol/Internet Protocol (TCP/IP) that uses a combination of cryptographic processes to authenticate the host computers and to encrypt and decrypt data transferred between them. This encryption provides assurance on the validity and ownership of the encrypted data.

To batch-transfer files securely with PostalOne!, participants must complete the following steps to permit SSL to operate on their host systems:

• Identify a technical point of contact and a business point of contact.
• Identify the server that will transfer the files with an IP address and a fully qualified domain name (FQDN). For example, "www.usps.com" is a FQDN: www is the host, usps is the second-level domain, and .com is the top-level domain. The FQDN must match the common name of the machine.
• Ensure that ports 443 and 444 are open in your firewall, for sending encrypted files.
• Download either the Java 2 SDK, Standard Edition, version 1.3 or the Java 2 Runtime Environment, Standard Edition, version 1.3 onto the server that will transfer the files. Both the software developer's toolkit and the runtime environment are available free of charge from Sun Microsystems, Inc.
• Create a Java keystore on the server using the Java functionality.
• Create a certificate signing request as a PKCS10 file following directions at VeriSign's Secure Site Services to obtain a Secure Site ID. We do not recommend using other Certificate Authorities due to potential difficulties in bridging certificate formats.
  • Verify the Distinguished Name information in your certificate with Dun & Bradstreet, or otherwise prove you have the legal right to do business in that name. Note: You may need to supply VeriSign with evidence of business and individual legitimacy along with your SSL certificate request.
  • Prove that you are the registered owner of your domain name.
  • Agree to the VeriSign Server ID Subscriber Agreement before completing your application.
• Obtain your certificate from VeriSign.
• Add the signed certificate you receive from VeriSign to your keystore to identify your machine when it contacts PostalOne!.
• Download Batch Processor from the PostalOne! Web site and install the application on your server. Add link We recommend testing the batch processor or automated method for sending files in cooperation with the PostalOne! Customer Care Center.

For more information about obtaining security certificates, please contact the PostalOne! Customer Care Center at 800-522-9085.

Future Plans

In the future, client authentication certificates may be required from permit holders using PostalOne!.

Appendix A — PostalOne! Encryption Certificates

The following steps are guidelines only. For detailed instructions, please contact the PostalOne! Customer Care Center at 800-522-9085 or postalone@email.usps.gov.

1. Create a Java Keystore – A keystore is a file that contains digitally signed certificates. The PostalOne! file transfer system uses these certificates to verify the name of your host computer before accepting files from it. To create a keystore, use the keytool utility that is a part of the Java 2 SDK, Standard Edition, version 1.3 or the Java 2 Runtime Environment, Standard Edition, version 1.3. You need the following information to create a keystore:

• The fully qualified domain name of your file transfer computer; the common name must match domain name.
• The name of your organizational unit
• The name of your organization; formal name must be alphanumeric characters, that is no characters such as @, !, or &.
• The city, state or province, and two character country code of your location. You must specify -keyalg rsa when creating a keystore for use with PostalOne!. PostalOne! uses the RSA signature algorithm for signing certificates.

  Please note your keystore password as you will need it in subsequent steps.

2. Create Certificate Requests – The VeriSign Certificate Authority must sign the certificate you created in your local keystore file. To obtain this digital signature, you must submit a certificate request to VeriSign. Use keytool to create your certificate request.

3. Obtain a Secure Site ID – Follow directions at VeriSign's Secure Site Services to obtain a Secure Site ID.

4. Add the Signed Certificate to a Keystore – After receiving a digitally signed certificate from VeriSign, you must add this signed certificate to your keystore. Use keytool to import your signed certificate into your keystore. This should be in the same directory where the unattended file transfer client will be installed. Once the certificate is successfully imported, SSL is enabled.

   Please note, you may also use keytool to verify that your signed certificate is in your keystore.