NIST Special Publication 800-49
`
`NISI
`
`National Institute of
`Standards and Technology
`Technology Administration
`U.S. Department of Commerce
`
`Federal S/MIME V3 Client
`Profile
`
`C. Michael Chernick
`
`C O M P U T E R S E C U R I T Y
`
`
`November 2002
`
`
`MOBILEIRON, INC. - EXHIBIT 1007
`Page 001
`
`

`

`NIST Special Publication 800-49
`
`Federal S/MIME V3 Client
`Profile
`
`Recommendations of the
`National Institute of Standards and Technology
`
`C. Michael Chernick
`
`C O M P U T E R
`
`S E C U R I T Y
`
`Computer Security Division
`Information Technology Laboratory
`National Institute of Standards and Technology
`Gaithersburg, MD 20899-8930
`
`November 2002
`
`U.S. Department of Commerce
`Donald L. Evans, Secretary
`
`Technology Administration
`Phillip J. Bond, Under Secretary of Commerce for Technology
`
`National Institute of Standards and Technology
`Arden L. Bement, Jr., Director
`
`MOBILEIRON, INC. - EXHIBIT 1007
`Page 002
`
`

`

`Reports on Information Security Technology
`
`The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology
`(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the
`Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data,
`proof of concept implementations, and technical analysis to advance the development and productive
`use of information technology. ITL’s responsibilities include the development of technical, physical,
`administrative, and management standards and guidelines for the cost-effective security and privacy of
`sensitive unclassified information in Federal computer systems. This Special Publication 800-series
`reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative
`activities with industry, government, and academic organizations.
`
`Certain commercial entities, equipment, or materials may be identified in this document in order to describe an
`experimental procedure or concept adequately. Such identification is not intended to imply recommendation or
`endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities,
`materials, or equipment are necessarily the best available for the purpose.
`
`National Institute of Standards and Technology Special Publication 800-46
`
`Natl. Inst. Stand. Technol. Spec. Publ. 800-31, 26 pages (November 2002)
`
`CODEN: NSPUE2
`
`
`Acknowledgments
`
`NIST would like to thank the many people who assisted with the development of this profile. We are
`grateful for the support that we received from members of the Internet Engineering Task Force (IETF),
`IETF’s Public-Key Infrastructure Group (X.509) (PKIX) and S/MIME Working Groups. Special
`thanks are due to John Pawling, Jim Schaad, Russ Housley, Blake Ramsdell, and Tim Polk.
`
`MOBILEIRON, INC. - EXHIBIT 1007
`Page 003
`
`

