Agility Loop

The Certificate Revocation List Distribution Point (CRLDP or CDP) is the attribute in a PKI certificate that tells a relying party where to retrieve the signed binary file that contains a list of revoked certificates (there are other reason codes that can be used, be most clients essentially still interpret those certificates as revoked).  This file is generated by the Certificate Authority (CA) on a regular basis.  This is one way that applications and systems can verify the revocation status of a certificate (there are other methods as well).

The challenge associated with CRLs, and the CRLDP for that matter, is getting those files down to each relying party.  This is mainly a problem is larger PKIs.  In smaller PKIs, the CRLs are small enough that clients and server shouldn’t have too much trouble downloading the files (although some CRL retrieval implementations are very brittle).  For larger PKIs, this becomes more and more of problem as the PKI grows.  The CRL files get larger, and since each CA issues a CRL and larger PKIs may have multiple CAs, there may be multiple files to contend with.  As your users use your PKI more, more relying parties have to verify those certificates.  The bandwidth demands can grow exponentially, stressing your infrastructure and potentially preventing some relying parties from actually retrieving the information.

Early on in PKI, LDAP was used for many CRLDPs.  However, LDAP is actually blocked at some firewalls.  In addition, as LDAP is an older protocol, it doesn’t offer you the same advantages as using a HTTP reference.  By using HTTP in the CRLDP, you can take full advantage of HTTP 1.1 enhancements like resumption and compression.

However, one must be cautious to not get too fancy on how they actually serve the CRL content.  Most PKI implementations on the relying party side are fairly simple.  There is typically no user interaction when retrieving the CRL…it happens in the background.

In my experience, it is best to take advantage of what web servers do best…serve static content.  It is tempting to make use of scripts or applets in serving CRLs.  One not make the reference a “dynamic” URL that includes the passing of a parameter to Java App?  That is certainly an option, but I truly believe that in PKI where you can make it simple, keep it simple. In addition, many web proxies will actually not be able to cache this content without manual intervention (although to be fair, many PKI implementations use http conventions like pragma: no cache to force the retrieval of the freshest CRL).

So instead of http://pki.company.com/crlscript?CA11, use http://pki.company.com/crls/CA11.crl.  Local users and networks can then easily replicate this directory through mirroring using standard scripts, FTP clients, and/ordownload managers.  By locally caching the content, the Infrastructure piece of your PKI will incur less bandwidth stress and you’ll have less headaches.

Saw a couple of posts throughout the Blackberry blogosphere in relation to a product called Cellcrypt that was presented at this past WES.  Cellcrypt enables users to make secure phone calls on their Blackberry.  The calls are encrypted using AES and the product is currently undergoing FIPS 140-2 certification.

I took a quick look at the tech overview on their website.  To oversimplify, Cellcrypt is essentially SSL for voice on a mobile platform.  When the client is installed, a key is generated for that phone so a key doesn’t have to be installed.  Although this is certainly convenient, I wonder if it is possible to import a key or even use a smart card?  This would make this an even better solution for enterprises like DoD who already have a robust PKI.

I can envision that if this works as advertised, that an enterprise could stand up the solution for their “important” mobile users.  It is not clear how the address book is managed, but as long as this is robust, why couldn’t a place like DoD roll this out for the enterprise and their DoD users?

Lastly, it is solutions like this that have to make you re-consider the viability of the SME-PED and other such custom secure devices.  Yes, the crypto on these devices is likely a bit more robust (and secret), but who is to say that a chip couldn’t be swapped in a commercial Blackberry to enable the higher level security?  Even more so, is a solution like Cellcrypt good enough for a lot of the transactions a govt agency uses?  SSL is relied on constantly.

Anyhow, love to see some more geeky details on this product.  Definitely has promise!

Just read a new Technet article detailing some of the new PKI features in Windows 7 and Windows 2008.  Some overall interesting stuff there, but what I really hadn’t seen before is support for HTTP Enrollment for PKI certificates.

One of the challenges of any PKI is re-enrollment of entities.  So, for example, a new laptop is provisioned and given to a user.  During provisioning, a device certificate is installed onto the machine (either via auto-enrollment or manually installed).  However, once that laptop leaves the IT department, the goal is to do as less “touch” as possible in the future.

In an environment where all of the machines are on the same domain and PKI is managed in-house, enrollment is a cinch.  However, more and more PKI is an out-sourced service.  PKI can be difficult (although to be honest sometimes that is over-emphasized).  If I can pay someone to manage it for me, it is probably more secure to let the experts actually manage it.  BUT, if it is outsourced, how do I allow my machine to get certificates?  In the MS PKI world, I may have to create a forest trust so that my machines can enroll and then re-enroll.

The addition of HTTP Enrollment allows enrollment requests to be performed over HTTP/S.  So, there is less of a need for forest relationships and more of an ability to out-source PKI.  It actually makes the Microsoft CA a much more attractive option.

All this being said, I expect that HTTP Enrollment will only work with Windows 7?  If that is the case, it will take some time for the impact of this new technology.

UPDATE: From doing some more digging, this capability will only work with Windows 7.  BUMMER.

I have been a Blackberry user for some time now.  On of the reasons that I first received a Blackberry was to start testing the security of the device.  Years ago, when DoD was first rolling out PKI, secure email (S/MIME) was the killer app.  Although it took some working with Microsoft and the other email vendors to get proper S/MIME support (don’t get me started about Lotus Notes though…still have nightmares on that one), we eventually got most of the kinks ironed out.  The next frontier we wanted to tackle was mobile devices, and Blackberry was a logical choice.  At first we started with just getting S/MIME support.  RIM actually was a ahead of the ball on this one and fairly quickly released a package for their devices (granted I think it was $150-200 at first…it is now a free download).

However, the device itself had some security holes that needed to be filled.  DoD has continued to test and verify the security of the Blackberry and has worked closely with RIM to release a Secure Technical Implementation Guide (STIG) for Blackberries and other devices.  The STIG walks administrators through the entire Blackberry meta-system to ensure security for the BES and the device itself.  A new version of the Blackberry STIG was released in Feb 2009 and applies to any enterprise using Blackberries, not just DoD.

I also ran across a GCN webcast entitled “Best Practices for Hardening your Agencys BlackBerry Wireless Platform“.  I haven’t actually watched it and it is probably trying to sell something, but probably worth a quick glance (and if you do watch it and it has value please comment on this post).

I do love it when wading through the Twitter chaff actually does yield something productive.  Thankfully, my saved search in TweetDeck led me to the Security Musings blog run by Gemini Security Solutions.

Besides feeling a bit of kinship to a blog that seems to really get PKI and security, they had an interesting post a couple of days ago about S/MIME support in Gmail.   It is a Firefox plug-in called Gmail S/MIME.  From reading the blog entry and the plug-in home page, it sounds like it essentually wraps your message in an attachment (which is basically what an S/MIME message is anyhow) and uploads to Gmail.

I gave it a test run by sending a message from Gmail to Outlook 2007 (only after an hour and a half of trying to fix Outlook…thx Gist plugin).  I get an underlying security message error in Outlook…odd.  That is usually related to trust or odd formatting of a message.  If I had some more time, I’d dig into the attachment.  Still a cool idea, and it has lots of promise.  One of the challenges of webmail (and mail on mobile devices) is signing and encrypting email.

But it is 4/16 after all…time to watch the boys finish OGBC!

Today in GCN, there is an article entitled Industry group gives government a failing grade in e-mail authentication — Government Computer News.  The main thrust of the article is detailing how most Government domains do not support any type of email domain authentication such as Sender ID or DomainKeys.

E-mail authentication technology, usually transparent to the end user, lets servers verify that e-mail traffic is indeed coming from the domain or sender that it purports to be from, and that the sender is authorized to use that domain. The OTA study showed that only 11 of 25 government domains examined use such authentication. A similar study of top commercial sites showed that the private sector is doing a little better, with 55 percent using some form of e-mail authentication.

To be fair, the private sector isn’t doing so great either at 55%.

What I find particularly ironic is that much of the government is ahead on PKI and other security technologies.  It seems like this would be a pretty easy solution to combat spam and phishing attacks.  I know in the past we have discuss using simple SMTP over SSL.  This would at least buy security of SMTP mail transfer, and authentication of domains (although it would be difficult to use with external email domains).  However, technology like DomainKeys (which Yahoo uses) is a more versatile solution than SMTP over SSL.  Hell it’s even open source, so costs COULD be minimal.