How to Deliver E-Certificates Securely for Sender & Recipient

How to Deliver E-Certificates Securely for Sender & Recipient

December 03, 2010 / in Registered Email™ / by Zafar Khan, RPost CEO

There is set of RPost services that when combined, provide for an elegant and secure way of transmitting electronic insurance certificates, electronic titles (real estate, land, auto titles), permits, regulator issued licenses, and university transcripts while ensuring:

a. Proof of content and time received by recipient.

b. Proof of encrypted or private transmission to prevent exposure of sensitive data on the certificates.

c. Revocation of validity rights by sender, even after the certificate is passed along to others by email.

d. Verification of validity power for any recipient who may shown the certificate and would like to ensure fees have been paid, there have been no liens applied, etc.

Using RPost services, one would turn on three features (this can be done automated if batch sending or ad-hoc by sender in Outlook, Lotus, or Online App) as noted below and simply send the certificate in the body of the email as body text or attached as a doc, image, or PDF.

Know more:

Email Encryption Service

Secure Email Services

a. Send Registered: Provides proof of content and time of receipt for sender – in this context, proof that the transmission was encrypted end-to-end and only accessible by the intended recipient, to protect from a later claim of data breach. This proves the breach did not happen on your watch – when you were in control of the data.

b. Send with Encryption: This is end-to-end encryption – and the feature of transmitting an advance password is an option that the sender can choose, not required. The sender can also set it up so the recipient can create their own ‘decryption password’ or a schema can be used.

c. Send with Digital Seal authentication rights: This would permit the e-cert to be time-sealed, content tamperproof, and validated at any time in the future, regardless as to whether it was forwarded on to others, and the verification mechanism could be turned off centrally at sender’s request to ‘revoke’ the cert after a cancellation or late renewal payment, so that any future party that tried to authenticate would get a failure // or revocation alert. This is ideal for the specific use described.