Collecting ideas

Ideas to evaluate

1. Maintain protocol compatibility w/ OpenPGP card
2. Keep expired ENC keys on card
3. Allow for a different AUTH key for contactless mode (w/ its own PIN that might even be empty, but anyway should be different from the one used on the contact interface)
4. Allow safe-export keys to user-certified devices
5. add secure messaging
6. add virtual channels
7. support out of band user-consent when HW allows it
8. never hardcode limits (but check for HW-imposed ones): HW evolves!
9. Support for longer keys (RSA up to 4096bits, ECC p-521)
10. Report error counter after valid PIN (see comment by Thunderbird on January 6, 2012 11:24 AM on http://www.schneier.com/blog/archives/2012/01/improving_the_s.html )
11. implement HOTP (or even TOTP)

Everything that is an extension to OpenPGP Card protocol v2.0 must depend on policy defined at install time.

Test scenarios

• Key generation, signature, decryption and authentication operation via GnuPG
• Export of
• FIXME: any existing automated unit/integration tests available?

Misc

• Support for non-CRT implementation of RSA (even when imported key is in CRT format)
• What applet AID? Used 0xF9:0x4D:0x79:0x50:0x47:0x50:0x69:0x64:0x30:0x31 (F9 'MyPGPid01') for applet AID and 0xF9:0x4D:0x79:0x50:0x47:0x50:0x69:0x64:0x00:0x00 (F9 'MyPGPid' 00 00) for package AID

What can be used from existing projects?

• JOpenPGPCard project (http://sourceforge.net/projects/jopenpgpcard/)
• FIXME

Development process

• IDE (NetBeans?, others?)
• Management of development of features (discussion, issues, requests) - GitHub Issues
• Testing and integration: Jenkins - plugins Check style & FindBugs
• Tests
  • we should agree on test scenarios & acceptance tests
  • TDD with Jenkins would be nice
  • Jenkins connected on all master repos, test often
• Coding style
  • Jenkins - plugins Check style
• Code review
  • all developers will have their own github fork from main repo, pull requests to add new code into main repository

Emulation of extended APDU functionality

• would require an "incoming buffer" (to allow transferring chunks when extended APDUs are not available) and a temporary key object (for the test). That temporary key could be used in other parts of the code - a new key could be generated after every import. Once the import starts, no other commands should be accepted. End of import could simply be a zero-len PUT_DATA. Buffer should be lockable (since it's shareable between different functions). Better if its size is user-configurable at card init, with a reasonable minimum size (2k?).