ECDH is turned used when using ECDSA, so also its also used when using EC certificates on the client. There is missing negotiation of EC curves, so the code is not future safe, but its something that we’ll add in the future.  Part of the regression test now uses the EC certificate. hxtool needs support for generating EC keys and exporting the SubjectPublicKeyInfo before its can sign certificates, neither of them too hard.

Too much of the OpenSSL EC implementation is hidden, so right now its not possible to load plugins. So no support for PKCS11 or Keychain based private keys.

hxtool can now both read and create PEM and PKCS11 files containing both certificates and private keys. Neither of formats will end up containing encrypted keys (ie shrouded PKCS8 keys), so that is a feature that must be added.

And talking about private keys, hcrypto now uses RSA key blinding and CRT for private key operations, makes quite a lot difference in performance and security. I also added RSA key generation, that is really the last two missing bits that makes hcrypto useful.

The coolest feature is also the most basic in the X.509 world. libhx509 and hxtool now can print certificates. It would be boastful to call is a CA software because some important tools are not there yet, for example a CRL and OSCP generation tools and certificate store handling.

There is two reason why I wrote this extension to hx509. First reason was I wanted a simple way to setup a PK-INIT realm and using OpenSSL as a CA only causes pain for most users, its very hard to get the generated certificates right and openssl lets you get away with it too. Second reason is that I needed a simple way to generate certificates for another part of Heimdal, kca (more about that later).

What hxtool do for us then ? It will let you issue certificates with a simple interface using default templates.

To generate a CA certifiate with RSA key that is valid for 10 years, this is the command you would use.

hxtool issue-certificate \
    –self-signed \
    –issue-ca \
    –generate-key=rsa \
    –subject=”CN=CA,DC=h5l,DC=se” \
    –lifetime=10years \
    –certificate=”FILE:ca.pem”

Now you have a CA certificate with its private key in the PEM file ca.pem. Now you say, what makes this hx509 so much simpler to use then OpenSSL. The answer is the default values and builtin profiles, let take the example with the KDC PK-INIT certificate. It needs to have this EKU (extended key usage) and a special SAN (Subject Alternative Name) for PK-INIT. hxtool will help you generate that certificate with some simple command options, it wont give you total control over the certificate creation process, but for most users that is not really interesting, they just want to have certificates.

hxtool issue-certificate \
    –ca-certificate=FILE:ca.pem \
    –generate-key=rsa \
    –type=”pkinit-kdc” \
    –pk-init-principal=”krbtgt/H5L.SE@H5L.SE” \
    –subject=”uid=kdc,DC=h5l,DC=se” \
    –certificate=”FILE:kdc.pem”

Writing a certificate issuing code when you have a X509 verifier, a crypto library and a sane ASN.1 compiler is very simple. It took me about 3 days from no code to a somewhat working software, now, 12 days later while also working with other thing, its good enough to tell people about it.

Next item will be to write a sane manual how to use this software. Since hxtool is such a small tool the manual will be short too, it will be another texinfo manual about how to use hxtool to serve your basic CA needs. Creating a CA and issueing certificates to user and services.

There will always be missing functionallity to hx509, the PKIX people have started to write standard too long ago for me to catch up.

The other part of PK-INIT is the hx509 library that I’ve been tweeking on last last year or so when I have had time. On it there is two major issues left. First there must be error string generated. There is currect two error codes, but that doesn’t help you if you get the “signature incorrect” error-code. What signature, on the CMS SignedData message, the signing certificate, or maybe some certificates in the chain. The second issue is that there is no policy mappings yet, that that is a major flaw when verifying chains that go though bridge-ca’s. I find the policy mappings to be badly written in the PKIX (rfc3280), its spread out over then whole document and no clear view how to implement it, or even how to use it!

Anyway, the last week I add proxy certificate support to hx509, so now Heimdal can use proxy certificates generated by the grid folks again.

I’ve also written more tests for the Heimdal regression suite. Both for the hx509 library and Heimdal as a system. Now as part of “make check” a kerberos database is created, kdc started, kinit run (both using Encrypted Timestamp pre-authentication and PK-INIT) and , as a client is authenticated (testing both mutual authentication and not) to a application server using krb5_mk_req API (ap-req/ap-rep).

Of the latest changes I like the the credential cache iteration code the
most. It allows the user to list all caches available. It only works
for API and MEMORY caches though, some day there will be support for
KCM and FILE caches.

$ klist --list-caches
Principal      Cache name     Status
lha@SU.SE        0              Valid
lha@E.KTH.SE     1              Valid

This glued together with support in GSS-API’s gss_aquire_cred
allow applications to select the source principal is a bliss. I’ve
modified push (the pop-client included in Heimdal) to use SASL and
now I can tell is to use lha@KTH.SE when talking to
mail1.kth.se even though the current selected cache is
lha@SU.SE. No more kswitch (MIT application for API credential
cache) or using wrapper shellscripts setting the KRB5CCNAME
enviroment variable. It makes my life much easier, no more wondering
why I’ve not received any mail for whole day just because I selected
the wrong credential at the begining of the day.

The outstanding question is how to handle support for automatic
selection of credentials. What parameters can you accept from the
server ? How should you store the local configuration ? How should the
user influence the selection ? How to avoid privacy issues (avoid
doing TGS-REQ to KDC that you don’t want to expose your actions too) ?
These are all very interesting issues, but causes a lot of squishy
noise when you hits your head agaist the wall.

I’ve also cleaned up DH support in PK-INIT, now it will check the
parameters choosen by the client, and there is a moduli files that
allows the administrator to add new group parameters. I also wrote a
fix for the PK-INIT-09 windows problem with binding the answer to the
request as presented by
href=”http://www.cis.upenn.edu/~scedrov/”>Andrew Scedrow et al at
IETF63 in Paris. The fix from Microsoft can be found
href=”http://www.microsoft.com/technet/security/bulletin/MS05-042.mspx”>
here.

Now there is only parts of the KDC certificate verification code
missing and documentation on how to use PK-INIT that is missing before
I’m happy enough to make a release including PK-INIT. There are of
course major issues left, like PAM support, certificate handling and
CMS support, but those can be cleaned up later. There is of course the
rewrite of the ASN.1 compiler, but that seems to be the default state
of ASN.1 compilers so I’m not too worried about that.

Technorati tag: Heimdal

It diffrent from the other common free implementation (read OpenSSL) because it centers around the certificate instead of the public/private keys.

Right now it have support for PKCS12, PEM, DER certificate stores, I’ll soon add PKCS11 support.

The CMS interface is somewhat raw, but produces and decodes/verifies SignedData and EnvelopedData. Talking about the interface, I’ll update the API for sure, there needs to be a context variable to pass back errors to the user, com_err might be good, but its not that good.

The reason I started this work is that I found the choices I had to use CMS in PK-INIT was bad and very strange to use. They also didn’t support the operations I need to do, for example search certificates for diffrent critera, use random oids as content types in CMS messages or interface with PKCS11 in a sane way.

Adding PKCS11 support is going to be the intresting part, then I’ll see how much of the API I made up really works with keys that are hiddes inside other devices.

A choice I have to make is what crypto libary I want to support, one way to do it is to use PKCS11 for everything, this way the X.509 and CMS libary will be independent of the crypto support, and the user can choose what crypto provider to use.

The real work is of course adding more tests, its really great to have a large regression testsuite, makes you feel warm inside. Right now there is a small one, but it needs improvements (and for me to commit it).

Technorati tag: Heimdal