`

`Executive Summary to the Federal S/MIME V3 Client Profile
`
`
`(For Procurement Officials, Implementers, Vendors and Others Interested in Specifying
`S/MIME Technology)
`
`S/MIME (Secure / Multipurpose Internet Mail Extensions) is a set of specifications for securing
`electronic mail. S/MIME is based upon the widely used MIME standard [MIME] and describes a
`protocol for adding cryptographic security services through MIME encapsulation of digitally
`signed and encrypted objects. The basic security services offered by S/MIME are authentication,
`non-repudiation of origin, message integrity, and message privacy. Optional security services
`include signed receipts, security labels, secure mailing lists, and an extended method of
`identifying the signer’s certificate(s).
`
`To understand S/MIME it is useful to understand some of the history of Internet e-mail. In the
`past twenty-five years or so, Internet e-mail has evolved from a simple text-based (ASCII)
`transfer of messages designed for researchers into a more sophisticated messaging system
`capable of communicating a wealth of digital information (e.g., photographic images, computer
`files, sound clips, cinema) to many millions of people around the world.
`
`Internet e-mail was designed for a small community of trusted researchers (primarily at
`university and government sites) for exchanging text-based messages, and thus security was not
`a goal in its design. Over the years many deficiencies in Internet e-mail have been overcome to a
`certain extent through the use of a technology called Multipurpose Internet Mail Extensions
`(MIME). Employing MIME for messaging allows the use of multiple-text effects (e.g., bold,
`italic, various font sizes, and colors) as well as the transfer of digital information. MIME by
`itself also does not address security issues. However, a set of security features has been
`developed and added to MIME to form what is known as S/MIME (Secure MIME).
`
`S/MIME adds features to e-mail messaging including privacy (using encryption), authentication
`of sending party (using digital signatures), integrity (non-alteration of messages), etc. S/MIME
`V3 is the latest version of S/MIME and is supported in whole or part by several vendors with
`“Commercial-Off-The-Shelf” (COTS) products.
`
`Because S/MIME still uses the same extant Internet e-mail technology that has been widely
`deployed for many years, it is not necessary to modify or replace e-mail “servers” to
`accommodate S/MIME. Rather S/MIME functionality may be added to e-mail “client” software.
`By not disturbing the underlying e-mail server/message transfer system, S/MIME allows gradual
`migration from non-secure to secure e-mail messaging, rather than requiring a large, possibly
`abrupt change in technology.
`
`Like other services and protocols used by the Internet community, S/MIME has been under
`development for many years, with the main components specified by the Internet Engineering
`Task Force (IETF), a technical body that issues specifications that serve as standards for vendor
`
`iii
`
`MOBILEIRON, INC. - EXHIBIT 1007
`Page 004
`
`

`

`implementation. These specifications are known as "Request for Comments"1 (RFCs). The
`IETF RFCs for S/MIME reference important standards issued by the International Organization
`for Standardization (ISO) and the International Telecommunication Union (ITU). In addition,
`the U.S. National Institute of Standards and Technology (NIST) has issued certain Federal
`Information Processing Standards (FIPS) that are used to specify requirements for cryptographic
`algorithms and related hardware/software modules used by S/MIME. Thus, implementers and
`users must adhere to a very large set of “standards.”
`
`Furthermore, because standards developers allow many options within communications systems,
`even if all standards are rigidly adhered to, interoperability may not be possible due to differing
`choices of options selected by different vendors. For example, if vendor A chooses to implement
`signed receipts and vendor B chooses not to, then the signed receipts requested by the user of
`vendor A's products will never be sent by vendor B's product although neither implementation
`violates the standards.
`
`To help assure that S/MIME products can interoperate and meet the e-mail security needs of
`federal agencies both with respect to security features, and adequate cryptographic algorithms,
`NIST has developed this Federal S/MIME V3 Client Profile. This profile states requirements for
`implementing sets of cryptographic algorithm suites specified elsewhere by the standards
`development organizations. The profile specifies a set of e-mail security features (e.g.,
`encrypted e-mail, signed receipts) that are mandatory to be implemented. In the definition of this
`Profile, NIST’s intention is never to violate underlying S/MIME standards, but rather to provide
`additional specificity within the standards.
`
`While NIST believes that use of this profile will help assure interoperability of the near term
`secure e-mail products, NIST anticipates that future revisions of the profile will be required to
`reflect new cryptographic algorithms and related attacks, new underlying S/MIME standards,
`and new e-mail security features required by federal agencies.
`
`The use of S/MIME requires the establishment of a Public Key Infrastructure (PKI) to support
`each sender and recipient of S/MIME messages. While the details of PKI are out of scope for
`this document, it is important to note that PKI is used to provide mechanisms to establish the
`identity of S/MIME users (known as authentication) and to provide for digital signatures,
`confidentiality, non-repudiation of sender, etc. X.509 Certificates are used to bind an entity’s
`identity and public key for secure operations for S/MIME and other PKI-enabled secure
`applications. For a further understanding of PKI, see [Kuhn01], [Housley01], or [Adams00] in
`the References clause.
`
`1 (Note: The RFC name is a misnomer, but is retained for historic purposes, and is well-known in the Internet
`development community.)
`
`iv
`
`MOBILEIRON, INC. - EXHIBIT 1007
`Page 005
`
`

`

`Summary of E-mail Security Features Mandated by the Federal
`
`S/MIME V3 Client Profile
`
`
`Feature
`
`Signed Messages
`
`Encrypted Messages
`
`Signed and Encrypted
`Messages
`
`
`Requirement
`
`Send and receive
`
`Send and receive
`
`Send and receive
`
`
`Signed Receipt Processing
`
`Request, send, and process signed receipts
`
`Receipt of Messages from
`Secure Mail List Agents
`
`Cryptographic Modules
`
`Cryptographic Algorithm
`Suite 1 (ALS1)
`
`Cryptographic Algorithm
`Suite 2 (ALS2)
`
`Public Key Infrastructure
`(PKI)
`
`Process messages from secure mail list agents
`(includes suppressing of receipts as required and non-
`disclosure of list recipients as required)
`
`FIPS 140-1 or FIPS 140-2, Security Requirements for
`Cryptographic Modules2
`
`RSA for digital signature [RFC2313] with SHA-1
`hash algorithm [FIPS180-1], RSA for key transport
`
`[RFC2313], Triple-DES [FIPS46-3] for content
`
`encryption (RSA Key Sizes >= 1024 bits)
`
`
`DSA for digital signature [FIPS186-2] with SHA-1
`hash algorithm [FIPS180-1], RSA [RFC2313] for key
`transport, Triple-DES [FIPS46-3] for content
`encryption (DSA Key Size =1024 bits) (RSA Key
`Size >= 1024 bits)
`
`Senders/receivers require valid X.509 certificates
`
`(Conformance to Federal PKI X.509 Certificate and
`
`CRL Extensions Profile required)
`
`
`Note that compliant implementations can generate “clear” signed messages using RSA or DSA
`signature algorithms. (“Clear” signed messages can be read by non S/MIME-enabled clients,
`although signatures cannot be automatically processed and verified by such clients.) S/MIME
`signed messages may include the time that signatures were generated as well as the sender’s PKI
`certificates. The sender’s PKI certificates (also known as X.509 certificates) can be used to
`verify the sender’s identity and help to enable other security services.
`
`2 FIPS-140 defines four levels of security. The appropriate security level is determined by the sensitivity of the
`data. Cryptographic module security levels are thus chosen on the basis of data sensitivity, and this selection is
`beyond the scope of this profile. See Clause 1 of [FIPS 140-2] for a description of security levels.
`
`v
`
`MOBILEIRON, INC. - EXHIBIT 1007
`Page 006
`
`

`

`Compliant implementations process both “clear” and “opaque” signed messages. (“Opaque”
`signed messages are encoded such that the recipient requires an S/MIME-enabled e-mail client to
`automatically read the message.) Each implementation uses the Lightweight Directory Access
`Protocol (LDAP) to obtain certificates and certificate revocation lists (CRLs) and checks that the
`proper fields within each certificate match the sender’s name.
`
`Compliant implementations must be able to encrypt messages for one or more recipients.
`
`Optional Services
`
`The profile identifies three optional cryptographic algorithm suites. These are desirable to
`implement but not mandatory. These suites are:
`
`ALS3: {RSA [RFC 2313] for digital signature with SHA-1 hash algorithm [FIPS180-1],
`RSA [RFC 2313] for key transport, AES [FIPS197] for content encryption}
`
`ALS4: {DSA for digital signature [FIPS186-2] with SHA-1 hash algorithm [FIPS180-1],
`Diffie-Hellman [RFC2631] for key agreement, Triple-DES for content encryption
`[FIPS46-3].}
`
`ALS5: {DSA for digital signature [FIPS186-2] with SHA-256 hash algorithm [FIPS180-
`2], Diffie-Hellman [RFC2631] for key agreement, AES [FIPS197] for content
`encryption}
`Note: Newer versions of DSA are anticipated with support for key sizes greater than 1024
`bits. New standards for D-H and AES usage are anticipated to require the use of the
`SHA-256 hash algorithm. The SHA-256 algorithm is now available. [FIPS180-2]
`
`Optional services in this profile include the ability to send and process e-mail with security labels
`(as defined in the S/MIME V3 standards [RFC2634]). Another optional service is the ability to
`securely bind sender’s certificates to their signatures through the signing certificate attribute (as
`defined in [RFC2634]).
`
`Mail list agent processing (also defined in [RFC2634]) is out-of-scope (i.e., will not be tested for
`conformance) with respect to this protocol. However, S/MIME-enabled e-mail client software
`MUST be able to properly process messages from secure mail list agents.
`
`vi
`
`MOBILEIRON, INC. - EXHIBIT 1007
`Page 007
`
`

`

`Federal S/MIME V3 Client Profile
`
`1
`2
`
`Table of Contents
`
`Introduction..............................................................................................................................1
`
`S/MIME Profile Requirements ................................................................................................2
`
`2.1
`Fundamental Technologies ............................................................................................. 2
`2.1.1
`Cryptographic Algorithm Suite Conformance........................................................ 3
`
`2.1.2
`PKI Profile Conformance ....................................................................................... 4
`
`2.1.3
`Cryptographic Messaging Systems (CMS) Content Types .................................... 5
`
`2.1.4 MIME Encoding ..................................................................................................... 5
`2.1.5 Mail Access Protocols (POP/IMAP) ...................................................................... 6
`
`2.2
`S/MIME Message Generation......................................................................................... 6
`
`2.2.1
`Sending Signed Messages....................................................................................... 6
`
`2.2.2
`Sending Encrypted Messages ................................................................................. 6
`
`2.2.3
`Sending Signed and Encrypted Messages............................................................... 7
`
`2.2.4
`Building MIME Header .......................................................................................... 7
`2.3
`S/MIME Message Reception and Processing................................................................. 7
`
`2.3.1
`Parsing MIME Header ............................................................................................ 7
`
`2.3.2
`Receiving Signed Messages.................................................................................... 7
`
`2.3.3
`Receiving Encrypted Messages .............................................................................. 8
`2.3.4
`Receiving Signed and Encrypted Messages ........................................................... 9
`
`2.3.5
`Processing Return Receipts..................................................................................... 9
`
`2.4
`Certificate Processing ..................................................................................................... 9
`
`2.4.1
`X.509 Certificate Processing .................................................................................. 9
`
`2.4.2
`X.509 CRL Processing............................................................................................ 9
`
`2.4.3
`Path Validation........................................................................................................ 9
`2.4.4
`Path Building ........................................................................................................ 10
`Support for Enhanced Security Services for S/MIME (RFC 2634) ......................................11
`
`3.1
`Signed Receipts............................................................................................................. 11
`
`3.2
`Security Labels.............................................................................................................. 11
`
`3.3
`Secure Mailing Lists ..................................................................................................... 12
`
`3.4
`Signing Certificate Attribute......................................................................................... 12
`
`4 Optional Features and Notes on Testing................................................................................12
`
`4.1
`Generate Application/pkcs7-signature MIME Type (Opaque) Signed Messages........ 12
`
`4.2
`Self-Signed Certificates ................................................................................................ 12
`4.3
`Sending CRLs ............................................................................................................... 12
`
`4.4
`Selective Trust of Certificates....................................................................................... 12
`
`4.5
`Acquiring Certificates................................................................................................... 12
`
`4.6
`Importing/Exporting PKCS #12 Credentials ................................................................ 13
`
`4.7
`Notes on Testing and Scope.......................................................................................... 13
`
`5 References..............................................................................................................................13
`
`A. Appendix A Cryptographic Algorithms (Non-Normative)..................................................16
`
`A.1 One-Way Hash Algorithms........................................................................................... 16
`
`A.2
`Symmetric Encryption Algorithms............................................................................... 16
`
`A.3 Digital Signature Algorithms........................................................................................ 17
`
`A.4 Key Management Algorithms....................................................................................... 17
`
`A.5 Algorithm Suites ........................................................................................................... 18
`
`
`3
`
`
`
`vii
`
`MOBILEIRON, INC. - EXHIBIT 1007
`Page 008
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Federal S/MIME V3 Client Profile
`
`Introduction
`1
`S/MIME (Secure / Multipurpose Internet Mail Extensions) is a set of specifications for securing
`electronic mail. S/MIME is based upon the widely used MIME standard [MIME] and describes a
`protocol for adding cryptographic security services through MIME encapsulation of digitally
`signed and encrypted objects. The basic security services offered by S/MIME are authentication,
`non-repudiation of origin, message integrity, and message privacy. Optional security services
`include signed receipts, security labels, secure mailing lists, and an extended method of
`identifying the signer’s certificate(s).
`
`S/MIME Version 3 is the latest version of S/MIME. Version 3 is specified in IETF RFCs 2630
`through 2634 ([RFC2630], [RFC2631], [RFC2632], [RFC2633], and [RFC2634]).
`
`The S/MIME specifications were designed to promote interoperable secure electronic mail, such
`that two compliant implementations would be able to communicate securely with one another.
`However, implementations may support different optional services, and the specifications may
`unintentionally allow multiple interpretations. As a result, different implementations of S/MIME
`may not be fully interoperable or provide the desired level of security.
`
`The S/MIME specifications rely on cryptographic mechanisms and public key infrastructures
`(PKI) to provide security services. If the cryptographic and PKI components that are used to
`support the S/MIME implementation are sufficiently robust, users can obtain additional
`assurance that sufficiently strong cryptographic algorithms are used, and that procedures are in
`place to protect sensitive information.
`
`Conformance to this profile helps to assure that S/MIME implementations will be able to
`interoperate and provide reasonable assurance to users.
`
`The National Institute of Standards and Technology (NIST), Information Technology
`Laboratory, Computer Security Division, has developed this S/MIME client profile as guidance
`in the development and procurement of commercial-off-the-shelf (COTS) S/MIME-compliant
`products. This profile document identifies requirements for a secure and interoperable S/MIME
`V3 client implementation. NIST is developing tests and testing tools to determine the level of
`conformance of an S/MIME V3 client implementation with this profile.
`
`This profile does not address requirements for network infrastructure components that implement
`S/MIME V3, such as mail list agents (MLAs) and secure mail gateways (e.g., security guards).
`Such systems will have significant overlap but will have additional requirements specific to their
`function.
`
`The remainder of this document is organized into four principal sections: (a) S/MIME Profile
`requirements; (b) Support for Enhanced Security Services (ESS); (c) Optional Features and
`Notes on Testing; and (d) References. In addition, there is a non-Normative Appendix on
`Cryptographic Algorithms. The profile requirements describe the minimum functionality
`required to support secure and interoperable S/MIME client implementations. The support for
`
`1
`
`MOBILEIRON, INC. - EXHIBIT 1007
`Page 009
`
`
`
`

`

`Federal S/MIME V3 Client Profile
`
`ESS section discusses requirements for ESS conformance. The optional features and notes on
`testing section specifies desirable, but optional features for S/MIME client implementations as
`well as useful notes for testing. These features will be useful to “power” users, but fall outside
`the core services required to support mainstream S/MIME users. The references section provides
`current URL as well as document titles when documents are on-line. The non-normative
`appendix on cryptographic algorithms provides guidance on cryptographic algorithms.
`
`2 S/MIME Profile Requirements
`
`Important S/MIME interoperability and security features are identified in this section. First,
`underlying technologies are examined, including cryptography, public key infrastructure (PKI),
`and formatting of cryptographically protected data. The following subsection describes
`requirements in these areas. Using these technologies, S/MIME clients perform two fundamental
`operations: they generate electronic mail messages and process electronic mail messages. The
`second and third sections describe the minimum functionality for S/MIME message generation
`and reception, respectively.
`
`Conformant implementations MUST be able to generate and process signed, encrypted, and
`signed and encrypted messages as detailed in the paragraphs that follow. Conformant
`implementations MUST be able to support all of the mandatory clauses of the IETF RFCs 2630,
`2632, and 2633 with the exception that implementation of RFC 2631 Ephemeral-Static Diffie-
`Hellman Key Agreement [RFC2631] algorithm mandated in [RFC2630] is NOT required by this
`Profile. However, implementation of the Ephemeral-Static Diffie-Hellman Key Agreement
`algorithm in RFC 2631 is recommended. The terms “MUST,” “SHOULD,” and “MAY” are
`used as defined in RFC 2119 [MUSTSHOULD].
`
`Conformance to this profile also assumes implementations of Federal Information Processing
`Standards (FIPS) approved cryptographic algorithms as specified in Clause 2.1.1.
`
`2.1 Fundamental Technologies
`
`S/MIME relies on four fundamental technologies to format and protect electronic mail messages.
`These fundamental technologies are cryptographic algorithms, public key infrastructure (PKI),
`the cryptographic message syntax (CMS) data format, and MIME. Correct implementation of
`these mechanisms is essential to the security and interoperability of every S/MIME client. While
`these technologies will not be tested in isolation, they will be tested indirectly.
`
`However, not all features available through these technologies are required for S/MIME. To that
`end, we describe the features that are required by this profile.
`
`2
`
`MOBILEIRON, INC. - EXHIBIT 1007
`Page 010
`
`

`

`Federal S/MIME V3 Client Profile
`
`2.1.1 Cryptographic Algorithm Suite Conformance
`To help ensure that cryptographic functions are correctly implemented, software modules
`implementing cryptographic functions MUST conform to either FIPS 140-1, or FIPS 140-2,
`Security Requirements For Cryptographic Modules [FIPS140-1] [FIPS140-2]3.
`
`2.1.1.1 Mandatory to Implement Algorithm Suites
`Conforming Federal S/MIME Profile implementations MUST support the following suites of
`cryptographic algorithms:
`ALS1: {RSA for digital signature [RFC2313] with SHA-1 hash algorithm [FIPS180-1],
`RSA for key transport [RFC2313], Triple-DES [FIPS46-3] for content encryption}
`Conforming implementations MUST support a RSA key size of at least 1024 bits. For
`Triple-DES, when generating messages at least two independent keys MUST be
`supported using the Cipher Block Chaining (CBC) Mode. This algorithm is also known
`as DES EDE3 CBC.
`
`ALS2: {DSA for digital signature [FIPS186-2] with SHA-1 hash algorithm [FIPS180-1],
`RSA [RFC2313] for key transport, Triple-DES [FIPS46-3] for content encryption}
`Conforming implementations MUST support a DSA key size of 1024 bits.
`
`This profile requires that implementations MUST be able to verify signatures on certificates and
`messages using either of the above algorithm suites. However for message generation only one
`of these algorithm suites MUST be supported. This implies that both the RSA digital signature
`and DSA algorithms MUST be supported for message verification, but only one of these
`algorithms MUST be supported for message generation. However, implementations SHOULD
`support both signature algorithms for message generation.
`
`2.1.1.2 Recommended Algorithm Suites
`In addition to supporting ALS1 or ALS2, conforming implementations SHOULD support the
`following additional algorithm suites:
`
`ALS3: {RSA [RFC 2313] for digital signature with SHA-1 hash algorithm [FIPS180-1],
`RSA [RFC 2313] for key transport, Advanced Encryption Standard [FIPS197] for content
`encryption}
`
`ALS4: {DSA for digital signature [FIPS186-2] with SHA-1 hash algorithm [FIPS180-1],
`Diffie-Hellman [RFC2631] for key agreement, Triple-DES for content encryption
`[FIPS46-3].}
`
`ALS5: {DSA for digital signature [FIPS186-2] with SHA-256 hash algorithm [FIPS180-
`2], Diffie-Hellman [RFC2631] for key agreement, AES [FIPS197] for content
`encryption}
`
`3 FIPS-140 defines four levels of security. The appropriate security level is determined by the sensitivity of the
`data. Cryptographic module security levels are thus chosen on the basis of data sensitivity, and this selection is
`beyond the scope of this profile. See Clause 1 of [FIPS 140-2] for a description of security levels.
`
`3
`
`MOBILEIRON, INC. - EXHIBIT 1007
`Page 011
`
`

