Abstract
In Sweden, an Electronic Identification card has recently become is a formal Swedish standard. Thus there is a need for a program that can use the card for digital signatures and encryption. Modifying the existing PGP has major advantages instead of recreate the wheel and start from scratch. This idea has been floating around for years, but since nothing has happened, it is now written down for a broader audience, in the hope that someone will catch it and do it.

Why PGP?
- It is well-known and well-repudiated, and has become a de facto standard on Internet. (the first version is dated back to 1991) PGP is distributed world wide, by Network Associates global network of distributors.
- More formally, IETF has adopted the Open PGP and PGP/Mime as standard drafts. (add links to this)
- We can use an existing infra structure which are recognised globally, since PGP has announced to support the X509 certificate type together with the market leaders in the field, Verisign and Entrust.
- PGP has already plugin's for popular email programs such as Microsoft Outlook, Microsoft Express, Exchange, Eudora, Claris (for Mac users) etc. This makes it suitable for legally binding documents sent by email.
- Its public source code fulfils security criteria # 1; the ability to perform a quality control. This implies that the program part that glues the smart card to PGP must also be publicly available.
- With PGP, the current risk for non-compatible solutions from different implementers is reduced.
- Its by far cheaper to modify PGP then creating a self made solution for digital signatures & encryption.

Selecting a smart card standard.
The choice of standard depends on which market niche the implementers chose to aim at. Naturally, the implementor could chose to support several standards in order to widen the potential market.

By choosing a legally recognised smart card, it is possible to immediately reach the market that needs legally binding documents. Such as the Swedish Electronic IDentification card. There is work going on to also make it a PKCS standard, (add link to SEIS work in this field, and to existing PKCS standards) and thus it would become internationally recognised. Germany and some states in US, with their digital signature laws are other obvious markets. The history indicates that the acceptance for smart card is bigger in Europe than in US.

Roomers have that Microsoft is about to release a smart card called "Windows card". More details are hopefully on Microsoft's web. This could also be an interesting alternative to consider. Or perhaps Java based smart cards.

Free or commercial usage?
PGP exists both as a freeware version for non commercial use, and a commercial version. It is the implementers choice to aim at the freeware and/or the commercial PGP version. For an example, if a university creates the source code, they might not have the incentive to support a commercial PGP version. While a company might want to support only the commercial version. Once the basic source code exists, it does just require minor modifications to support both versions.

Technical details.
If the program can not find a valid smart card, then the user should have the ability to use the soft keys that PGP normally uses. This gives the highest flexibility. There could for example be a need to send email, with soft keys instead of the smart card. It also allows the user to go back to soft keys in case he would loose his smart card.

To ease the examination of the source code, it is suggested to be distributed as a separate piece of source code that is mixed into PGP’s original code at compilation time.

Do not use MD5 as a hash algorithm. PGP supports both SHA or RIPEMD that can be used instead. MD5 is no longer recommended for new implementations. (add the exact location in www.rsa.com where more technical details exists.)