It is indeed heavy, and I avoid it for both performance and payload size, and more importantly, because some implementations of SSL have vulnerabilities. Others may have. The generalisation of the protocol I use is well known -
A -> R: A, B
R -> A: {A,B,Kᴬᴮ,T}ᴷᴬᴿ,{A,B,Kᴬᴮ,T}ᴷᴮᴿ
A -> B: {A,B,Kᴬᴮ,T}ᴷᴮᴿ,{M}ᴷᴬᴮ
Where A = Alice, B = Bob, R = Robert, K = key, T = time stamp, M = message
A planning system that uses my store and forward implementation is used by a defence force, and went through some pretty thorough accreditation.
As for your willingness to farm this out to a third party - hey that's cool. It is, after all, a commodity service. Personally? I prefer to avoid dependencies on third parties where I can, because I'm not comfortable with the longer-term versioning dependencies, patch management and general operational support that's added over and above my code, which must already be supported.
A -> R: A, B
R -> A: {A,B,Kᴬᴮ,T}ᴷᴬᴿ,{A,B,Kᴬᴮ,T}ᴷᴮᴿ
A -> B: {A,B,Kᴬᴮ,T}ᴷᴮᴿ,{M}ᴷᴬᴮ
Where A = Alice, B = Bob, R = Robert, K = key, T = time stamp, M = message
A planning system that uses my store and forward implementation is used by a defence force, and went through some pretty thorough accreditation.
As for your willingness to farm this out to a third party - hey that's cool. It is, after all, a commodity service. Personally? I prefer to avoid dependencies on third parties where I can, because I'm not comfortable with the longer-term versioning dependencies, patch management and general operational support that's added over and above my code, which must already be supported.