Encryption - automatic key renewal

When doing message level encryption, the public key of the recipient is used to encrypt the source message. But how to obtain the encryption key of the recipient? Is there some directory (X500?) containing all these keys? Nope. Encryption keys are usually exchanged via out-of-band mechanisms.

For message level signing, things are much easier: a sender attaches its certificate to the signed message. The receiver checks the certificate first and next uses the public key contained in the certificate to verify the signatures. If the sender switches to a new private key, a new certificate containing the new public key is sent along with each message.

But what if a receiver wants to switch to a new encryption key? How to inform all senders that they should start using a new encryption key? What I've seen happening is that a company informs its business partners that they should all switch to this new key at exactly the same date and time. Clumsy solution. This could easily be avoided if ESB's and B2B tools supported the use of both the old and new encryption key for a while (try to decrypt with the new key, next try to decrypt with the old key). But products don't support this simple feature.

Note: switching to new encryption key is typical when the same keys are used for signing and encryption; the certificate needs to be renewed and this often implies a new keypair and thus new encryption key.

EDIINT/AS2 is a popular protocol for B2B communication. AS2 uses message level security extensively, both for signing and encryption. So AS2 uses are confronted with this challenge of key renewal. Now AS2 has an optional profile called "Certificate Exchange Messaging" that allows the automated exchange of new encryption keys! And it requires the parallel use of an old and new key.

This optional CEM profile exists already for a while but support is still limited: Axway, Cleo Communications Inc. GXS,Inc., Inovis, and SEEBURGER.

Microsoft DCS & BitzTalk adapter pack

Just as the BizTalk services evolved into Azure cloud offering, Microsoft seems to be brewing something else as well. As part of their Customer Care Framework, Microsoft delivers the Distributed Connectivity Services (DCS). This underlying layer seems pretty fundamental. If I understand well, (web) services are discovered and invoked dynamically. No UDDI , but WS-MetaDataExchange. Don't have the full picture yet, but looks very interesting...

Something else I learned on the Microsoft side is the BizTalk adapter pack. The new BizTalk adapters are WCF enabled and can be invoked as WCF services. So from a .Net program perspective, everything looks like standard services. Makes me think a bit of WSIF in the Java/open-source world. Biztalk adapters will gradually migrate to this new architecture. This allows these adapters to be used both with and without the BizTalk server.