[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: success with pkinit/opensc was (Re: Heimdal PKINIT complile errors)



Peter Duff wrote:

>To the fun part: I'm working on porting a pam_krb5 module to work with
>pkinit.  The main issue seems to be that, as far as I can tell,
>certificates can only be retrieved from on disk, rather than going
>through opensc to retrieve it.  Would it not make sense to change this
>so that the certificate is retrieved from the same slot_x-id_x field
>in as specified?
>
>  
>
Yes, it would. Unfortunately currently there's no way of doing it nicely 
and easily using openssl engines. You could use PKCS#11 API only for 
getting the certificate from the card but you would have to reload the 
PKCS#11 module and catch the CKR_CRYPTOKI_ALREADY_INITIALIZED error.
Another approach is to use PKCS#11 all the way.
Therefore, I have a question : Can we imagine to see the function 
pk_principal_from_X509 from kdc/pkinit.c move to lib/krb5/pkinit.c with 
a slighty different profile : pk_principal_from_X509(krb5_context 
context, X509 *client_cert, krb5_principal *principal), so that it could 
also be used on the client side to match certificate and principal?

Best regards,

Manu

>For example, a kinit it would go from looking like:
>
>% kinit -C ENGINE:CERT=/home/duff/tmp/duff2.pem,KEY=slot_0-id_45 duff@REALM
>
>to looking like:
>
>% kinit -C ENGINE:CERT=slot_0-id_45,KEY=slot_0-id_45 duff@REALM 
>(or something even simpler)
>
>Which would retrieve both key and certificate from the card, and
>simplify life for modules like pam.  Does this look right?  If it
>doesn't look too time consuming, I'm happy to come up with a patch.
>
>One final question - Does the KDC obey CRLs on the client's ssl certificate?  
>
>Thanks again.
>
>Peter.
>
>Ted Olsson <ted@polarcap.org> writes:
>
>
>  
>
>>>New errors. New solution?
>>>      
>>>
>
>
>You can get around that by changeing the 6 of uint16_t and uint32_t to
>"unsigned short" and unsigned long".
>
>I'm not sure how wise it was to pull in bittypes even though they are
>correct. It would be simple enough to use krb5-types.h, but in the
>generated files, can't make up my mind about this though.
>
>Love
>
>  
>