Secure Email Brick

The technology elements documented in the Secure Email Brick provide for the following:

• An alternative method of secure email communication where a PKI-based S/MIME solution is not practical (i.e., imposes an undue technical complexity or cost burden on an external partner)
• The capability to establish trust between internal and external senders and recipients
• The capability for an NIH user to send a secure email communication and/or attachment that is received and read by a recipient who is inside or outside the NIH infrastructure
• The capability for an external user to send a secure email communication and/or attachment that is received and read by a recipient who resides inside the NIH infrastructure
• The minimization of operational impact and cost on NIH and external users
  
  
  

• There is no existing baseline to handle NIH external non-affiliate requirements.
• Technologies and vendors identified in the brick are not a replacement for PKI-based S/MIME technology; rather, these are considered to be alternatives when S/MIME is not practical.
• The secure email (email encryption) market is currently in a nascent state with multiple solutions. Research-based analysis indicates secure email (email encryption) technologies will continue to advance and reach mainstream adoption in the next 2 to 5 years.
• NIH should continue to track developments in alternative architecture patterns as well as hybrid models with the ability to enhance current email encryption and secure exchange solutions for inbound and outbound partner and non-affiliate exchange.
• Tactical and strategic deployments must ensure that licensing arrangements provide for unlimited external users at no additional cost to NIH. 
• Vendor licensing levels are established by internal user, internal user and plug-in, or Central Processing Unit (CPU).
• Deployments must limit cost burden on NIH external partners and non-affiliates.
• The current solution provides for external user login to a staging Web server to retrieve secure email by SSL. Tumbleweed and Sigaba have an option of sending a password protected secure email directly to the desktop of previously registered external users.
• Solutions that currently provide “reply only” capabilities for external users may require NIH to register those users on the product’s server (i.e.. external users who need to originate secure email communications with internal users may cause NIH to incur licensing costs and administrative burden).
• Oasis Web Service Standards include Security Assertion Markup Language (SAML). SAML may provide enhanced features or capabilities for secure email communication.