Transport Layer Security ( use of TLS in SSL or HTTPS etc ) is a clear prerequisite for B2B eCommerce irrespective of industry. Without TLS eCommerce partners would not be able to trust who they are doing business with. You seldom ( perhaps never ) get something for nothing, and there is quite a substantial overall cost incurred in having to achieve TLS. I realized just how much effort managing trusted material was when confronted with an expired certificate for my OpenSource project demonstration protobuf-rpc-pro. Furthermore in my job in enterprise application integration i’ve experienced many real problems associated with the (mis)management of trusted material. Here some thoughts about the cost for medium to large sized organizations.
- key generation and certification requests. This business function should only be performed by a security specialist, making the function expensive. Even if the cost of the certificate which verifies a public key is zero ( which it isn’t except for self signed certs ), this business function is expensive due to it’s specialization. There is an enormous amount of security knowledge required to use the tools ( openssl, keytool etc ), produce the right keys ( is 1024 bits ok or 2048?) and request the right kind of certification etc. Outsourcing of this business function is not advisable – considering this would equate to putting an organizations most trusted material into untrusted ( or not sufficiently trusted ) hands.
- protecting the secret key. Wherever a private key is created or stored, it leaves a digital fingerprint ( even after deleting on a hard drive etc). This key generation function should be centralized to limit the risk of unintentional key loss or poliferation, and imposing a policy of using keystore passwords to protect private keys. There is a cost to the organization in educating anyone who deals with secret key material, even if it is just to explain the internal security policies – like not emailing keys to the places that they’re needed.
- lifecycle management of trusted material. If a HTTPS certificate for a domain that you own expires, clients which rightly expect a valid certificate on connecting to your domain servers will no longer work. This puts a responsibility on the organization owning the domain to manage it’s certificates. Clearly when the number of certificates are large, this becomes a constant operational cost. The cost of replacing the trusted material ( keys & certificates ) on the webservers in a timely manner is only marginal. To run a cluster of webservers, requires a high degree of automation just to manage “routine” security patching and upgrades ( which should happen more frequently than key changes). A much higher cost is associated with informing partners about certificate changes which are likely to break their client’s current trust schemes. Clients’ trust doesn’t necessarily break, but it can be that new certification authorities are used which older clients do not trust, or new key lengths are introduced where older clients cannot use. In this case, if the partner management is not well managed, unlucky clients will only realize that something has changed when nothing is working and someone’s loosing money or customers. Knowing when clients will be affected by certificate changes is again a specialist function. Turning the perspective around, anywhere where your organization is a B2B client, you will need to manage constant certificate changes initiated by partners, and proactively realize which partners are obliged to replace certificates due to pending expiry.
Unfortunately use of TLS is not optional – not only for B2B commerce – but also within the borders of any organization, where the privacy and confidentiality of data transferred needs guaranteeing, and different parts of the organization ( employees / systems ) are trusted to different extents.