Crypto-enabled application projects

NIST S/MIME Activities

NIST has developed a Federal S/MIME V3 Client Profile, (NIST Special Publication 800-49) for security and interoperability based on IETF specifications. The profile includes all mandatory features of the (S/MIME V3) IETF RFCs (RFCs 2630 through 2634) with the EXCEPTION that implementation of RFC 2631 Diffie-Hellman Key Agreement cryptographic algorithm mandated in IETF RFC 2630 is NOT required. In addition, the profile mandates certain optional features required for interoperability and security in secure email products. The primary audience is federal agencies, but the profile may be used by private sector and local governments as well. NOTE: NIST is in the process of updating the client profile to support S/MIME V3.1.

High Level API for Crypto-Functions

The PKI team has developed a high-level Application Programming Interface (API) for public-key based cryptographic services with collaboration from FDIC, GAO, DOE, and Treasury FMS. The objective was to provide a simple interface for PKI-based cryptographic services that hides the complexity of public key cryptography, and facilitate the development of PKI-enabled applications.

The API specifies digital signature and encryption functions, and consists of two sets of operations - one for buffer, and another for file operation. In addition, a Cryptographic Message Syntax (CMS) parser function was also specified. The PKI team has developed reference implementations of this API by building a thin glue layer that maps the high level API to an underlying product API. An agency has expressed interest in using this reference implementation to PKI-enable its financial management system.

Data Formats

Public key infrastructures (PKIs) are starting to be deployed by businesses, industrial/trade organizations, and government agencies to enable and secure electronic transactions. PKIs have enabled businesses and government agencies to perform previously paper-based signed transactions electronically. PKIs provide the capability to authenticate users and to permit them to sign digital data in a technically non-reputable fashion. Many general purpose applications, such as word processors, electronic mail clients, and web browsers, now permit an individual to use a digital signature certificate (an electronic document binding an identity to a digital signature public key) to sign digital data. The digital signature along with the information that was digitally signed is placed into a proprietary format (e.g. Adobe PDF, Microsoft Word) that is unique to the vendor and/or application. As a result, the recipient of digitally signed data must have the specific application that was used to generate the digital signature to verify the digital signature.

A Common Signed Data Format is needed to achieve interoperability across applications.