Damien Miller wrote:
> On Tue, 1 Nov 2005, Alon Bar-Lev wrote:
>
> I am busy at the moment, hopefully I will have time to look at it
> properly next week. Looking at it briefly, I was concerned about the
> assumption of X.509 support - we have no intention of including x.509 at
> present.
>
> -d
>


Thanks!
It is good to know that it is somewhere in the queue...

I want to explain why I think that X.509 is related to
smartcard support... And then I will wait until you have
some free time...

But first, I must say that I don't want to offend anyone...
and I am sorry if you already know that, or you think I am
talking none-sense.

I think your current approach is good for small systems or
individuals... But it does not scale. And worse When your
standard interface is raw keys on files, you create a false
sense of security, since you have a record of a security
product... And most people do not know better.

Let's say that the user knows that his key was stolen, now
he has to create a list of every system that trusted his
stolen key and remove the trust. During this phase, the user
will most likely forget a few systems, that left vulnerable.

Most users will not report that their key was stolen and
continue using it... The effort to update a new key in all
the systems is too big. So every remote system is left
vulnerable.

On enterprises, managing raw keys that are distributed all
over with people come and go is very difficult, people that
leave the enterprise will most likely be able to continue
using their keys afterwards for a long period.

But there is an advantage... The user can backup his keys...
So he can recover his keys from the last backup. So the user
never loses his keys and can access his remote systems and
modify their trust if he wishes by him-self.

Now... when user chooses to use smartcard, I assume he does
this because it is more secure... and not because it is a
neat device...

The environment should support this smartcard user.
Smartcard keys cannot be backed up... So if the user
lose/locks/damaged his card he also loses his keys. Since he
does not have his key, he cannot generate a new key and
modify the trust of remote systems by him-self... He need to
contact the administrator of each remote system and ask him
to update the trust, his situation is worse, since he has no
way to prove his identity to the administrators, because he
lost his keys...

Until all the administrators responses the remote systems
are vulnerable... But my claim is that there are few systems
that the user forgets...

Again... If the user uses smartcard because he want to
enhance security, the last requirement would be to revoke
his last identity from *ALL* remote systems. X.509 provides
this service.

Lastly, the user will most likely use his smartcard for
another purposes... Such as smartcard logon, email signing,
SSL authentication... All which are X.509... (Except of
gpg... where I had BIG failure...)

In order to summarize my argument:
1. X.509 is needed since smartcard user cannot backup his
keys, every change of smartcard result in remote system
update for *ALL* systems. The management overhead is huge.
When using X.509 the user enrolls a new certificate using a
different key, and then can access all remote systems
without any remote change.
2. X.509 is needed in order to revoke old identities, thus
not allowing ghost identities to exist on remote systems. It
completes the security requirements when moving from
software based storage to smartcards.
3. People who use PKCS#11 most likely uses it in X.509
environment and they wishes to use the same identities also
with openssh.

And on one sentence... If a user (on large scale) come to a
conclusion that he wishes to use secure environment, he most
likely use smartcard (PKCS#11) and X.509, drooping each will
result in a security weakness.

On small scale, most users will not bother to use
smartcards... and if they do... you can leave the opensc
interface for them...

After said that...
I can modify my implementation to not using X.509 from
openssh point of view, but I will still require X.509
certificate and private key on token... I will also issue a
patch for X.509 in order to use the certificate.

Regardless, I think that you should reconsider the X.509
support issue.

Just to make my-self clearer... I don't think that current
implementation of X.509 is complete... There are few issues
to solve... But I think that we can all take openssh one
step further, and adjust it for todays requirements.

Best Regards,
Alon Bar-Lev.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev