Hi, 2015年2月20日金曜日、NdK<ndk.cla...@gmail.com <javascript:_e(%7B%7D,'cvml','ndk.cla...@gmail.com');>>さんは書きました:
> Hello all. > > What I'd like to see addressed in future card > 6 - support for out-of-band authorization (HW) > For token type card, how about appending one more usb port to connect keyboard? It's just for inputing PIN/passphrase or out-of-bound auth by hitting the Enter key. USB ten keys like V7 KP0N1-7N0P Numeric keypad looks suitable for this purpose. Micro USB plug may be prefarable for compact board design. I don't like wireless features by two reasons. It may introduce complexity for middleware of the card. I like KISS. Another is break visibility to check HSM composition validness. For FST-01 spesific request, I ask gniibe to consider about case design with physical hole to tightly bind a token with keyring. Yuji 3 to 6 should be under a "policy" object connected to the main key to > make it public and let relying parties evaluate how much trust to give. > > Since smartcards have evolved (slowly...) and nowadays we have other > much-less-constrained alternatives (GnuK), I feel that many limitations > are just an heavy heritage that's becoming nonsensical. > > The reasons behind my list, point by point: > 1 - I'd like to roll the key used for reading mail every year, but > currently that would mean I'd have to use a new card every year or have > old keys on-disk, defeating the purpose of using a smartcard/token (from > my tests on actual smartcards, it's not hard to have room for 14 to 20 > keys on an 80k smartcard, more than 30 on a 144k one, WAY more are > possible on GnuK) > 2 - If I have to use my card to login on a possibly untrusted computer, > I don't want it to steal my PIN and sign/certify without me knowing it > 3 - Since NFC readers often have no pinpad (or could have easily been > tampered with) I don't want to expose my main PIN nor the same key I use > for "wired" auth > 4 - since HOTP changes at every use, it makes keyloggers nearly useless > and gives a third factor to the auth process (might be combined by > simple means -like digit-by-digit addition modulo 10- to the PIN) > 5 - I know, it's debatable and many see it as dangerous... but is it > more dangerous than keeping an on-disk (or on-paper) copy of the key? > Key export should be protected by a "certificate" (policy object defines > an "allowed KeyID for export" and the private key is exported only > encrypted to that KeyID); might even set a "fuse" to mark the fact that > the key have been exported > 6 - like in Yubikey NEO, a physical button to authorize some operations > can be useful (certification, signature, NFC PIN-less auth) > 7 - malaware currently can replace the hash of the object being signed > and the user can't know it till it's late... a small display could be > used to report some metadata (file name type and size for signature, > keyID and owner data for certification, peer ID for auth...) to give the > user more feedback > > What do you think? Complete BS or could something be considered for > inclusion? > > PS: 1 is the main reason I'm not yet using GPG much, even if I started > using it since DOS & FIDO-BBSs era... > > BYtE, > Diego. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users >
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
