-
Notifications
You must be signed in to change notification settings - Fork 4
Collecting ideas
NdK edited this page Jun 12, 2013
·
11 revisions
- Maintain protocol compatibility w/ OpenPGP card
- Keep expired ENC keys on card
- 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)
- Allow safe-export keys to user-certified devices
- add secure messaging
- add virtual channels
- support out of band user-consent when HW allows it
- never hardcode limits (but check for HW-imposed ones): HW evolves!
- Support for longer keys (RSA up to 4096bits, ECC p-521)
- 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 )
- implement HOTP (or even TOTP)
- take some ideas from Google's https://sites.google.com/site/oauthgoog/gnubby (like anonymous RFID auth and unlimited key store (key gets loaded in encrypted form when needed -- the card only keeps a long-term secret to decode the private key)
Everything that is an extension to OpenPGP Card protocol v2.0 must depend on policy defined at install time.
- Key generation, signature, decryption and authentication operation via GnuPG
- Export of keys towards a certified device
- FIXME: any existing automated unit/integration tests available?
- 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
- JOpenPGPCard project (http://sourceforge.net/projects/jopenpgpcard/)
- FIXME
- IDE (NetBeans?, others?)
- Management of development of features (discussion, issues, requests) - GitHub Issues & Huboard
- 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
- 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?).