G'day,
> Yes it is complex, and may be overkill. But rather then using the
> engine, I would like to see PKCS11 used instead. The main use of
> PKINIT will be with smart cards, and smart cards come with a
> PKCS11. Browsers and other applications already know how to use
> PKCS11, and smartcard vendors provide PKCS11 libs. If you look
> close at the examples the engine code is loading and calling PKCS11.
In fact I am also using PKCS#11, which is why I wanted to avoid creating an openssl engine. Personally, I would prefer to use the PKCS#11 API in PKINIT rather than openssl, as you suggest.
However, I assumed in my proposal that openssl API was used in PKINIT for non-PKCS#11 use cases (such as loading keys and certificates from files). Also, the verification of the server's certificate required additional non-PKCS#11 information (such as the location of the trusted certificates directory). These two considerations lead me to a non-PKCS#11 API (although I am glad to change this).
>> Examination of the PKINIT code reveals that the following
>> information is required from the user:
>>
>> * the user's private key
>
> Not really the private key, but access to the signing function that
> can use the key. With a smartcard, the key never leaves the card.
True. I did think about proposing a "sign" and "verify" abstraction (as per the PKCS#11 API). However, my aim was to keep as much of the original API used in Heimdal PKINIT as possible, which meant using the openssl EVP_PKEY type. I wrote some code that creates an EVP_PKEY which delegates to PKCS#11. Of course, using PKCS#11 in the first place would have been simpler.
re: obtaining trusted certificates
> This is the standard OpenSSL way of handling trust certificates.
> Since they need to be trusted by the local system there may be
> security risks in fetching them from a URL.
True. However, the point is to provide an alternative, if required.
re: creating a krb5_pki_identity implementation
> No don't put this burden on the applicaiton. Using PKCS11 makes
> a lot more sense. It depends on what is in your krb5_pki_identity.
> If its a pointer to the pkcs11 lib to use, then OK.
My krb5_pki_identity implementation does use PCKS#11 (although it then creates openssl EVP_PKEY and X509 types delegating to the PKCS#11 instance).
> If the engine to pkcs11 code was removed, and replaced with
> pkcs11 calls from PKINIT then that would simplify and standardize
> the interface.
I agree. The use of PKCS#11 calls only in the Heimdal PKINIT implementation has my full support. However, if an openssl interface is required, then a PKCS#11-to-openssl implementation of krb5_pki_identity may be provided.
-- Geoff