On Thu, May 8, 2008 at 3:27 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "Mark Phippard" <markphip_at_gmail.com> writes:
>>> I think this is a bad idea. The only reason to store a client cert in
>>> encrypted form is to prevent anybody who can get a filesystem
>>> dump/backup from using it. If you want to store the passphrase on disk,
>>> it's implicit that you don't care about that threat model - so just
>>> store the client cert on disk in unencrypted form, and you'll never have
>>> to enter a passphrase. (Yes, I think ssl-client-cert-password is a bad
>>> idea too, FWIW)
>> I think a certificate passphrase is not all that different from a
>> password provided to a basic response challenge. Given that every
>> Subversion command is a new session and a passphrase has to be entered
>> every time, people are going to want to cache them. And it does not
>> make sense to store these in plain-text when we have the ability to
>> encrypt them.
> If I understand him correctly, Joe is pointing out that the only purpose
> of this passphrase is to decrypt the cert -- so instead of storing the
> passphrase unencrypted, we might as well dispense with the passphrase
> entirely and just store the unencrypted cert itself.
> It is true that from the user's point of view, the passphrase is just
> another password. But the user-visible behavior would be the same
> whether the passphrase or the cert were stored unencrypted: namely, that
> the user wouldn't get prompted for the passphrase.
I must be missing something because I do not see how this is any
better. It would still rely on physical security otherwise someone
could just grab your unencrypted cert and use it to impersonate you.
I do not follow the logic for treating this different from any other
password. In the current code someone using client certs has to enter
a passphrase for every command. In a GUI like TortoiseSVN, if they
want to browse a repository they have to enter it everytime they
expand a folder. So now they want to cache the passphrase but have to
enter it in plaintext and rely on physical security to protect it. On
Windows and OSX we have a much better way to do this, and if any of
these branches work out maybe we will soon have it on Unix too. What
would be the reason to not want this feature?
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-08 23:20:08 CEST