Predicting problems with PKCS #11 as a Trust Store

[Nikos Mavrogiannopoulos]

On Fri, 2016-03-04 at 23:08 +0100, Rick van Rein wrote:
> Hello,
> 
> If I understand correctly, then one of the goals of p11-kit is to
> serve
> as a trust store.  That use surprised me a bit, because PKCS #11
> seems
> too constraining for that use-case, unlike alternatives like
> LDAP.  May
> I present my cautions, in the hope they are useful to you?
> 
>   * Useful about PKCS #11 is that it has well-defined storage formats
> for X.509 certificates, but that won't help much with other key
> infrastructures.  I defined a format for OpenPGP [1] but that isn't
> standardised, it isn't widely supported, and so you cannot rely on it
> being possible in general.  The same can be said about OpenSSH,
> DNSSEC, and so on. 

Is that a real problem though? If openpgp wants to be a consumer of
pkcs11 that's pretty easy to add, and for dnssec/openssh the public key
and private key formats stored would be sufficient wouldn't they?

btw. about standardizing the openpgp format for PKCS#11 have you
brought your proposal to PKCS#11 working group? The process is quite
open as far as I know.
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11


>  The only thing you could do for those is store the raw
> public key -- that is, if a suitable format exists; I had a lot of
> trouble squeezing SRP into PKCS #11 for example.

That's true but I don't think it is something prohibitive.

> May I suggest an alternative instead of PKCS #11?  Use LDAP.  It is
> just
> as capable of carrying X.509 certificates with annotations.  And I
> think
> it is a good idea [2] to have LDAP servers for structured data such
> as
> public keys under domain names anyway; this is something we are
> actively
> working towards [3].  Using SyncRepl, you can be updated virtually
> instantly.  And definitions for many public-key systems have been
> made
> already; OpenSSH and OpenPGP are both covered, and you could easily
> add
> your own if you wanted, without risking a conflict with other LDAP
> users, and without the need to go through a standardisation committee
> :)

There is a slight difference. LDAP is a network protocol rather than an
API, and for a trust store you would have to address the issue which
server to contact, and in the short run you could only implement it
using slapd... that sounds like too much for a trust store :)

Nevertheless, you could of course switch to something like that and
keep the PKCS#11 API (after all it's only an API), but still it sounds
much easier to extend the API to handle any missing use cases rather
than switch to a protocol which is very broad.

regards,
Nikos