On Mon, Feb 23, 2015 at 8:10 AM, David Woodhouse <dw...@infradead.org> wrote:
> On Mon, 2015-02-23 at 13:59 +0100, Arne Schwabe wrote:
>>
>> All fine. My rationale was like, if I want a certificate with a certain
>> SUBJECT (e.g. CN=schw...@mycoolca.com) etc. it should not matter for men
>> wether I get it from OS X, Windows or Android Certificate store.
>
> The canonical way of representing that would be
> pkcs11:object=schw...@mycoolca.com
That representation loses the "CN=" (and maybe doesn't allow for
additional search options -- I'm not sure).
OpenVPN already has an entire set of options that deal with PKCS-11.
This patch is a completely different, parallel way of dealing with
certificates, so I'm not sure why a "pkcs11:" scheme is needed. I
probably would not implement it in Tunnelblick myself.
There are two things here: (A) what this "select" string is and (B)
where/how to find the cert.
As to "what this 'select' string is" -- well, for "future-proofing", I
would want it to be labeled as a selection string in case we want to
pass something else at some time in the future.
Adding a scheme makes sense to me -- the "file:" scheme looks
interesting, but it isn't part of this patch. But I think the scheme
should be optional, so the configuration could include (the
platform-independent):
--management-external-keychain select:CN=schw...@mycoolca.com
and have it use the Keychain on OS X, Android Certificate Store on
Android, something-I-don't-know on Windows, etc.
The tricky aspect of that is that the default would really depend on
the management interface software, which really means it depends on
the GUI. It is conceivable that two GUIs for the same platform could
have different defaults (although I assume both Tunnelblick and
Viscosity would use Keychain as the default, accessing it with
keychain-mcd).
