World's biggest PKI goes open source: DogTag is released
One of the frequently lamented complaints of PKI is that it simply didn't scale (IT talk for not delivering enough grunt to power a big user base), and there was no evidence to the contrary. Well, that's not quite true, there is one large-scale PKI on the planet:
Red Hat has teamed up with August Schell to run and support the U.S. Department of Defense’s (DoD) public key infrastructure (PKI). The DoD PKI is the world’s largest and most advanced PKI installation, supporting all military and civilian personnel throughout the DoD worldwide.
Red Hat Certificate Authority (CA) and Lightweight Directory Access Protocol (LDAP) are used to operate the DoD identity management infrastructure with August Schell providing hands-on support for the source-code-level implementation. The Red Hat Certificate System has issued more than 10 million digital credentials, many of which were issued immediately preceding conflicts in Iraq and Afghanistan.
It seems that its success or growth rode the wave of the recent Iraq military expedition (or war or whatever they call it these days). The reason for stressing the military context is that in such circumstances, things can be pushed out which would never evolve of their own pace in the government or private economy. This may make it a trendsetter, because it finally breached the barriers for the rest of the world. Or it may simply underline the reasons why it won't set any trends; only future history will tell us which it is.
Today's news is that the code behind the above PKI has just gone open source under the name of DogTag (a reference to the 2 metal identity tags that US servicemen and women wear around their necks). Bob Lord announces:
In December of 2004, Red Hat purchased several technologies and products from AOL. The most prominent of those products were the Directory Server and the Certificate System. Since then we opened the source code to the Directory Server (see http://directory.fedoraproject.org/ for all the details). However a number of factors kept the work to release the Certificate System on the back burner. That's about to change.
Today, I'm extremely happy to announce the release of the Certificate System source code to the world.
This isn't a “Lite” or demo version of the technology, but the entire source code repository, the one we use to build the Red Hat branded version of the product. It's the real deal.
Another barrier breached! This could change the map for small, boutique or startup CAs. For those who think that this will lead to an explosion of interest in crypto and CAs and PKIs, I cannot resist adding some thoughts from Frank Hecker, who commented:
It's ... the end of an era: When I was working at Netscape ten years ago we were dealing with patented crypto algorithms (RSA), classified crypto algorithms (FORTEZZA), proprietary crypto libraries (RSA BSafe) and crypto applications (Netscape Communicator, Netscape Enterprise Server, Netscape Certificate Management System), and crypto export control. All gone now, or at least gone for most practical purposes (e.g., export control).
Of course, now that people have all the open-source patent-free no-export-hassle crypto that they could possibly want, they're realizing that crypto in and of itself wasn't nearly the panacea they thought it was :-)
I cannot say it better!
Posted by iang at March 20, 2008 04:08 AM
post from yesterday in crypto mailing list
http://www.garlic.com/~lynn/aadsm28.htm#47 delegating SSL certificates
the claim has been that the business model is bigger issue than the technical issues. PKI process is the digital certificates which are the letters of credit/introduction from the sailing ship days ... where the relying party has no other recourse to information regarding first time interaction with total stranger. it was created for the offline email scenario from the early 80s, where somebody dialups the electronic postoffice, exchange email, and hang up. then the recipient has to deal with first time email from complete stranger.
with any sort of information about the party being dealt with and/or timely direct access to authoritative agency about a complete stranger ... then the digital certificates are redundant, superfluous and obsolete.
a 2nd issue with the business model was that going into the mid-90s, it was realized that the earlier x.509 identity certificates (increasingly overloaded with personal information) represented significant liability and privacy issues. as a result there was a lot of retrenchment to relying-party-only certificates containing nothing but some sort of record locator. However it was trivially shown that if the record has to be accessed ... then the digital certificate was (again) redundant and superfluous (or as in other posts can be trivially compressed to zero bytes).
another issue specifically with the 3rd party PKI business model was traditionally a relying party has some sort of contractual relationship with the authoritative agency (say when they are doing background check with credit agency). In the 3rd party PKI business model, there is a relationship between the certification authority and the entity that the certificate has been issued for ... but no contractual relationship between the certification authority and the relying parties (effectively negating traditional business processes). In order for the gov. PKI project to address this short coming ... GSA signed contracts (as representative of gov. relying parties) with all the authorized gov. certification authorities ... creating contractual obligation between the relying parties (i.e. entities that needed to relying on the validity of the digital certificates) and the (PKI) certification authorities.
misc. past posts mentioning gov. pki project and gsa (as representative of gov. relying parties) requiring contractual relationship with all authorized certification authorities
http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
http://www.garlic.com/~lynn/aadsm15.htm#8 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
http://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
http://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
http://www.garlic.com/~lynn/aadsm26.htm#34 Failure of PKI in messaging
http://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)