`

`Federal S/MIME V3 Client Profile
`
`Note: Newer versions of DSA will become available with support for key sizes greater
`than 1024 bits. New standards for D-H and AES usage are anticipated to require the use
`of the SHA-256 hash algorithm. The SHA-256 algorithm is now available in draft form.
`
`•
`
`Related recommendations on public key sizes:
`•
`If an implementation supports AES in conjunction with RSA, the implementation
`SHOULD also support RSA public key sizes greater than 1024 bits.
`If an implementation supports AES in conjunction with D-H, the implementation
`SHOULD also support D-H public key sizes greater than 1024 bits.
`If an implementation supports public key sizes greater than 1024 bits when using
`either DSA or RSA for digital signature, the implementation SHOULD also support
`SHA-256.
`
`•
`
`Additional algorithm suites will be identified in the future.
`
`Note: The current Digital Signature Algorithm (DSA) defined in [FIPS186-2] uses a key size of
`at least 1024 bits. Future versions of FIPS 186 will be defined to allow for key sizes of 1024 bits
`or longer.
`
`Support of additional algorithm suites, especially using other FIPS approved algorithms (e.g., the
`Elliptical Curve Digital Signature Algorithm ECDSA [ANSIX9.62]) or other FIPS approved
`algorithms [FIPS140-1] or [FIPS140-2], is encouraged to promote interoperability and backward
`compatibility.
`
`However, some older and weaker algorithm suites should be avoided and not trusted. For
`example, the MD2 message digest algorithm and 512 bit RSA are now considered to be weak by
`many cryptographers.
`
`Further information on cryptographic algorithm suites is provided in Appendix A.
`
`2.1.1.3 Key Wrap Specifications
`In S/MIME V3, management of symmetric cryptographic keys often leads to situations where
`one symmetric key is used to encrypt (or wrap) another (e.g., sending enveloped data to several
`recipients). In situations where Triple-DES [FIPS46-3] is used for symmetric key encryption
`and key wrapping is required, the method for encoding the key wrap is as specified in
`[RFC3217] (or its successor document) MUST be used. In situations where AES [FIPS197] is
`used for symmetric key encryption and key wrapping is required, the method for encoding the
`key wrap as specified in [RFC3394] MUST be used.
`
`2.1.2 PKI Profile Conformance
`In order to help ensure that S/MIME V3 implementations interoperate securely, it is useful to
`adopt a profile of the X.509 standard. The most widely accepted PKI profile is the IETF Public
`Key Infrastructure using X.509 (PKIX) profile developed by the PKIX working group. The
`PKIX profile [RFC3280] identifies the format and semantics of certificates and CRLs for use on
`the Internet. Procedures are described for processing and validating certification paths in the
`Internet environment. The PKIX profile has also been adopted by the Federal PKI Technical
`
`4
`
`MOBILEIRON, INC. - EXHIBIT 1007
`Page 012
`
`

`

