david.daniel.smith at gmail.com
Sun Dec 30 13:30:45 EST 2007
Sunday 30 December 2007 10:02:35 に Ben Lindstrom さんは書きました:
> I'm sorry if this has been discussed in other places. Looking back at
> this thread I don't see any real discussion of it here.
It has been discussed in many threads on the list over the last few years.
Search for PKCS or the posts from Alon Bar-Lev and you should find them all.
> However, can someone give a run down as to why the current smartcard
> implement fails, why it cannot be fixed and thus must be replaced?
> It bothers me when people's solution is to throw out code because it
> doesn't do what they want without giving a solid reason why a new
> infrastructure is needed, or how this new setup will completely replace
> the existing setup.
Sure. To sum it up, currently OpenSSH uses OpenSC, which only provides support
for a limited number of smartcards. OpenSC is meant to be just another
PKCS#11 API implementation and if OpenSSH where to use PKCS#11 API instead of
OpenSC's specific API, it would be available to the wider world of
smartcards. Personally, I want to use it with opencryptoki, another free
PKCS#11 implementation, that supports the TPM chip in many workstations and
On top of this, Alon's patch adds new features: dynamic insertion and remove
of smartcards, session timeouts, and token removals.
> Just as bad is having two implementations living side-by-side and by the
> looks of the patch can both be compiled in. Does having both enabled
> have any ill effects? Should they both be allowed to be compiled in?
There aren't really any ill effects of having both in, but it is redundant.
OpenSC speaks PKCS#11 so using Alon's code one would still have support for
the same cards they're using now, and with his feature improvements it would
work better. I'm suggesting to have both of them compiled in and available to
ease the transition, but it's been stated on this thread that the PKCS#11
support should eventually completely replace the OpenSC support.
> As for X.509.. If one has followed this list for any period in time they
> will have seen the concerns about OpenSSL's X.509 parser complexity and
> the issues it has caused them in the past. That is part of the reason why
> djm@ and the other have no intention.
Let's leave the x509 issue for another day. The PKCS#11 patch doesn't
*require* x509 support, and I'm much more interested right now in having a
secure storage option for my SSH key then I am in having that key be
validated via my organization's PKI, as probably a few other people are.
> I remember discussions about writing a simplified X.509 parser that only
> looking at fields that OpenSSH cared about, but I've been away for over
> two years so I suspect that was abandoned. =)
Well, apparently the x509 support patch from Roumen Petrov is extremely full
so whenever that issue comes back around, it might be a good starting point.
Thanks for your feedback,
> On Fri, 28 Dec 2007, Alon Bar-Lev wrote:
> > Hello,
> > On 12/28/07, David Smith <david.daniel.smith at gmail.com> wrote:
> >> ping.
> > I also considered to ping... :)
> > Thanks for the reminder.
> >> is supported by an alternative pkcs#11 library, opencryptoki, and thus
> >> is unusable from applications that use opensc directly, because it's not
> >> a pkcs#15 card.
> > Also the patch introduces dynamic support for cryptographic hardware,
> > handling session timeouts, token removal etc..
> >> Alon's patch already functions parallel to the opensc support and RedHat
> >> is bundling it (or a similar patch, I'm not sure of the details). I
> >> would like this supported included mainline with all appropriate speed
> >> and importance.
> > Redhat developed nss based patch for OpenSSH, nss is much more
> > complicated and does not support all PKCS#11 tokens. The pkcs11-helper
> > based patch is much lighter and more compatible. Anyway, redhat will
> > face the same issues with OpenSSH regarding the dynamic hardware
> > usage.
> > If OpenSSH developers prefers to use Redhat's nss patch and this is
> > the way people be able to use more secured environment, it is fine.
> > I believe that my work is lighter and provide better service to users.
> > The main issue I am waiting for Peter to response is why he thinks
> > that the ssh-agent protocol should not be changed to support dynamic
> > environment. This is the main issue left, all the other are minor.
> > Currently, I execute a user prompt program directly from the agent,
> > while the other components of OpenSSH execute this from the main
> > executable. But I need a way to signal the caller that I need some
> > more information from the user.
> > Best Regards,
> > Alon Bar-Lev.
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
man perl | tail -6 | head -2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071230/dfb39a37/attachment-0001.bin
More information about the openssh-unix-dev