NIIBE Yutaka <gni...@fsij.org> wrote: > Well, I concluded that it is not worth (for me) to try to integrate U2F > feature into Gnuk.
While I am open to discussion, my current position is that it is better for Gnuk not to integrate the U2F feature. I'd rather prefer separate implementation of U2F, if needed, possibly reusing code of Gnuk (crypto, USB, etc.). I mean, by separate device. My reasons are: * The nature of two use case (OpenPGP private key vs. authentication for network service providers) are quite different. Generally, Gnuk users don't want to allow other new additional attack vectors, because of adding "new feature" (and U2F would come with them). OpenPGP private key is so important for Gnuk users. U2F key is just a thing to enter web service which is owned by a device vendor. For me, it is not wise to invite possible attacks just for some usefulness of not-so-important thing. * Resource on physical board is quite limited (20KB RAM and 128KB ROM). For code space, we will need some features of Gnuk if we integrate U2F or other features. * Unfortunately, currently, both of Gnuk and U2F uses same protocol of USB CCID. In a host system, it is the practice of CCID on host side to access the device exclusively to mitigate some attacks (changing while using). For example, GnuPG's scdaemon requires exclusive access to Gnuk Token. I think it is also same or similar to browser access to U2F device. I think that a single CCID device can't serve two different programs on host simultaneously. Well, we can manage and consider possible solutions for the latter two technical problems. The first problem is most important, I suppose. Keep adding things, it will become a system like host system, eventually. The purpose to separate out the management of OpenPGP private key to a dedicated device is: make it simple and easier to achieve better security. -- _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