`Federal S/MIME V3 Client Profile
`
`Working Group in the “Federal Public Key Infrastructure (PKI) X.509 Certificate and CRL
`Extensions Profile” [CERTCRL]. Conformance to this S/MIME V3 Profile requires
`conformance to [CERTCRL].
`
`2.1.3 Cryptographic Messaging Systems (CMS) Content Types
`Conforming implementations MUST be able to generate and receive the following CMS Content
`Types embedded in a ContentInfo object as defined in [RFC2630]:
`
`• SignedData
`• EnvelopedData
`• Receipt
`
`Conforming implementations MUST be able to generate and receive the following CMS content
`types as embedded content:
`
`• Data
`
`Note: The inclusion of Signed Receipts in Sections 2.2, 2.3, and 3.1 implies that implementations
`MUST include the Receipt content type from [RFC2634].
`
`In S/MIME messages, the Data content type is only used within SignedData or EnvelopedData
`content types and always contains a MIME-encoded message.
`
`Conforming implementations MUST be able to process nested S/MIME security layers such that
`signed data may appear within enveloped data and enveloped data may appear within signed
`data. Details of nesting of content types within MIME types are contained in [RFC2634]
`Clauses 1.1 and 1.2. Nesting beyond triple wrapping as defined in [RFC2634] Clauses 1.1 and
`1.2 is not required.
`
`2.1.4 MIME Encoding
`S/MIME is used to secure MIME content. Traditionally S/MIME implementations have used
`Base64 MIME encoding for all information. (Base64 encoding is used to transfer binary
`information through Internet (SMTP) mail because Internet mail was originally designed to
`transfer ASCII information only. Therefore to ensure that binary information is passed through
`the Internet without modification, it is necessary to translate the information into an ASCII
`representation such as Base64.) Unfortunately Base64 encoding applied to binary information
`causes an increase of message size of at least 33 percent and thus represents a waste of network
`bandwidth, and possibly storage at either end.
`
`S/MIME uses ASN.1 Basic Encoding Rules