Re: Splitting lib/krb5/pkinit.c

["Douglas E. Engert" <deengert@anl.gov>]

Looking around some more, I see that OpenSC has a libp11 that is
designed to be used by an application to load, and access pkcs11.so
It might be a better approach the the use of the engine directly.
There is a lot of e-mail on the OpenSC mailing list on this lately.


Geoff Elgey wrote:

> 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
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444