This chapter explains technological and procedural choices, which have been tested when developing the eAIP Security guidelines. See also the eAIP Security Risks and Mitigation Strategies in the eAIP Specification.
Signing can be a lengthy process: an eAIP can be composed of more than 100 files, including charts. Depending on the software and procedure used, the signing party might have to enter his password for each file to sign. On slower hardware, signing a large number of file can also be long, depending on the algorithms chosen.
The other possible areas to cover could be:
Confidentiality: making sure unwanted third parties cannot obtain the information;
Availability: guarantee that the end-user has access to the information, all the time;
Non-repudiation: making sure the end-user cannot reject having received the information.
The content of an eAIP is public information and as such we have not looked into methods for ensuring confidentiality. However, the publishing party can set up encrypted channels to distribute the eAIP, e.g. using an SSL-enabled website (with two way SSL) or using encrypted email.
As the eAIP Security guidelines are independent of the ways the eAIP is distributed, it is outside the scope of these documents to specify availability requirements regarding these distribution channels. It is up to the publisher and the end-user to agree on availability.
Non-repudiation is the ability to guarantee that a person has sent a message and that the receiving party has indeed received it. This is done typically by a trusted third party, which holds arbitration powers.
The current paper AIP distribution does not have a non-repudiation mechanism. Therefore, it was not included in the scope of the eAIP Specification.
x509, the ITU standard for public key cryptography, is widely used in PKI, in SSL and other security-related protocols. By its widespread use, it is natural to adopt this standard for eAIP security.
PGP, a public key system devised by Phill Zimmerman, is also used extensively to secure communications via email, instant messenger, etc. Its ease of use and decentralised management make it ideal for small organisations and tight IT budgets. Therefore, these two methods have been chosen, as they could ease the adoption and implementation of eAIP signature mechanisms.
Choosing between x509 and PGP is a choice which has to be carefully taken. Here are a few elements to help deciding:
Existing or planned use of x509: If your organisation already has x509 PKI deployed and has management procedures in place, then it is trivial to integrate the signing of eAIP into it. In case you are planning a x509 PKI roll-out, you could use the eAIP signing as a test case. You can also use the x509 tutorial to get acquainted with x509 concepts before plunging in to PKI.
Limited security budget: creating and managing an x509 PKI is costly, both on the software and personnel. PGP is significantly less costly and simple to set up.
Plan for organisational-wide security: If your organisation does not plan to roll out PKI, PGP is a good choice as it is decentralised by nature. Indeed, any individual or organisational unit may create a PGP key. On the other hand, x509 requires central administration of a CA, and security procedures for signing and certifying requests. This fits well in the centralised security model used by many enterprises.
Simple test of eAIP security: To simply test the signature of the eAIP, we recommend you use PGP, as it is easier to set up. Use x509 if you are interested in this technology and are planning a PKI roll-out, or if you already have a PKI.
The XML Signature is a W3C recommendation defining the integration of digital signatures within XML documents. Using this recommendation, it is possible to sign a complete document or some fragments of it, to embed the signatures inside the XML document (as well as outside, like X.509 and PGP).
Signing a fragment of a document allows several authors to separately sign their part of the same document. It would therefore be possible for each editor to sign individually his/her work (including charts, and modifications linked to amendments).
Since the eAIP is seen from the user's standpoint as being a single publication coming from the official publishing organisation, we have concluded that signing parts of a document is not an eAIP security requirement.
SSL Certificates HOWTO; Franck Martin
The Great List - SSL - Encryption; Caribe WWW Research
Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks; International Telecommunication Union
An Introduction to XML Digital Signatures; Ed Simon, Paul Madsen, Carlisle Adams
Gnu Privacy Guard (GnuPG) Mini Howto; Brenno J.S.A.A.F. de Winter, Michael Fischer v. Mollard, Arjen Baart
Corporate use of PGP & Key Management/recovery; Laszlo Baranyi