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

[Peter Duff <duffpl@gmail.com>]

I'd like to share with the group some success with heimdal
pkinit/opensc, in case, like me, there are disheartened souls out
there.

I've gotten pkinit support from the 20050113 snapshot working with
private keys being obtained from a pcsc/lite controlled smartcard.  So
far it all seems to work nicely, and is stable!  Thanks for the code,
it is truly amazing that this level of work gets given to the open
source community.

The main issues I had to get around are:
+ use openssl-0.9.7e - I was previously using an older version, which
core dumped at some point during the opensc engine calls.
+ I used the opensc-20050114 snapshot
+ compiling this snapshot w/openssl 0.9.7e requires an openssl patch (off topic)
+ realizing that  opensc creates/imports x509 rsa keys as _sign only_
by default (at least in my setup).  You need to use the "--key-usage
sign,encrypt" option of opensc's pkcs15-init  (because with pkinit you
need to decrypt the KDC challenge with your rsa key, so signing is not
enough).  I also needed the --split-key option with my usb token, but
it doesn't affect it working or not, which made me happy.
+ the kdc server certificate must be an ssl server certificate.  user
certificates must be ssl client certificates.  Both should be signed
by your CA.  Being a novice ssl and pkinit user, this wasn't obvious
to me.

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?

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