For RKL, the XFS standard defines a "scheme using certificates" and a "scheme using signatures", and the industry has taken-up this jargon. Please allow me to dispel this misnomer. The differences between the so-called certificate and signature schemes are just formatting and organisation, and they're fundamentally the same. Both methods follow the same sequence of events, both use certificates, both use signatures, and I would discourage any further use of this inaccurate terminology.
But first, some boring definitions of terms:
• Remote key loading (RKL) is the secure delivery of master keys from a host to a terminal across a public network.
• Extensions for Financial Services (XFS) is a specification of an interface between application software and terminal hardware, providing platform independence.
In XFS's "signature" scheme, the terminal and the host send each other their public keys and their public keys' signatures. But that is precisely a certificate exchange – a certificate is little more than a public key and its signature. XFS invented the term "signature issuer" instead of using the conventional term "certificate authority", but a rose by any other name would smell as sweet, i.e. a certificate by any other name would equally authenticate a public key.
Meanwhile, in XFS's "certificate" scheme, when the terminal and the host send sensitive data, they authenticate the transmission by attaching the encryption of the data under their private key – signatures!
Both use certificates, both use signatures.
While we're discussing XFS's RKL, may I take the opportunity to note just how awful the "signature" scheme is. This scheme uses a certificate format which I believe was initially designed as a colorful montage of crayon and finger-paint by a grade school girl as an art project, and the world would be a better place had it remained under her doting mother's fridge magnet. While it is admirable for a little league team to embrace and include the very weakest players, I am unconvinced that such non-judgmental inclusiveness is appropriate for a standards body.
The "certificate" scheme, on the other hand, uses the same regular standards as are used on the internet and in most modern cryptographic systems, such as X.509 certificates. These are the very standards that are employed by protocols such as S/MIME for secure email or SSL for secure web browsing. For example, when I personally am providing technical support for RKL systems which use the "certificate" scheme, on my PC I can just double click on an ATM's or a host's certificate file and that certificate is opened using the viewer utility that is included with Windows and which is used from Internet Explorer when you view a website's certificate. And by using industry standards, various services, such as the certificate authority, may be outsourced to companies whose primary focus is the internet.
I hereby propose that the "certificate" and "signature" schemes be renamed to "scheme using regular industry standards" and "scheme using weird proprietary techniques which are so removed from modern PKI that you'd laugh if you weren't the unfortunate programmer assigned with their implementation", respectively.
Naturally one wonders why XFS included this atrocious "signature" scheme. I don't know what transpired in producing the XFS standards, but it is easy to imagine two major ATM manufacturers both insisting that their own pre-existing scheme be adopted as the standard, and the compromise being to include them both.
The XFS document may be found at
ftp://ftp.cen.eu/PUBLIC/CWAs/other/WS-XFS/CWA16374/CWA16374-6-2011_December.pdf
See sections 5.3-4 and 8.1-2.
Signed and/or certified,
Henry